大公司里的小敏捷（1）

现在讨论敏捷过程已经不是一个新鲜的话题了，新技术公司大都在应用敏捷去改变现在的开发状态，但是不得不说，在一些传统的软件公司或者传统的Leader的领导下，我们的team怎么去敏捷那。我这里有点不成文的想法，希望和大家讨论:
1、数据的敏捷————对于一个项目来说，保证质量当然是需要良好的测试，而良好的测试对数据的要求是非常高的，那么我想应该从需求阶段开始准备数据了，而且要维护好数据，保证数据的同步。

2、应对变化：快速的开发pototype。这点很重要，要让客户有一定的体验的话，这个是必需的，我很看好grails，这是个快速开发的好方式，而且，这样的话对于一些辅助性的数据的保持也是很好的方式（ps 现在好多function的测试人员联数据库的select都不会。。。）

3、性能至上：说这句话真的不是说业务function就不重要了，我觉得应该一开始就要关注性能，这基本上是每个大型JavaEE不可回避的问题。

（待续）

评论

17 楼 comet12345678 2008-02-02  

gigix 写道

comet12345678 写道

Lucas Lee 写道

我以前也以为性能问题总是可以到最后再调整。
不过几年前一次失败的经历让我改变了这个看法。
那是在hibernate和EJB流行之前，我们自己按面向对象方法开发一个b/s的CRM系统。
最大的问题之一就是性能问题，最严重的是按用户权限过滤可看到的数据，是在数据load后挨个过滤而不是直接在sql层面用where过滤。
可想而知，会是多么慢。

所以，对于性能问题，我的看法改为：根据经验在开始时估计一下大概的瓶颈和负载能力（是否能合适），然后到后期再调整。如果有疑问就要先做性能测试，不能盲目认为性能是小问题（特别是没有直接经验，直接在这里看人家说的人，呵呵）。

   性能问题既可能是实现问题，也可能是结构问题，结构问题在开始就要考虑，实现可以局部调整。

但是不要忘了，最严重的性能问题，是难以定位难以修复的那一类性能问题。而难以定位难以修复，往往是由于代码质量低下造成的。而代码质量低下，很多时候正是因为过早地考虑性能造成的。

      所以开始考虑的是结构问题，而不是实现细节。
      不过，代码质量低下,再好的架构，再好的方案都没用了。

16 楼 gigix 2008-01-31  

comet12345678 写道

Lucas Lee 写道

我以前也以为性能问题总是可以到最后再调整。
不过几年前一次失败的经历让我改变了这个看法。
那是在hibernate和EJB流行之前，我们自己按面向对象方法开发一个b/s的CRM系统。
最大的问题之一就是性能问题，最严重的是按用户权限过滤可看到的数据，是在数据load后挨个过滤而不是直接在sql层面用where过滤。
可想而知，会是多么慢。

所以，对于性能问题，我的看法改为：根据经验在开始时估计一下大概的瓶颈和负载能力（是否能合适），然后到后期再调整。如果有疑问就要先做性能测试，不能盲目认为性能是小问题（特别是没有直接经验，直接在这里看人家说的人，呵呵）。

   性能问题既可能是实现问题，也可能是结构问题，结构问题在开始就要考虑，实现可以局部调整。

但是不要忘了，最严重的性能问题，是难以定位难以修复的那一类性能问题。而难以定位难以修复，往往是由于代码质量低下造成的。而代码质量低下，很多时候正是因为过早地考虑性能造成的。

15 楼 comet12345678 2008-01-30  

Lucas Lee 写道

我以前也以为性能问题总是可以到最后再调整。
不过几年前一次失败的经历让我改变了这个看法。
那是在hibernate和EJB流行之前，我们自己按面向对象方法开发一个b/s的CRM系统。
最大的问题之一就是性能问题，最严重的是按用户权限过滤可看到的数据，是在数据load后挨个过滤而不是直接在sql层面用where过滤。
可想而知，会是多么慢。

所以，对于性能问题，我的看法改为：根据经验在开始时估计一下大概的瓶颈和负载能力（是否能合适），然后到后期再调整。如果有疑问就要先做性能测试，不能盲目认为性能是小问题（特别是没有直接经验，直接在这里看人家说的人，呵呵）。

   性能问题既可能是实现问题，也可能是结构问题，结构问题在开始就要考虑，实现可以局部调整。

14 楼 抛出异常的爱 2008-01-30  

Lucas Lee 写道

我以前也以为性能问题总是可以到最后再调整。
不过几年前一次失败的经历让我改变了这个看法。
那是在hibernate和EJB流行之前，我们自己按面向对象方法开发一个b/s的CRM系统。
最大的问题之一就是性能问题，最严重的是按用户权限过滤可看到的数据，是在数据load后挨个过滤而不是直接在sql层面用where过滤。
可想而知，会是多么慢。

所以，对于性能问题，我的看法改为：根据经验在开始时估计一下大概的瓶颈和负载能力（是否能合适），然后到后期再调整。如果有疑问就要先做性能测试，不能盲目认为性能是小问题（特别是没有直接经验，直接在这里看人家说的人，呵呵）。

这就是为什么翻页没被取消的原因。
PS：对于敏捷的系统来说
把load后的数据挨个过滤
改成到sql里加where条件
叫作重构。
这是敏捷可以接受的变更

我的看法是把所有的性能问题要变成需求来作。
而不是bug来修改。

13 楼 LucasLee 2008-01-30  

我以前也以为性能问题总是可以到最后再调整。
不过几年前一次失败的经历让我改变了这个看法。
那是在hibernate和EJB流行之前，我们自己按面向对象方法开发一个b/s的CRM系统。
最大的问题之一就是性能问题，最严重的是按用户权限过滤可看到的数据，是在数据load后挨个过滤而不是直接在sql层面用where过滤。
可想而知，会是多么慢。

所以，对于性能问题，我的看法改为：根据经验在开始时估计一下大概的瓶颈和负载能力（是否能合适），然后到后期再调整。如果有疑问就要先做性能测试，不能盲目认为性能是小问题（特别是没有直接经验，直接在这里看人家说的人，呵呵）。

12 楼 抛出异常的爱 2008-01-30  

gigix 写道

花花公子 写道

对于性能，忘了是谁说的，“当它成为一个问题，它才是问题”。

我告诉你一个从大量咨询项目中得到的经验

如果一个人感到自己的项目有严重的问题
但是又不能/不敢/不愿说出到底是什么问题
他就会说有性能问题

凡是有人跟你说他的项目有性能问题，你就大胆的猜他在需求/质量/沟通上有问题。真正有性能问题而不能用常见的敏捷实践解决的情况出现概率之小，以致于我每次都敢拿一顿晚餐来打赌。

听了这话。。。。我再加一顿。。。
明天再去酒桌上调研一下。

11 楼 windedge 2008-01-30  

抛出异常的爱 写道

dearwolf 写道

2、应对变化：快速的开发prototype。这点很重要，要让客户有一定的体验的话，这个是必需的，我很看好grails，这是个快速开发的好方式，而且，这样的话对于一些辅助性的数据的保持也是很好的方式（ps 现在好多function的测试人员联数据库的select都不会。。。）

测试员不应该会....
而且原型开发是瀑布的典型用法.

敏捷开发用原型开发又怎么了？

原型的主要目的是重复....
我并不是说原型不好,
对于瀑布来说.....
但是你见哪个敏捷的东西是用原型拷贝出来的?
敏捷是把模块先搭出来....之后重用.

对原型的理解不一样?希望看到更深入的探讨~

10 楼 gigix 2008-01-30  

花花公子 写道

对于性能，忘了是谁说的，“当它成为一个问题，它才是问题”。

我告诉你一个从大量咨询项目中得到的经验

如果一个人感到自己的项目有严重的问题
但是又不能/不敢/不愿说出到底是什么问题
他就会说有性能问题

凡是有人跟你说他的项目有性能问题，你就大胆的猜他在需求/质量/沟通上有问题。真正有性能问题而不能用常见的敏捷实践解决的情况出现概率之小，以致于我每次都敢拿一顿晚餐来打赌。

9 楼 庄表伟 2008-01-28  

chengren 写道

花花公子 写道

对于性能，忘了是谁说的，“当它成为一个问题，它才是问题”。

嘿嘿。。。
那你的硬件服务器是怎么规划出来的呢？

不是他规划的...

8 楼 balaschen 2008-01-28  

引用

1、数据的敏捷————对于一个项目来说，保证质量当然是需要良好的测试，而良好的测试对数据的要求是非常高的，那么我想应该从需求阶段开始准备数据了，而且要维护好数据，保证数据的同步。

这样还敏捷么
不要乱用新鲜词

7 楼 chengren 2008-01-25  

花花公子 写道

对于性能，忘了是谁说的，“当它成为一个问题，它才是问题”。

嘿嘿。。。
那你的硬件服务器是怎么规划出来的呢？

6 楼 抛出异常的爱 2008-01-25  

大部分的观点还是很有价值的.
等待楼主继续

5 楼 花花公子 2008-01-25  

对于性能，忘了是谁说的，“当它成为一个问题，它才是问题”。

4 楼 xly_971223 2008-01-25  

引用

性能至上

这就是胡扯了 性能是最后考虑的一个问题
只要不写出低级代码 性能的瓶颈就集中在那么几点，专门解决就可以了

3 楼 抛出异常的爱 2008-01-24  

dearwolf 写道

2、应对变化：快速的开发prototype。这点很重要，要让客户有一定的体验的话，这个是必需的，我很看好grails，这是个快速开发的好方式，而且，这样的话对于一些辅助性的数据的保持也是很好的方式（ps 现在好多function的测试人员联数据库的select都不会。。。）

测试员不应该会....
而且原型开发是瀑布的典型用法.

敏捷开发用原型开发又怎么了？

原型的主要目的是重复....
我并不是说原型不好,
对于瀑布来说.....
但是你见哪个敏捷的东西是用原型拷贝出来的?
敏捷是把模块先搭出来....之后重用.

2 楼 dearwolf 2008-01-24  

2、应对变化：快速的开发prototype。这点很重要，要让客户有一定的体验的话，这个是必需的，我很看好grails，这是个快速开发的好方式，而且，这样的话对于一些辅助性的数据的保持也是很好的方式（ps 现在好多function的测试人员联数据库的select都不会。。。）

测试员不应该会....
而且原型开发是瀑布的典型用法.

敏捷开发用原型开发又怎么了？

1 楼 抛出异常的爱 2008-01-24  

3、性能至上：说这句话真的不是说业务function就不重要了，我觉得应该一开始就要关注性能，这基本上是每个大型JavaEE不可回避的问题。

瀑布汗....这样是敏不起来的.
敏捷这东西是指在开始时只考虑最少最有必要的东西.

2、应对变化：快速的开发prototype。这点很重要，要让客户有一定的体验的话，这个是必需的，我很看好grails，这是个快速开发的好方式，而且，这样的话对于一些辅助性的数据的保持也是很好的方式（ps 现在好多function的测试人员联数据库的select都不会。。。）

测试员不应该会....
而且原型开发是瀑布的典型用法.


1、数据的敏捷————对于一个项目来说，保证质量当然是需要良好的测试，而良好的测试对数据的要求是非常高的，那么我想应该从需求阶段开始准备数据了，而且要维护好数据，保证数据的同步

这点放最后....至少要放到页面的敏捷之后...