大公司里的小敏捷（1）
现在讨论敏捷过程已经不是一个新鲜的话题了，新技术公司大都在应用敏捷去改变现在的开发状态，但是不得不说，在一些传统的软件公司或者传统的Leader的领导下，我们的team怎么去敏捷那。我这里有点不成文的想法，希望和大家讨论:
1、数据的敏捷————对于一个项目来说，保证质量当然是需要良好的测试，而良好的测试对数据的要求是非常高的，那么我想应该从需求阶段开始准备数据了，而且要维护好数据，保证数据的同步。
2、应对变化：快速的开发pototype。这点很重要，要让客户有一定的体验的话，这个是必需的，我很看好grails，这是个快速开发的好方式，而且，这样的话对于一些辅助性的数据的保持也是很好的方式（ps 现在好多function的测试人员联数据库的select都不会。。。）
3、性能至上：说这句话真的不是说业务function就不重要了，我觉得应该一开始就要关注性能，这基本上是每个大型JavaEE不可回避的问题。
（待续）
不要乱用新鲜词
10 楼 gigix 2008-01-30 花花公子 写道对于性能，忘了是谁说的，“当它成为一个问题，它才是问题”。
我告诉你一个从大量咨询项目中得到的经验
如果一个人感到自己的项目有严重的问题
但是又不能/不敢/不愿说出到底是什么问题
他就会说有性能问题
凡是有人跟你说他的项目有性能问题，你就大胆的猜他在需求/质量/沟通上有问题。真正有性能问题而不能用常见的敏捷实践解决的情况出现概率之小，以致于我每次都敢拿一顿晚餐来打赌。 11 楼 windedge 2008-01-30 抛出异常的爱 写道dearwolf 写道2、应对变化：快速的开发prototype。这点很重要，要让客户有一定的体验的话，这个是必需的，我很看好grails，这是个快速开发的好方式，而且，这样的话对于一些辅助性的数据的保持也是很好的方式（ps 现在好多function的测试人员联数据库的select都不会。。。）
测试员不应该会....
而且原型开发是瀑布的典型用法.
敏捷开发用原型开发又怎么了？
原型的主要目的是重复....
我并不是说原型不好,
对于瀑布来说.....
但是你见哪个敏捷的东西是用原型拷贝出来的?
敏捷是把模块先搭出来....之后重用.
对原型的理解不一样?希望看到更深入的探讨~ 12 楼 抛出异常的爱 2008-01-30 gigix 写道花花公子 写道对于性能，忘了是谁说的，“当它成为一个问题，它才是问题”。
我告诉你一个从大量咨询项目中得到的经验
如果一个人感到自己的项目有严重的问题
但是又不能/不敢/不愿说出到底是什么问题
他就会说有性能问题
凡是有人跟你说他的项目有性能问题，你就大胆的猜他在需求/质量/沟通上有问题。真正有性能问题而不能用常见的敏捷实践解决的情况出现概率之小，以致于我每次都敢拿一顿晚餐来打赌。
听了这话。。。。我再加一顿。。。
明天再去酒桌上调研一下。 13 楼 LucasLee 2008-01-30 我以前也以为性能问题总是可以到最后再调整。
不过几年前一次失败的经历让我改变了这个看法。
那是在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来修改。 15 楼 comet12345678 2008-01-30 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过滤。
可想而知，会是多么慢。
所以，对于性能问题，我的看法改为：根据经验在开始时估计一下大概的瓶颈和负载能力（是否能合适），然后到后期再调整。如果有疑问就要先做性能测试，不能盲目认为性能是小问题（特别是没有直接经验，直接在这里看人家说的人，呵呵）。
性能问题既可能是实现问题，也可能是结构问题，结构问题在开始就要考虑，实现可以局部调整。
但是不要忘了，最严重的性能问题，是难以定位难以修复的那一类性能问题。而难以定位难以修复，往往是由于代码质量低下造成的。而代码质量低下，很多时候正是因为过早地考虑性能造成的。 17 楼 comet12345678 2008-02-02 gigix 写道comet12345678 写道Lucas Lee 写道我以前也以为性能问题总是可以到最后再调整。
不过几年前一次失败的经历让我改变了这个看法。
那是在hibernate和EJB流行之前，我们自己按面向对象方法开发一个b/s的CRM系统。
最大的问题之一就是性能问题，最严重的是按用户权限过滤可看到的数据，是在数据load后挨个过滤而不是直接在sql层面用where过滤。
可想而知，会是多么慢。
所以，对于性能问题，我的看法改为：根据经验在开始时估计一下大概的瓶颈和负载能力（是否能合适），然后到后期再调整。如果有疑问就要先做性能测试，不能盲目认为性能是小问题（特别是没有直接经验，直接在这里看人家说的人，呵呵）。
性能问题既可能是实现问题，也可能是结构问题，结构问题在开始就要考虑，实现可以局部调整。
但是不要忘了，最严重的性能问题，是难以定位难以修复的那一类性能问题。而难以定位难以修复，往往是由于代码质量低下造成的。而代码质量低下，很多时候正是因为过早地考虑性能造成的。
所以开始考虑的是结构问题，而不是实现细节。
不过，代码质量低下,再好的架构，再好的方案都没用了。