读书笔记----《代码整洁之道》

关于本书的一些观点和笔记

什么是软件专业人士？

软件专业人士的精髓在于将公司利益视同个人利益，意味着担当责任，你无法负责的事情不可能获得荣耀与骄傲。

对于完成的定义：代码写完，测试通过，QA和需求方已经认可

软件人员如何体现专业？

1.bug难以避免，但要对bug负责。

2.让QA找不出任何问题

3.要确信代码正常运行，自测

4.不要为了进度而随意堆砌代码，对待代码就如同雕塑家对待泥巴一样，要对它进行不断的与塑造

职业道德

1.职业发展是你自己的事，雇主没有义务确保你在职场能立于不败之地，也没有义务培训你，送你参加各种会议或给买各种书籍充电。这些都是你自己的事，将自己的职业发展寄希望于雇主的软件开发人员将会很惨

2.做为软件开发人员，就要了解自己的领域，精通 设计模式、设计原则、方法、实践、工具，并坚持学习，可以练习，学会与同事合作，乐于帮助他人，了解自己的业务领域

3.与雇主/客户保持一致

雇主的问题就是你的问题，每次开发系统，都应该站在雇主的角度来思考，确保开发的功能真正满足雇主的需要

沟通与承诺

承诺用语：口头上说，心里认真，付诸行动。

非承诺用语：应当/需要，希望/但愿，“让我们“而不是“让我”。

在讲话时，注意这些用语可进行判断

关于沟通

专业人士对自己的能力极限了如指掌，而优秀的经理人对敢于说“不”的人总是求贤若渴，因为只有敢于说“不”，才能真正做成一些事情。

“试试看”这个词，如果此前并未有所保留，没有新方案，如果你不会改变你的行动，如果你对自己原先的估计有充分的自信，那么，本质上将，承诺“尝试”就是一种不诚实的表现，你在说谎，你这么做的原因，可能是为了护住面子和避免冲突，牺牲专业原则以就全，并非问题的解决之道。

关于编码

不要在熬夜和焦虑状态写代码。

流态区：写代码时，渴望进入流态区，那种状态高度专注，但思维视野却会收拢到狭窄的状态，感觉效率极高，但实际不一定是。

遇到阻塞时，结对编程、需求帮助、转移注意力后再来写代码

写代码是属于创建性输出，应有创造性输入

软件开发是一场马拉松，保持节奏很重要

测试驱动开发（TDD）

TDD的三项法则，

1）在编好失败单元测试之前，不要编写任何产品代码

2）只要有一个单元测试失败了，就不要再写测试代码，无法通过编译也是一种失败情况

3）产品代码恰好能过让当前失败的单元测试成功通过即可，不要多写

TDD的优势

1）确定性，对所写代码更有把控感

2）缺陷率会降低

3）勇气，会更有勇气去改代码

4）文档，单元测试即文档

先写测试是一种进攻，后写测试是一种防守

测试策略

单元测试、组件测试、集成测试、系统测试、探索式测试

通常，业务分析员测试“正确路径”，以证明功能的业务价值，QA则测试“错误路径”、边界条件、异常例外情况，因为QA的职责是考虑哪些部分可能出问题

验收测试是业务方写给业务方的

单元测试程序员写给程序员的

单元测试与验收测试首先是文档，然后才是测试，它们的真正价值不在测试上，而在具体指标上

GUI与业务逻辑应该分开测试

预估工作量

德尔菲法：工作中的敏捷估点

PERT，概率分布的方式

O乐观预估 N标称预估 P悲观预估

压力

在压力下保持冷静的最好方式，便是规避会导致压力的处境

1）承诺，应当避免对没有把握能过达成的最后期限做出承诺

2）保持整洁，让系统、代码。设计尽可能整洁

3）危机中的纪律：在危机时刻依然会遵循的纪律原则，并且在所有工作中都遵守这些纪律

应对压力

1）不要惊慌失措

2）沟通

3）依靠你的纪律原则

4）需求帮助

协助

程序员与人：大多程序员更倾向于计算机打交道

程序员与雇主：雇主更看重结果与进度

程序员与程序员：

1）代码个体所有：尽量避免

2）协助下的代码共有权

3）结对编程

关于团队与项目

有凝聚力的团队，不要围绕项目来组件团队，而要把项目给有凝聚力的团队