Robert C.Martin 著

第1章 专业主义

1.1 清楚你要什么

专业主义：它不但象征着荣誉与骄傲，而且明确意味着责任义务与担当。

1.3 首先，不行损害之事

1.3.1 不要破坏软件功能

写一些随时都能运行的单元测试，然后尽可能多地执行这些测试。测试覆盖率尽可能为100%。

1.3.2 不要破坏结构

• 结构良好的代码更灵活。以牺牲结构为代价，得不偿失，将来必追悔莫及。
• 如果希望自己的软件灵活可变，那就应该时常修改它！
• 有种策略叫“无情重构”：对每个模块，每检入一次代码，就要让它比上次检出时变得更简洁。每次读代码，都别忘了进行点滴的改善。
• 对待代码，就如同雕塑家对待泥巴那样，要对它进行不断的变形与塑造。

1.4.1 了解你的领域

• 设计模式。GOF 24种。
• 设计原则。SOLID原则，组件设计原则。

1.4.3 练习

每日10分钟卡塔。

第2章 说不

• 专业人士敢于说明真相而不屈从于权势。
• 只有敢于说不，才能真正做成一些事情。

2.1 对抗角色

最好的结果是你和你的经理追求共同的目标。最关键的是要找到那个共同目标，而这往往有赖于协商。

2.2 高风险时刻

• 最要说“不”的是那些高风险的关键时刻。越是关键时刻，“不”字就越具价值。

2.4 说“是”的成本

• 有时候，获取正确决策的唯一途径，便是勇敢无畏地说出“不”字。

2.5 如何写出好代码

• 想成为风云为物或救世主有时会让你做出一些不专业的行为
• 专业人士之所以成为英雄为物，是因为他们出色地完成了任务，不但按时而且符合预算。

第3章 说是

3.3 结论

专业人士不需要对所有请求都回答“是”。不过，他们应该努力寻找创新的方法，尽可能做到有求必应。

第4章 编码

4.2.2 中断

• 结对是应对中断的一种好方法。结对搭档能够维护住中断处的上下文。
• 另一种很有帮助的采用TDD。失败的测试能帮你维护住编码进行的上下文。

4.3 阻塞

• 创造性输出依赖于创造性输入。

4.4 调试

• 不管是否采纳TDD或其他一些同等效果的实践，衡量你是否是一名专业人士的一个重要方面，便是看你是否能将调试时间尽量降到最低。

4.6 进度延迟

4.6.2 盲目冲刺

• 如果经理极力要求你尽力赶上最后截止期限，那该怎么办呢？坚决维持你的估算!
• 唯一能够加快进度的方法便是缩减范围。

4.6.3 加班加点

不应该采用额外加班加点的工作方案，除非以下三个条件都能满足：

1. 你个人能挤出这些时间。
2. 短期加班，最多加班两周。
3. 你的老板要有后备预案，以防万一加班措施失败了。

4.7 帮助

• 作为业传人士，要以能够随时帮助别人为荣。
• 如果有人向你伸出援手，要诚挚接受，心怀感激地接受帮助并诚意合作。

第5章 测试驱动开发

5.2 TDD的三项法则

1. 在编好失败单元测试之前，不要编写任何产品代码。
2. 只要有一个单元测试失败了，就不要再写测试代码;无法通过编译也是一种失败情况。
3. 产品代码恰好能够让当前失败的单元测试成功通过即可，不要多写。
   这两个循环不断反复。写一些测试代码，然后再写一些产品代码。这两套代码同步增长，互为补充。

5.3 TDD的优势

5.3.3 勇气

• 拥有一套值得依赖的测试，便可完全打消对修改代码的全部恐惧。

5.3.4 文档

• 单元测试即是文档。

5.3.5 设计

• 遵循三项法则并且测试先行，便能够产生一种驱动力，促使你做出松耦合的设计。

第6章 练习

6.2 编程柔道场

6.2.1 卡塔

• 真正的挑战是把一个卡塔练习到炉火纯青，你可窥见其中的韵律。
• some kata

http://katas.softwarecraftsmanship.org/
http://codekata.pragprog.com/

6.3 自身经验的拓展

6.3.1 开源

• 保持不落伍的一种方法是为开源项目贡献代码，就像律师和医生参加公益活动一样。如果你是Javat程序员，请为Rails项目做点贡献。如果你为老板写了很多C++，可以找一个Python项目贡献代码。

第7章 验收测试

7.2 验收测试

• 我们把验收测试定义为业务方与开发方合作编写的测试，其目的在于确定需求已经完成。

7.2.1 完成的定义

• 应该编写整套自动化测试，它们全都通过，就意味着满足了所有的要求。如果对功能的验收测试全部通过，就算真正完成了。

7.2.3 自动化

• 验收测试都应当自动进行。在软件开发周期中，确实有时候需要手动测试，但是验收测试不应当手动进行，原因很简单：要考虑成本。
• 工具：FitNesse, Cucmber, robot framework, Selenium。

7.2.5 验收测试什么时候写，由谁来写

• 在理想状态下，业务方和QA会协作编写这些测试，程序员来检查测试之间是否有冲突或矛盾。
• 如果只能由开发人员来写测试，应当确保写测试的程序员与开发所测试功能的程序员不是同一个人。
• 通常，业务分析员测试“正确路径”，以证明功能的业务价值;QA则测试“错误路径 ”、边界条件、异常、例外情况，因为QA的职责是考虑哪些部分可能出问题。

7.2.6 开发人员的角色

• 开发人员有责任把验收测试与系统联系起来，然后主这些测试通过。

7.2.7 测试的协商与被动推进

• 与编写测人协商并改进测试是开发人员的职责。绝不能被动接受测试。

7.2.8 验收测试和单元测试

• 验收测试不是单元测试。单元测试是程序员写给程序呗的，它是正式的设计文档，描述了底层结构及代码的行为。关心单元测试的是程序员而不是业务员。
• 尽管两者测试的可能是同一个对象，其机制和路径却是不同的。单元测试是系统内部进行，调用特定类的方法;验收测试是在系统外部，通常是在API或者是UI级别进行。

7.2.10

• 请务必确保在持续集成系统中，单元测试和验收测试每天都能运行好几次。整套系统应该由源代码管理系统来触发。只要有人提交了代码，持续集成系统就会开始构建，并运行所有的测试。
• 持续集成如果失败了，团队里的所有人应该停下手里的活，看看如何让测试通过。

第8章 测试策略

8.2 自动化测试金字塔

image

第9章 时间管理

9.1 会议

9.1.4 立会

• 到场人依次回答以下3个问题：1.我昨天干了什么？2.我今天打算干什么?3.我遇到了什么问题? 每个人的发言不超过1分钟。

9.1.7 争论/反对

• Kent Beck：凡是不能在5分钟内解决的争论，都不能靠辩论解决。
• 争论之所以要花那么多时间，是因为各方都拿不出足够有力的证据。所以这类争论依据的不是事实，而是信念。
• 在没有数据的情况下，如果观点无法在适时间(5~30分钟)里达成一致，就永远无法达成一致。唯一的出路是，用数据说话。
• 如果争论必须解决，就应当要求争论各方在5分钟内向大家摆明问题，然后大家投票。

9.3 时间拆分和番茄工作法

• 番茄工作法的基本思想：把计时器设定到25分钟。倒计时期间不要让任何事情干扰你的工作。无论什么干扰，都必须等到25分钟结束再处理。
• 一天中，不错的情况下你可以有12_{14个番茄时间段，糟糕的情况下可能人有2}3个。把情况记录下来并且画图表示，就可以很清楚地知道每天有多少时间是有效率的，有多少时间是花在杂事上的。

第10章 预估

10.1.1 承诺

承诺是必须做到的。专业开发人员不随便承诺，除非他们确切知道可以完成。

10.2 PERT

PERT(计划评审技术)的一部分内容就是对预估的计算方法。这种技术包含了一个非常简单有效的办法，把预估变成概率分布。你可以根据3个数字预计某项任务。这就是三元分析法：

• O: 乐观预计。为保证乐观预估有意义，这个数据对应的发生概率应当小于1%。
• N：标称预估。这是最大概率的数字。
• P：悲观预估。为保证悲观预估有意义，这个数据对应的发生概率应当小于1%。
  有了以上三个预估，我们可以这样描述概率分布：

μ = (O+4N+P)/6

μ是任务的期望完成时间。

σ = (P-O)/6

σ是这个任务概率分布的标准差，用来衡量不确定性。如果这个数字很大，就表示非常不确认。

大任务的μ 可由各小任务μ 加和得到。大任务的σ等于各小任务σ的平方和再开方。

第11章 压力

11.1 避免压力

• 应当避免对没有把握能够达成的最后期限做出承诺。
• 专业人士总会千方百计地帮助业务方找到达成目标的方法，但并不一定要接受业务方代为做出的承诺。
• 快速前进确保最后期限的方法，便是保持整洁。
• 选择那些你在危机时间依然会遵循的纪律原则，并且在所有工作中都遵守这些纪律。

11.3 结论

• 应对压力的诀窍在于，能回避压力时尽可能地回避，当无法回避则则勇敢直面。可以通过慎重承诺，遵循自己的纪律原则、保护整洁等来回避压力。直面压力时，则要保持冷静，与别人多多沟通，坚守自己的原则纪律，并寻求他人的帮助。

第12章 协作

12.1 程序员与人

12.1.1 程序员与雇主

• 对做的事情充满激情是好的，但是，最好把注意力集中在付我们薪水的老板所追求的目标上。
• 专业程序员最糟糕的表现是两耳不闻窗外事，只顾一头将自己埋在技术堆里，甚至公司业务火烧眉毛行将崩溃了也不闻不问。
• 专业程序员会花时间去理解于业务。他们会和用户讨论他们正在使用的软件，会和销售人员与市场人员讨论所遭遇的问题，会和经理们沟通，明确团队的短期目标和长期目标。

12.1.2 程序员与程序员

• 专业人士结对工作，因为这是分享知识的最好途径。专业人士不会仅凭一已之力从零开始创建知识，而是通过互相结对来学习系统的不同部分和业务。
• 结对是复查代码最好的方式

12.3 结论

• 如果我们真想终生能以编程度日，那么，一定要学会交流。

第13章 团队与项目

13.1.1 有凝聚的团队

• 有凝聚力的团队通常约有12名成员。最多可以有20人，最少可以只有3人，但是12个人是最好的。这个团队应该程序员，测试人员和分析师，同时还要有一名项目经理。
• 程序员算一组，测试人员和分析师算一组，2:1是比较好的组合。由12个人组成的理想团队，人员配备情况是这样的：7名程序员，2名测试人员，2名分析师和1名项目经理。

13.2 结论

• 团队比项目更难构建。困此，组建稳健的团队，让团队在一个又一个项目中整体移动共同工作是较好的做法。团队也可以同时承接多个项目。在组建团队时，要给予团队充足的时间，让他们形成凝聚力，一直共同工作，成为不断交付项目的强大引擎。

第14章 辅导、学徒期与技艺

• 学校能够传授的是计算机编程的理论。但是学校并不会也无法传授作为一名编程匠者所需掌握的原则，实践和技能。这些东西只有经由师徒个体间多年的细心监督和辅导才能获得。
• 对新人的培养的辅导非常重要
• 学徒/实习生-->熟练工(5年左右)-->大师(10年以上)。大师就像星际迷航中的Scotty。