整理了一下《代码整洁之道–程序员的职业素养》中一些受益匪浅的观点。

第一章 专业主义

1. 清楚你想要什么

2. 承担责任

3. 了解你的领域

失误率永远不能等于0，但你有责任让它无限接近于零。

每个专业软件开发人员必须了解的技能：

1. 设计模式。必须能够描述GOF书中的全部24种模式。

2. 设计原则 必须了解SOLID原则，深刻理解组件设计原则

3. 结构图  流程图  决策表  状态迁移图表

第二章 说“不”

大多数时间我们都希望能够说“是”。健康的团队都会努力寻找给他人肯定的答复。运作良好的团队经理和开发人员，会相互协商，直到达成共同认可的行动方案。

但是有时候，获取正确决策的唯一途径，便是勇敢无畏的说“不”。这个是比说“是”更负责任，更专业，也更困难的能力。

第三章 说“是”

1. 遵守承诺

2. 如果这个事情依赖他人，无法掌控，需要采取一些具体行动来达成目标。比如坐下来讨论一下具体行动，来一步一步接近目标，直至完成目标。

3. 如果确实无法完成，赶紧去调整别人对你的预期，越快越好

第四章 编码

给他人提供帮助并非说明你更聪明，而是你带来了一个新的视角，对解决问题起到了显著的催化作用。PS：事实上能够提供完善的解决方案，一眼看出问题出在什么地方也是一种可贵的能力和丰富经验的累积。

辅导年轻的程序员是经验丰富程序员的职责所在，向资深的导师寻求帮助也是年轻程序员的专业职责。

第五章  TDD的三项法则

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

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

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

TDD可以提升代码确定性、降低代码缺陷率，优化文档和设计的原则。

测试先行，会迫使你去思考什么是好的设计。

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

第六章 练习-自身经验的扩展

老板的职责不包括避免你的技术落伍，也不包括为你打造一份好看的简历。保持自己的技能不落伍是自己的责任。

第七章 验收测试

做业务和写程序的人都容易陷入一个陷阱：过早进行精细化。

1. 不确定性原则

东西画在纸上与真正做出来，是不一样的。业务方看到真正运行的情况就会意识到，自己想要的东西根本不是这样。

一看到已经满足的需求，关于到底想要什么，他们就会有更好的想法——通常并不是他们当时想看到的样子。

2. 预估焦虑

即便拥有全面准确的信息，评估也通常会存在巨大的变数。其次，因为不确定原则的存在，不可能通过反复推敲实现早起的精准性。需求一定会变化的，所以过早追求精确性是徒劳的。

身为专业开发人员，你的职责是协助开发团队开发出最棒的软件。也就是说每个人都需要关心错误和疏忽，并协助改正。

验收测试和单元测试

验收测试是业务方的，是正式的需求文档，描述了业务方认为系统应该如何运行。关心验收测试结果的是业务方和程序员。

单元测试是程序员写给程序员的，它是正式的设计文档，描述了底层结构和代码行为，关心单元测试结果的只是程序员。

它们的主要目的是如实描述系统的设计、结构和行为。当然他们也可以验证设计、结构和行为是否达到了具体指标，但是它们的真正价值不是在测试上，而是在具体指标上。

第八章 测试策略

尽管公司可能设有独立的QA小组专门负责测试软件，但是开发小组仍然要把“QA应该找不到任何错误”作为努力的目标。

对于QA找到的每一个问题，开发团队都应高度重视，认真对待。应该反思为什么出现这种错误，并采取措施避免今后重犯。

第九章 时间管理

关于会议，有两条真理

1. 会议是必需的

2. 会议浪费了大量的时间

在走入死胡同后可以快速意识到，并且有勇气走回头路。这就是坑法则：如果你掉进了坑里，别挖。

第十章 预估

当发现预估的时间不足时，最重要的是努力解决这个问题，并向外部同步进展。

预估真正的问题在于：业务方认为是承诺，开发方认为是猜测。

不要给出承诺，除非你确切知道可以完成。

第十二章 协作

你需要理解手上正在编写的代码业务价值是什么，了解雇佣你的企业将如何从你的工作中获得回报。

对做的事情充满激情是好的，但是，最好把注意力集中到付我们薪水的老板所追求的目标上。(关注业务和业务目标)