整理了一下《代码整洁之道–程序员的职业素养》中一些受益匪浅的观点。
第一章 专业主义
-
清楚你想要什么 -
承担责任 -
了解你的领域
失误率永远不能等于0，但你有责任让它无限接近于零。
每个专业软件开发人员必须了解的技能：
-
设计模式。必须能够描述GOF书中的全部24种模式。 -
设计原则 必须了解SOLID原则，深刻理解组件设计原则 -
结构图 ?流程图 ?决策表 ?状态迁移图表
第二章 说“不”
大多数时间我们都希望能够说“是”。健康的团队都会努力寻找给他人肯定的答复。运作良好的团队经理和开发人员，会相互协商，直到达成共同认可的行动方案。
但是有时候，获取正确决策的唯一途径，便是勇敢无畏的说“不”。这个是比说“是”更负责任，更专业，也更困难的能力。
第三章 说“是”
-
遵守承诺 -
如果这个事情依赖他人，无法掌控，需要采取一些具体行动来达成目标。比如坐下来讨论一下具体行动，来一步一步接近目标，直至完成目标。 -
如果确实无法完成，赶紧去调整别人对你的预期，越快越好
第四章 编码
给他人提供帮助并非说明你更聪明，而是你带来了一个新的视角，对解决问题起到了显著的催化作用。PS：事实上能够提供完善的解决方案，一眼看出问题出在什么地方也是一种可贵的能力和丰富经验的累积。
辅导年轻的程序员是经验丰富程序员的职责所在，向资深的导师寻求帮助也是年轻程序员的专业职责。
第五章 ?TDD的三项法则
-
在编写好失败单元测试之前，不编写任何产品代码 -
只要有一个单元测试失败了就不需要再写测试代码;无法通过编译也是一种失败情况 -
产品代码恰好能够让当前失败的单元测试通过即可，不要多写。
TDD可以提升代码确定性、降低代码缺陷率，优化文档和设计的原则。
测试先行，会迫使你去思考什么是好的设计。
事后测试只是一种防守，先行编写测试则是进攻。事后编写的测试已经受制于已有代码，已经知道问题是如何解决的。测试先行的防守编写测试代码比起来，后写的测试在深度和捕获错误的灵敏度方面要逊色很多。
第六章 练习-自身经验的扩展
老板的职责不包括避免你的技术落伍，也不包括为你打造一份好看的简历。保持自己的技能不落伍是自己的责任。
第七章 验收测试
做业务和写程序的人都容易陷入一个陷阱：过早进行精细化。
- 不确定性原则
东西画在纸上与真正做出来，是不一样的。业务方看到真正运行的情况就会意识到，自己想要的东西根本不是这样。
一看到已经满足的需求，关于到底想要什么，他们就会有更好的想法——通常并不是他们当时想看到的样子。
- 预估焦虑
即便拥有全面准确的信息，评估也通常会存在巨大的变数。其次，因为不确定原则的存在，不可能通过反复推敲实现早起的精准性。需求一定会变化的，所以过早追求精确性是徒劳的。
身为专业开发人员，你的职责是协助开发团队开发出最棒的软件。也就是说每个人都需要关心错误和疏忽，并协助改正。
验收测试和单元测试
验收测试是业务方的，是正式的需求文档，描述了业务方认为系统应该如何运行。关心验收测试结果的是业务方和程序员。
单元测试是程序员写给程序员的，它是正式的设计文档，描述了底层结构和代码行为，关心单元测试结果的只是程序员。
它们的主要目的是如实描述系统的设计、结构和行为。当然他们也可以验证设计、结构和行为是否达到了具体指标，但是它们的真正价值不是在测试上，而是在具体指标上。
第八章 测试策略
尽管公司可能设有独立的QA小组专门负责测试软件，但是开发小组仍然要把“QA应该找不到任何错误”作为努力的目标。
对于QA找到的每一个问题，开发团队都应高度重视，认真对待。应该反思为什么出现这种错误，并采取措施避免今后重犯。
第九章 时间管理
关于会议，有两条真理
-
会议是必需的 -
会议浪费了大量的时间
在走入死胡同后可以快速意识到，并且有勇气走回头路。这就是坑法则：如果你掉进了坑里，别挖。
第十章 预估
当发现预估的时间不足时，最重要的是努力解决这个问题，并向外部同步进展。
预估真正的问题在于：业务方认为是承诺，开发方认为是猜测。
不要给出承诺，除非你确切知道可以完成。
第十二章 协作
你需要理解手上正在编写的代码业务价值是什么，了解雇佣你的企业将如何从你的工作中获得回报。
对做的事情充满激情是好的，但是，最好把注意力集中到付我们薪水的老板所追求的目标上。(关注业务和业务目标)
|