《Clean Coder》读书笔记

第一章 专业主义

 1.1 清楚你要什么

非专业人士不需要为自己所做的工作负责，他们大可把责任推给雇主。而专业人士如果犯了错，只好自己收拾残局。

如果你不小心放过了某个bug导致公司损失了1万美金。 非专业人士会说“难免要出点状况的嘛”然后没事人一样继续写其他模块。而专业人士会自己为公司的那1万美金买单。

专业主义的精髓就在于将公司的利益视同个人利益。“专业主义”就意味着担当责任。

 1.2 担当责任

如果项目有风险时间不够，应该告诉经理，测试还未完成、自己不能按时交付产品，那样经理一定会不开心，但是客户不会因此有糟糕的体会，经理也不会有客户的投诉。

 1.3 不行损害之事

要做的专业，就不能留下bug.

专业人士，就是能对自己犯下的错误负责的人，哪怕那些错误实际上在所难免。所以，雄心勃勃的专业人士要做的第一件事就是“道歉”。失误率永远不可能等于零，但是你有责任让它无线接近零。

1.让QA找不出任何问题

故意发送明知有缺陷的代码，这种做法是极其不专业的。什么样的代码是有缺陷的呢？那些你没有把握的代码都是！

每次QA找出问题时，更糟糕的hi用户找出问题时，你都应该震惊羞愧，并决心以此为戒。

2.要确信代码正常运行

你怎么知道代码能否正常运行呢，很简单，测试！

写一些随时都能运行的单元测试，然后尽可能多的执行这些测试。

要用这些自动化单元测试去测多少代码呢？全部！ 全部都要测！

你写的每一行代码都要测试。

1.3.2 不要破坏结构

成熟的专业开发人员知道，聪明人不会为了发布新功能而破坏结构。结构良好的代码更灵活。以牺牲结构为代价，得不偿失，将来必定追悔莫及。

对每个模块，每检入一次代码，就要让它比上次检出时变得更为简洁。每次读代码，都别忘了进行点滴的改善。如果一直不重构代码，等到最后不得不重构时，你就会发现代码已经”僵化了“。

1.4 职业道德

雇主付了钱，你就必须为此付出时间和精力。以每周40个小时的工作时间为例，这40个小时是用来解决雇主的问题，而不是你自己的问题。

你应该计划每周工作60 小时。前40 小时是给雇主的，后20小时是给自己的。在这剩余的20小时里，你应该看书、练习、学习，或者做其他能提升职业能力的事情。

一周有168个小时，你给你的雇主40小时，为自己的职业发展留20小时，剩下的108小时再留56个小时给睡眠，那么还剩下52小时可以做其他的事情。

作者列出了每个专业软件开发人员必须精通的事项：

 设计模式。必须能够描述GOF 书中全部24中模式，同时还有POSA书中的多数模式的实战经验。
 设计原则。必须了解SOLID 原则，而且要深刻理解组件设计原则。
 方法。必须理解XP,Scrum,精益，看板，瀑布，结构化分析以及结构化设计等。
 实践。必须掌握测试驱动开发(TDD)，面向对象设计，结构化编程、持续集成和结对编程。
 工件。必须了解如何使用UML图、DFD图、结构图。Petri网络图，状态迁移图表、流程图和决策表。
1.4.2 坚持学习：

你会找那些已经不看医学期刊的医生看病嘛？你会聘请那些不了解最新税法和判例的税务律师嘛？那么雇主为什么要聘用那些不能与时俱进的开发人员呢？

如同你不会找那些已经不看医学期刊的医生看病一样， 不学习的程序员必然被淘汰。

1.4.6 了解业务领域

最糟糕、最不专业的做法是，简单按照规格说明来编写代码，但却对为什么那些业务需要那样的规格定义不求甚解。相反，你应该对这一领域有所了解，能辨别、质疑规格说明书中的错误。

第二章 和第三章

作者提出了专业的程序员应该知道何时说“不”何时说“是"。

在做出承诺之前应该充分考虑一下所有情况，（如，周末加班，添加人手等）。在此基础上，能就是能，不能就是不能。千万不要”试试看“。

如果无法兑现承诺，向团队发出预警，越快越好。

第三章 编码（coding）

代码需要满足的四个基本条件：

1. 代码必须能够正常工作。
2. 代码必须能够帮你解决客户提出的问题。
3. 代码必须能够和现有系统结合得天衣无缝。
4. 其他程序员必须能够读懂你的代码。

个人认为第4条最为重要。因为你不能能永远维护你自己写的代码，因此你必须让你的代码清楚的表达出它的意图。与其为了精简代码，导致他人难以理解你的代码，不如拆分你的代码，使他更为易于理解。

写代码是一种创造性的活动，尤其是写出好的代码。因此作为程序员应该多给自己一些”创造性的输入“（无差别的读一些有趣资料）来激发自己”创造性的输出“

当你遇到困难的时候，不妨离开一会儿。放空一下自己。让富有创造力的潜意识掌管问题。

采取加班加点的条件：

你个人能够挤出这些时间。

短期加班最多2周

你的老板有后备预案（以防万一加班的措施失败了）

第五章 TDD

事后补写测试是一种防守，事先编写测试是一种进攻。事后编写测试的作者已经受制于已有的代码，他已经知道问题是如何解决的。与采用测试先行的方式编写的测试代码比起来。后写的测试在深度和捕获错误的灵敏度方面都要逊色很多。

TDD的三项法则：

1. 在编好失败单元测试之前，不要编写任何产品代码。
2. 只要有一个单元测试失败了，就不要再写测试代码；无法通过编译也是一种失败的情况。
3. 产品代码恰好能够让当前失败的单元测试成功通过即可，不要多写

第七章

作者对“完成 ” 一词做了如下定义

专业的开发人员的”完成“只能有一个含义：完成意味着所有的代码都写完了，所有的测试都通过了，QA和需求方已经认可。这，才是完成。

你应该编写整套的自动化测试，它们全部通过就意味着买组了所有的要求。