读书笔记—高效程序员的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、 及时通报进展与问题
发布进展情况，新的想法和目前正在关注的主题，不要等着别人来问项目状态如何了。
当经理或同事来询问工作进展、最新设计或研究状况的时候，不会感到头痛。