为什么是《敏捷软件开发》
我也想风驰电掣，快马加鞭。但是残酷的现实一次次的打在我的脸上。一天一天就这么的浪费在了无意义的编码上，不断的推翻，重建，推翻，重建。倒不是为了精益求精而改写代码，而是每一版都有逻辑上的大问题，以及需求的不明确，导致写出来的东西要么不能用，要么不合规。更有甚者，写到末期了，发现那临门一脚，迈不开，回溯到了前边不知哪一步了。
时间都去哪儿了？
为什么是《敏捷软件开发》？
当然是因为我有需求啊，而这本在我的书库里面躺灰的书的书名恰巧引起了我的注意。
不知它是或否能解决我的困惑呢？为我带来这曙光。
Tips：本文不涉及代码，还愿意继续吗
Tips：不但如此，还会有穿插文中的链接
极限编程实践
（本段出自《敏捷软件开发》，是我非常喜欢的一个片段，放在开头与大家共享）
完整团队
XP项目的所有参与者(开发人员、业务分析师、测试人员等等)一起工作在一个开放的场所中，他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。
关于这点，我前些天去我乐哥的公司玩儿的时候，就感受到了这种轻松愉快的氛围，还挺喜欢，这就是工作吗，那也是愿意上班的。
计划游戏
计划是持续的、循序渐进的。每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性。
这个暂时还体会不到。曾经我的老师跟我说，程序员应该每个月都在项目期，这样的进步是非常快的。我也不知道对不对，但是让我这么搞，我这小身板儿怕是hold不住啊。
客户测试
作为选择每个所期望的特性的一部分，客户定义出自动验收测试来表明该特性可以工作。
简单设计
团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试，不包含任何重复,表达出了编写者想表达的所有东西，并且包含尽可能少的代码。
这也是我一直追求的。以前是通过代码的不断迭代，但是现在我觉得应该是通过理论的不断迭代来达成这个愿景。
结对编程
所有的产品软件都是由两个程序员、并排坐在一-起在同一台机器上构建的。
这个我也曾努力过，但是他们都去上班了。。。
测试驱动开发
程序员以非常短的循环周期工作，他们先增加一个失败的测试，然后使之通过。
这个就是我一直对我的团队成员说的，每一个模块，在开始写之前应该先把测试的刁钻案例先写好，模块一写完马上进行测试。
改进设计
随时改进糟糕的代码，保持代码尽可能的干净、具有表达力。
可持续的速度
团队只有持久才有获胜的希望，他们能够以长期维持的速度努力工作，他们保存精力，他们把项目看做是马拉松长跑，而不是全速短跑。
敏捷软件开发宣言
| 个体和交互 | 胜过 | 过程工具 |
| 可以工作的伙伴 | 胜过 | 面面俱到的文档 |
| 客户合作 | 胜过 | 合同谈判 |
| 响应变化 | 胜过 | 遵循计划 |
墨子说：非贤无急，非士无与虑国
优质的团队固然重要，但是更为重要的是团队成员之间的协作。
详尽的文档固然重要，但是给你一本砖头一样的工具书你能看几页？
至于第三点，嗯，懂得都懂。。。
结对编程
我靠，这个实在是太喜欢了。倒也不是找不到人，只是没有去找。
好吧，是有点困难。
结对编程：所有的产品代码都是由结对的程序员使用一台电脑共同完成的。结对人员中的一位控制键盘输入，另一位观察输入的代码中的错误和可以改进的地方···
多好。实名羡慕。
理想中是这样的：
当然这样也是可以接受的：
总不能这样吧：（其实也并无不可，我要在后边）
靠，下次带团队项目就这么玩，，，
主要是我自己想玩
《重构》读书笔记
重构<1> 好好的项目为什么我要一遍遍重写
重构<2> 那些该回炉重造的回锅肉
重构<3> 我是一个类，难道我不配拥有专属测试代码吗？
设计模式六大原则
什么激发了软件设计的腐臭味
僵化、脆弱、不牢固
粘滞、不必要的复杂、不必要的重复、晦涩难懂。
什么时候，我们写出来的代码变成了这样。
如果不服气，请找出自己两个月前写的开发代码。如果觉得还很不错，那要么是你的代码作风真的非常好，要么就是你这两个月就没什么进步。
我经常翻看自己以前写的项目代码，常常感慨：这写的什么狗屎？这段代码的算法思想是什么？WC，为什么注释乱写？？？？？
哎。。。然后开始大改。
改到一半，实在受不了了，这还不如重写。
问题出在哪里呢？
首先就是设计的问题，代码结构设计不好，其实那时候的我们可能也就那个水平，只能设计出那样的结构来，也无话可说。
其次就是不写注释，或者乱写注释。不是说，程序员最讨厌的两件事就是：别人不写注释，和别人叫我写注释嘛。（我正在养成写好注释的习惯，尽量言简意赅）
再就是面向CV编程了。
少复制粘贴吧，实在不行，就手抄嘛，复制粘贴很容易出问题，特别是在变量命名上，有时候就把别的地方的变量夹带过去，又忘记改，回头来找还不好找。
对付时常变化的需求，就将功能封装成可拓展性强的模块吧。
我的困惑已经得到了解决，《敏捷软件开发》这本书里面的设计模式讲的也不错，后面我还会用这本书在整理一下我所学的设计模式。
不知解决了你的困惑吗，如果你发现看不懂那本书，或者看不懂我这么浅显易懂的文，敲个几万行熟悉一下就好啦，问题不大。
文章来源: lion-wu.blog.csdn.net，作者：看，未来，版权归原作者所有，如需转载，请联系作者。
原文链接：lion-wu.blog.csdn.net/article/details/110794439