什么是敏捷设计开发

   敏捷设计是一个过程而不是一个事件。它是一个持续的应用原则、模式以及实践来改进软件的结构和可读性的过程。它致力于保持系统设计在任何事件都尽可能得简单、干净以及富有表现力。

   敏捷开发最不能容忍的几点：

• 僵化性：很难对系统的某一部分进行改动，因为改动这个有可能引发别的也需要一同改动；
• 脆弱性：对系统改动会导致系统中和改动的地方在概念上无关的许多地方出现问题；
• 牢固性：很难在其他系统中使之重用；
• 粘滞性：做正确的事情比做错误的事情要困难；
• 不必要的复杂性：对系统过于封装的复杂，使程序不易看懂；系统中含有使用不到的代码；
• 不必要的重复：在系统中多处地方出现类似的代码；
• 晦涩性：代码很难理解，很难阅读，没有很好的表现出意图。

    在大多数软件项目中最不可预测的就是需求的变化，这是作为软件开发人员必须接受的事实！我们生活在一个需求不断变化的世界中，我们的工作要保证我们的软件能承受住需求的变化。如果承受不住需求的变化，那么敏捷开发就是失败的。

敏捷开发致力于马拉松赛跑，一步一个脚印，慢慢积累，最开始使用最简单的做法，在以后的一天天里慢慢的改进原先的代码，当看到有需要修改的代码，作为敏捷开发人员必须要马上改掉，而不应该散漫和推脱。

    简而言之，敏捷开发人员知道自己要做什么，是因为：

1. 遵循敏捷时间去发现问题；
2. 应用设计原则去分析问题；
3. 适当运用设计模式去解决问题； 

  而我把敏捷开发人员需要知道自己做什么简单的定义为3q法则，3代表三条，q代表中文的去的首字母。时刻记住这3q法则，则能很好的知道自己在做项目中处于一个什么角色。

  保持尽可能好的设计，做到一个敏捷开发人员该有的特质，看到不好的代码改之，看到不好的设计改之，尽可能的使代码通俗易懂，从而给人的感觉像是一个人开发的一样，做到人人可以看得懂别人写的代码，人人可以动手改别人不好的代码。这就好小时候医生给我们打防御疫苗一样，没跟针都进过消毒，消毒过程是对每个小孩生命的正西(当然对于部分所谓的医生我直接无视)，如果没有消毒过程，那么被感染的风险会大大提高，这是难以忍受的。敏捷开发对于我们程序员来讲是同样的道理。

     总之，源代码一定要保持干净，简单，稳定，职业特性使我们有着对代码有精益求精的精神。虽然敏捷开发在中国很难坚持，但是还是尽量做到最好。

评论

12 楼 hobitton 2010-08-27  

lz大哥比较喜欢copy文字啊，，。。。。。。。这真得隐藏。。。

11 楼 csc365kl 2010-07-05  

我感觉比较适合打 一枪换一个地方的

10 楼 ajonjun 2010-07-02  

是一种思想，个人并不认同敏捷，不是所有项目适用的。

9 楼 lizhou 2010-06-28  

支持LZ，虽然就中国人目前的习惯和做法来说，真正的敏捷开发实施很困难。但仍然希望有人坚持下去

8 楼 herryhaixiao 2010-06-28  

gigix 写道

想法很好，还可以深思下去。继续努力吧。

恩，我会努力的，但是看到那么多投隐藏的，不知道是否值得继续下去，似乎在国内大部分没多少人肯定这种模式？
这个模式开发是要需要单元测试来保证的，可以确保功能的准确性，开发前先用单元测试写出需要的功能，然后在改不好的代码，这个就能控制bug的产生了。
每个功能点都用junit对应，这样看到不好的代码就可以随意改动了，但是改动后的结果符合测试的结果就好了，不知这个您有什么看法。

7 楼 see8di 2010-06-28  

這是一種趨于理想狀態的開發模式,要做到如此不容易,除非所有的程序員都是老手否則還是蠻難的.

6 楼 一蓑烟雨任平生 2010-06-27  

不好意思，是俺6月21日投的，俺投隐藏的时候，没想到gigix要来教育LZ。

5 楼 daquan198163 2010-06-27  

这是谁投的隐藏啊，没看gigix快要引导LZ找到问题的关键了么

4 楼 gigix 2010-06-27  

herryhaixiao 写道

敏捷开发我想是适用于有几年工作经验以上并且有能力的程序员，而且要了解项目的整个架构，如果是抱着出了问题谁负责的态度，那你就是一普通程序员，不适合敏捷开发。上线出事故，这种问题确实是有风险，这就有必要要求开发人员和测试人员严格把关了。

你这话说了，仍然是没有解决问题。

比如说吧，如果一个项目里都是普通程序员，“有几年工作经验以上并且有能力的程序员”都去做了项目经理或者跳槽了，那你怎么办？是不是就只能对他们说，不好意思，你们不适合敏捷开发？那么你讲的这套东西，说穿了就是：有好的程序员，就能做出好的设计；只有普通程序员，就做不出好的设计。那这套所谓的方法，到底有什么用呢？

再比如说吧，你说一句“严格把关”，怎么把？某公司开发一个BOSS系统，光是一轮关键业务回归测试就要做3～5天。一个月要给局方上一个版本，有几个3～5天来做回归测试？你看到不好的代码改之了，这句“严格把关”叫开发人员和测试人员怎么去落地？

想法很好，还可以深思下去。继续努力吧。

3 楼 herryhaixiao 2010-06-27  

gigix 写道

引用

保持尽可能好的设计，做到一个敏捷开发人员该有的特质，看到不好的代码改之，看到不好的设计改之，尽可能的使代码通俗易懂，从而给人的感觉像是一个人开发的一样，做到人人可以看得懂别人写的代码，人人可以动手改别人不好的代码。这就好小时候医生给我们打防御疫苗一样，没跟针都进过消毒，消毒过程是对每个小孩生命的正西(当然对于部分所谓的医生我直接无视)，如果没有消毒过程，那么被感染的风险会大大提高，这是难以忍受的。敏捷开发对于我们程序员来讲是同样的道理。

总之，源代码一定要保持干净，简单，稳定，职业特性使我们有着对代码有精益求精的精神。虽然敏捷开发在中国很难坚持，但是还是尽量做到最好。

如果代码一改就有可能出错，你怎么办？
原来的代码虽然不干净，至少是可以工作的。你一改，改坏了，出了线上事故，造成了损失。这种情况，你怎么办？

恩，是的，你说出了中国很多程序员的心声，想改又怕改错，怕承担责任，针对这种问题确实是比较头痛的，其实大部分都知道自己的项目有什么地方写的不好，但是都觉得只要不是自己的模块就无关紧要，而且出了问题也不是我的责任，再说框架是架构师设计的也没必要去管它，普遍程序员都是这种心态，所以就会出现诸如电信项目里面的代码及其混乱，二期开发很难入手的传言。敏捷开发我想是适用于有几年工作经验以上并且有能力的程序员，而且要了解项目的整个架构，如果是抱着出了问题谁负责的态度，那你就是一普通程序员，不适合敏捷开发。上线出事故，这种问题确实是有风险，这就有必要要求开发人员和测试人员严格把关了。

2 楼 gigix 2010-06-27  

引用

保持尽可能好的设计，做到一个敏捷开发人员该有的特质，看到不好的代码改之，看到不好的设计改之，尽可能的使代码通俗易懂，从而给人的感觉像是一个人开发的一样，做到人人可以看得懂别人写的代码，人人可以动手改别人不好的代码。这就好小时候医生给我们打防御疫苗一样，没跟针都进过消毒，消毒过程是对每个小孩生命的正西(当然对于部分所谓的医生我直接无视)，如果没有消毒过程，那么被感染的风险会大大提高，这是难以忍受的。敏捷开发对于我们程序员来讲是同样的道理。

总之，源代码一定要保持干净，简单，稳定，职业特性使我们有着对代码有精益求精的精神。虽然敏捷开发在中国很难坚持，但是还是尽量做到最好。

如果代码一改就有可能出错，你怎么办？
原来的代码虽然不干净，至少是可以工作的。你一改，改坏了，出了线上事故，造成了损失。这种情况，你怎么办？

1 楼 chellman 2010-06-27  

说的挺好的。
看到不好的代码改之，看到不好的设计改之。其实更多的时候是人的惰性和自扫门前雪的心理在作祟。