Sunny Way

终于把这本书读完了，读了之后觉得这书确实是本好书，虽然有些“习惯”还体会不太深，但是能吸收的还是很多的。
如同译者序中说的那样：“武功者，包括内功、外功、武术技击之总和”，这本书写的就是内功，习武方要内外兼修。然，习得盖世武功还不足以雄霸天下，团队合作才是真正制霸武林的密宝。再好的程序员也敌不过一个好的团队，这本书讲的也是一个好的团队成员应具备的素质。

下面就是学习时做的笔记了。

1.做事

指责不能修复bug。

2.欲速则不达

修复代码时杜绝+-1，保持代码易读性。

3.对事不对人

要对自己说的话负责任。

4.排除万难，奋勇前进

要敢于进行代码重够，那是一件好事情。

5.跟踪变化

如果你一直在学习，恭喜你，你已经把昨天的技术学会了。

6.对团队投资

团队中只有自己优秀，实际上对自己和团队都是损失。

7.懂得丢弃

乐于学习新东西，并丢弃阻碍前进的东西。

8.打破沙锅问到底

这是个好习惯，往往能够找到问题发生的根源。问提要有质量，别纠缠没水准的问题。

9.把握开发节奏

注重节奏和循环，理解时间盒，并保持事件之间稳定重复的间隔。

10.让客户做决定

充分了解用户的想法和需求及时跟用户沟通，做用户想要的软件，开发者不应想当然的做。

11.让设计指导而不是操纵开发

设计就是战略，满足实现即可，不要过于详细。

12.合理地使用技术

不要开发能下载到的东西，也不要乱使用”技术”，使用新技术前应权衡利弊。

13.保持可发布

对于自己修改过的代码应保证可以正常编译运行并不影响其他人。确保程序可持续发布。

14.提早集成，频繁集成

不要等到都”所有”的工作都做好了才开始merge，也不要改一点整合一次系统。

15.提早实现自动化部署

工欲善其事，必先利其器。提早实现自动安装部署，方便给测试成员或者用户进行演示，并方便产品在其他机器上安装部署。（我能想到小的东西是Makefile，大的就是安装和维护脚本了）

16.使用演示获得频繁反馈

定期给客户演示交流，获得最准确和最新的需求，避免后期返工或者不能交付的问题。

17.使用小迭代，增量发布

对付大项目，最理想的办法就是小步前进，这也是敏捷方法的核心。不应该期望一下子做出最完美的软件，迭代尽快完成必要的功能才能保证程序开发平稳进行。迭代让人感到专注和效率。

18.固定的价格就意味着背叛承诺

产品价格和开发时间的评估对于没很多经验的团队来说是个难事，为了避免出现问题，可以同客户一起迭代，迭代评估，迭代开发，迭代付款，从而积累评估经验，保障对客户的承诺。

19.守护天使

自动化单元测试！key Word:桩程序，就是一些用来查看运行状态的代码行。单元测试：运用单元测试可以快速的找到问题出现的位置以及原因。

20.先用它再实现它

好的设计并不意味着需要更多的类，先“向后“做测试再实现。Key Word：TDD(Test Driven Development)。

21.不同环境，就有不同问题

所开发程序的兼容性问题，在其他环境下可能不会如预期一样工作，通过持续集成工具便会快速找到问题所在。

22.自动验收测试

对于测试的数据可以用一些易于修改的文本文件或者excel导入，来简化测试过程。

23.度量真实的进度

不要用不恰当的度量来欺骗自己或者团队。要评估那些需要完成的待办事项。对自己的任务进行时间估算，在估算后对自己的评估进行评价，计算评估系数（完成时间/估算时间）。在下一次估算的时候可以考虑将估算的时间*估算系数。这样时间久了，估算的会越来越准（除非是异常情况）。

24.倾听用户的声音

没有愚蠢的客户，只有愚蠢自大的开发人员。当用户遇见问题时应积极配合，找出出现问题的真正原因，即使不是程序的bug，也可能是文档或者使用的bug。

25.代码要清晰的表达意图

PIE原则，代码要清晰的表达意图，不要用int result = val << 1;来代替 int result = val * 2;这种小聪明。用枚举来代替状态值是个好主意。要编写清晰的代码而不是讨巧的代码。应该让自己或团队的任何其他任何人可以读懂自己一年前写的代码，而且只读一遍就知道它的运行机制。

26.用代码沟通

好的命名可以让人们更好的阅读代码，甚至可以不用注释都能让人读懂程序。好的代码胜过好的注释。

27.动态评估取舍

不单单是编程，平衡是一个非常重要的东西。

28.增量式编程

不要长时间出于编写代码状态，要时不时编译测试一下，保证自己不会偏离终点太远。要休息的话，就要好好休息。休息时请远离键盘。

29.保持简单

让人看过代码之后觉得简单不是件坏事，做同样的事情，如果简单的方法和代码能够达到效果那是件好事。开发可以工作的、最简单的解决方案。

30.编写内聚的代码

不要把所有的东西都写到一个类里，也不应该把每个东西都写一个类。

31.告知，不要询问

不要抢别的对象或是组件的工作。告诉它做什么，然后盯着你自己的职责就好了。Key Word:命令与查询相分离模式（command-query separation）

32.根据契约进行替换

要遵守Liskov替换原则，相对基类的对应方法，派生类服务（方法）应该不要求更多，不承诺更少；要可以进行自由的替换。针对is-a关系使用继承；针对has-a或uses-a关系使用委托（聚合）

33.记录问题解决日志

daylog：问题发生解决后，更新一篇日志，方便日后查找。日志不宜过长（时间最好不要超过解决问题用的时间）

34.警告就是错误

有些时候犯的错误不是语法错误，很可能是语义错了。不应忽略警告的重要性。

35.对问题各个击破

识别复杂问题的第一步，是将他们分离出来。

36.报告所有的异常

不要给使用者留下什么麻烦，报告所有的异常。

37.提供有用的错误信息

错误信息一方面要提供给用户清晰、易于理解的问题描述和解释，另一方面还要提供具备关于错误的详细技术细节给用户，这样方便开发人员找代码中真正的问题所在。（错误类型：程序缺陷、环境问题、用户错误）

38.定期安排会面时间

立会可以让团队达成共识。保证会议短小精悍不跑题。

39.架构师必须写代码

优秀的设计从积极的程序员哪里开始演化。不要使用不愿意编程的架构师——不知道系统的真实情况是无法展开设计的。

40.实现代码集体所有制

保证公司内的任何代码有2个以上人了解。任何一位团队成员，只要理解某段代码的来龙去脉，就可以对其进行处理。如果某一段代码只有一位开发人员能够处理，项目的风险无形也就增加了。

41.成为指导者

赠人玫瑰，手有余香。在分享知识的同时往往能给自己新的灵感，并且提高了团队的实力，增加团队的氛围。

42.允许大家自己想办法

基于上一习惯，作为指导者，应该鼓励、引导大家思考如何解决问题，而不是直接给出你的答案。如果有人提出来某些想法，不妨帮他们分析每种想法的优劣之处，从而采纳最下的方案，这对双方来说都是个学习的机会。

43.准备好后再共享代码

不该提交未完成的代码（无法编译，功能未完，携带bug等），这会对使用版本库的其他团队成员造成很大的影响。

44.做代码复查

对于提升代码质量和降低错误率来说，代码复查是无价之宝。代码复查的三种方式：通宵复查、捡拾游戏、结对编程（推荐）。

45.及时通报进展与问题

及时汇报自己的进度，不论是快了还是慢了，让负责人有个合理的期望，对全局有个有效的控制。

等以后经验多了，还要拿这本书出来再钻研一下才是。