读书笔记—高效程序员的45个习惯，敏捷开发修炼之道

从公司拿的第一本书《搞笑程序员的45个习惯—敏捷开发修炼之道》，急急忙忙的看完了，写的是什么呢？大概清楚，但具体来说不是很清楚，所以现在总结一下下，里面虽说说的不是很具体，很多是大家都在做的，但是还是总结出来的好，把它养成自己的习惯，符合的继续发扬，不符合的改善，如此而已。

现在我的功力尚浅，读这些习惯的书，应该不算早也不算晚，看看吧，反正不管怎么样，我翻完了，总结一下吧，总结其实就是摘抄里面的内容，自己的感受呢，项目经验太少，应该不是很多，但敲一遍应该能记住一些吧。好吧，开始了。

糟糕的代码需要重构！

需求一直是变化的，不要畏惧变化，但也不要频繁的变更需求，需要在一小段时间内，保持需求的稳定性！

需求是用户决定的，不是编码人员决定的！

测试先行，有时可以让测试牵引着编码工作的进行！

团队内部的协作，资源共享，代码共享，相互帮助，降低每个人垄断的面，使得危险性降为最低，使得每个人都不是不可替代的！

编码：先难后易！这样利于工作的进行，容易的都做完了，难得做的时候遇到问题，有时不得不修改或者重写已经做完的部分。

一、态度决定一切

1、
做事

遇到bug，应该做的是解决问题，而不是找出凶手！！！

2、
欲速则不达

该重构的重构，该修改的修改，有时这会让我们工作的更快。绕过这些，没准我们会走更多弯路！

3、
对事不对人

我们是来工作的，又不是找茬的，是吧，每个人都有自己出色的一方面，当然也会有自己不出色一方面，给每一个人一个表达自己看法的机会。

4、
排除万难、奋勇前进

勇气会让人觉得不自在，提前鼓起勇气更需要魄力。但有些时候，它是扫除障碍的唯一途径，否则问题就会进一步恶化下去。鼓起勇气，这能让你从恐惧中解脱出来。

二、学无止境

1、
跟踪变化

每天学习下新的技术，新的思路，逆水行舟，不进则退，难呀！

2、
对团队投资

与团队的人进行分享，大家强才是真的强大，让讲座穿插在我们的生活中，午饭时间大家都可以交流自己学习的心得，你有苹果我有梨，一共享，咱俩就都有苹果和梨了，何乐而不为呢？

3、
懂得丢弃

有时我们学习了新的技术，新的开发方法和习惯，但也不忍心丢弃旧的不好或者叫不合时宜的技术和习惯，我们应该适应社会的发展，适应技术的创新，我们已经学习了新的技术了，又有什么不忍心废弃掉原来那些不好的耽误事的技术呢？舍得舍得，有舍才有得嘛！

4、
打破沙锅问到底

很好的提问，可以给你带来答案！用一下5H1W什么的方法吧，它确实能给你带来答案，即便带不来答案，也能告诉你你该怎么做了

5、
把握开发节奏

开发节奏不能太慢，那样会让人变得更懒惰，更没有斗志；同样开发节奏太快也是，经常性的加班，也会让人们绝望。就像减肥一样，一点点的成功也是一个很大的激励，小而可以达到的目标可以让人们全速前进，庆祝每一次难忘的成功

三、交付用户想要的软件

在模电上面学到一个词—反馈！他会帮助你开发出很接近用户需求的产品！不断地发布，然后不断地与用户交流，不断地修正需求，这就是反馈带给你的

1、
让客户做决定

产品最后谁用？废话，当然是用户了，所以产品做成什么样子，只有用户才能决定，我们做什么？只能建议！

2、
让设计指导而不是操纵开发

很简答，计划赶不上变化！开始时有一个宏观的设计就好了，不要面面俱到，因为你开始并不是很清楚这个项目，需要在编码过程中慢慢了解，慢慢根据实际情况再进行更详细的设计，开始时就用大量时间做没有实际价值的文档，浪费生命啊，而且自己以后也可能要按照原来的不合适的文档编码，因为那是你费尽九牛二虎之力才弄出来的文档啊，不用的话不是白做了吗？？何苦呢啊

3、
合理的使用技术

技术没有好与不好，只有合适不合适！选择慎重，不是看起来困难的就好，相反，越简单的说明越有功底，就像篮球场上，最牛叉的得分不是什么空中转体360再拉杆…..，一系列花哨的动作得分才是最美的，不可否认，这些可以证明你的实力，但是这样也同时带来更多的体能消耗，也可能带来更多的伤病，相反，一个简单的上空篮得分，一次简单的篮下空位跳投，都是很省体力，很巧妙，而且不会受伤的优雅的得分，能摆脱5个人的防守，证明你的功力更加深厚啊。代码也如此，简单的代码，自己看着清晰，用着简单，别人看着也清晰，维护起来越简单，而且越简单的事物越不容易坏

4、
保持可以发布

随时都保证你的项目能展示给任何人看，给客户，给老板，这样对大家都有好处，对代码的健壮性，对进度的安排，对客户的需求。。。。。。

5、
提早集成，频繁集成

越早集成，越早发现模块间的问题，修改的成本越低

6、
提早实现自动化部署

7、
使用演示获得频繁反馈

他会帮助你开发出很接近用户需求的产品！

8、
使用短迭代，增量发布

9、
固定的价格就意味着背叛承诺

软件项目有很多不确定性，很多东西做之前是没办法评估的

四、敏捷反馈

1、
守护天使

自动化单元测试

2、
先用它再实现它

编程之前，先写测试。先写测试，你就会站在代码用户的角度来思考，而不仅仅是一个单纯的实现着。这样做有很大的区别，你会发现因为你要使用它们，所以能设计一个更有用、更一致的接口。

3、
不同环境，就有不同问题

多平台测试不是增加麻烦，而是减少以后的麻烦的

不同环境下，问题也不同的

4、
自动验收测试

5、
度量真实进度

有时候做一个任务列表真的会很不错，而不是时间性质的，是任务性质的，将一个项目拆分成若干任务，列出来，然后自己做完一个就标记上，没做的就空在那里，等着继续完成

6、
倾听用户的声音

每一个抱怨的背后都隐藏了一个事实，找出真相，修复真正的问题

对客户的那些愚蠢抱怨，你既不会生气，也不会轻视。你会查看一下，找出背后的真正的问题

五、敏捷编码

1、
代码要清晰的表达意图

它说，代码重读的次数远远超过编写的次数，所以还是把代码写的清晰，简洁些吧，有时甚至可以牺牲性能，因为你要让后期升级，维护的人容易做事，因为你也有可能是一个升级别人代码，维护别人代码的人，己所不欲勿施于人嘛。那就把代码写的像英语一样，通俗易懂吧，哪怕借助词典查一下呢

2、
用代码沟通

恰当的注释可以帮助人们阅读代码。不光要写这代码是做什么的，而且也要注明为什么这样做，当时自己的想法。

先阅读注释，然后快速浏览代码，从而完全理解它做了什么，以及为什么这样做。

3、
动态评估取舍

东西没有绝对的好坏，只有适不适合你的客户，面面俱到不太现实，所以还是舍弃一些东西吧，因为你有更重要的东西要做呢

4、
增量式编程

在写了几行代码之后，你会迫切的希望进行依稀构建/测试循环，在没有得到反馈时，你不想走的太远。

5、
保持简单

简单不是简陋。简洁，实用，就好了，不必整一堆花里胡哨的高技术，没用的。

6、
编写内聚的代码

模块自己做自己的事，相互之间耦合度应该低一些，独立性强一点，不能离了谁，谁都玩不转，一个错就都出问题了，这个要特别注意啊！怎么才能做得到呢？？？？？？？？？？？？？？？？？？？？

7、
告知，但不要询问

命令与查询分开。命令可以做很多事，可以修改很多量，但是查询就是去看一下，而不能做出任何修改，也应该不要做任何修改

8、
根据契约进行替换

六、敏捷调试

1、
记录问题解决日志

这个就像高中时期的错题本，2个月2个本子，让我的数学成绩从90多分提至了130多分甚至更高，这说明了什么？说明了人们会经常跌倒在同一个地方，是很不长记性的，所以我们怎么办？脑子记不住，笔头总可以吧，写上啊，以后再查啊，没事就瞅瞅啊，笑话下自己嘛，是吧！

2、
警告就是错误

没事也应该多注意下警告，争取都给改了，完美主义者有什么不好呢？不过我的实际经验告诉我，有些警告是不可以避免的，是不用去搭理的，这个看你自己了，看具体情况了。

3、
对问题各个击破

没啥可说的，调试时基本的原则，单一变量原则，我们要确保周围其他的一定是好的，方能去判断这个事物是不是好的，所以，尽可能的拆开他们吧，那样你的思路会更清晰，做事情也越轻松

4、
报告所有的异常

报告异常情况，利于你的调试

要传播不能处理的异常

有些东西隐藏起来终究会出来祸害人的，只能将其消灭掉，消灭不了的，也要将其示之于众，让大家来看清楚他，消灭它吧

5、
提供有用的错误信息

不是什么丢人的事，利己利人！

七、敏捷协作

双拳难敌四手，一个人干不过一群人的，所以团队是一个很重要的玩意儿，团队中不能只有一个人发挥，其他人抑制，因为那样还是一个人，我更倾向于抑制一个人激活全队的人，当然最好的结果是，激活所有的人，但是也有偶尔嘛，哈哈，大家的利益高于一切，在哪都是这样的，没啥可说的，除非你是牛人，但世界上牛人不是很多，我看还是老老实实混团队吧。

1、
定期安排会面时间

当然会议的交流很重要，相互了解，相互帮助。

2、
架构师必须写代码

只有深入进去了，才能了解，了解了才能架构啊

3、
实行代码集体所有制

让开发人员轮换完成系统不同领域中的不同模块的不同任务

4、
成为领导者

你会感到给予别人教导，也是提升自己学识的一种方式，并且其他人亦可以开始相信你可以帮助他们

5、
允许大家自己想办法

用问题来回答问题，可以引导提问的人走向正确的道路

如果有人真的陷入胶着状态，就不要折磨他们了，告诉他们答案，再解释为什么是这样的

6、
准备好后再共享代码

自己对自己负责嘛，没啥说的

7、
做代码复查

人都是会犯错的，相互之间做代码复查是很好的，一起提高

8、
及时通报进展与问题

发布进展情况，新的想法和目前正在关注的主题，不要等着别人来问项目状态如何了。

当经理或同事来询问工作进展、最新设计或研究状况的时候，不会感到头痛。