《The Clean Coder》读书笔记
作者：互联网
序章
有时候，获取正确决策的唯一途径，便是勇敢无畏地说出“不”字......我们要明白，委屈专业原则以求全，并不是问题的解决之道。舍弃这些原则，只会制造出更多的麻烦......
第一章：专业主义
所有软件项目的根本指导原则是，软件要易于修改。如果违背这条原则搭建僵化的结构，就破坏了构筑整个行业的经济模型。
不能铭记过去的人，注定要重蹈覆辙。
每个软件开发人员必须精通的事项：
- 设计模式。必须能描述GOF书中的全部24种模式，同时还要有POSA书中的多数模式的实战经验。
- 设计原则。必须了解SOLID原则，而且要深刻理解组件设计原则。
- 方法。必须理解XP、Scrum、精益、看板、瀑布、结构化分析及结构化设计等。
- 实践。必须掌握测试驱动开发、面向对象设计、结构化编程、持续集成和结对编程。
- 工件。必须了解如何使用UML图、DFD图、结构图、petri网络图、状态迁移图标、流程图和决策表。
第二章：说“不”
在发现自己成为笑柄时，专业人士会第一个发笑。他从不会嘲讽别人，自作自受时他会接受别人的嘲讽。反之，他则会一笑了之。他不会因别人犯错误就对之横加损贬，因为他知道，自己有可能就是下一个犯错的人。
专业人士都清楚自己的自负，也知道上天会注意到这种自负，并加以惩戒。如若果真遭遇挫折，最好的办法就是按照霍华德说的-------一笑了之吧！
专业人士敢于说明真相而不屈从于权势。专业人士有勇气对他们的经理说“不”。
奴隶没有权利说“不”。劳工或许也对说“不”有所顾虑。但是专业人士应该懂得说“不”。事实上，优秀的经理人对于敢于说“不”的人，总是求贤若渴。因为只有敢于说“不”，才能真正做一些事情。
第三章：说”是“
今天的程序员坑定得去面对诸如估算、确定最后期限以及面对面交流等沟通活动。做出承诺或许听起来令人有点害怕，但它能够帮助程序员解决在沟通中可能发生的不少问题。如果你能够一直信守承诺，大家会以为你“是一名严谨负责的开发人员”。在我们这行中，这也是最有价值的评价。
专业人士不需要对所有请求都回答“是”。不过，他们应该努力寻找创新的方法，尽可能做到有求必应。当专业人士给出肯定回答时，他们会使用正式的承诺，以确保各方能明白无误地理解承诺的内容。
第四章：编码
如果感到疲劳或者心烦意乱，千万不要编码。强而为之，最终只能再回头返工。相反，要找到一种方法来消除干扰，让心绪平静下来。
疲劳的时候，千万不要写代码。风险精神和职业素养，更多意义上指要遵守纪律原则而非成为长时间工作的工作狂。要确保自己已经将睡眠、健康和生活方式调整到最佳状况，这样才能做到在每天的8小时工作时间内全力以赴。
埋头忙于解决问题时，有时候可能会由于和问题贴得太紧，无法看清楚所有的可选项，由于大脑中富有创造性的部分被紧张的专注力所抑制，你会错过很棒的解决方案。因此，有时候解决问题做好的方法是回家，吃顿好吃的，然后上床睡觉，再在第二天清晨醒来洗个澡。
第五章：测试驱动开发（TDD）
测试驱动开发的三个原则：
- 在编好失败单元测试之前，不要编写任何产品代码。
- 只要有一个单元测试失败了，就不要再写测试代码；无法通过编译也是一种失败情况。
- 产品代码恰好能够让当前失败的单元测试成功通过即可，不要多写。
第七章：验收测试
要解决开发方和业务方沟通的问题，我所知道的唯一有效的方法就是编写自动化的验收测试。这些测试足够正式，所以其结果有权威性。这些测试不会造成模糊，也不可能与真实系统脱节。它们，就是无可挑剔的需求文档。
第八章：测试策略
TDD很强大，验收测试是表达和强化需求的有效方式。但他们都只是整体测试策略的一部分。为了更好的做到“QA应该找不到任何错误”，开发团队要和QA紧密协作，创建由单元测试、组件测试、集成测试、系统测试和探索性测试构成的测试体系。应该尽可能频繁的运行这些测试，提供尽可能多的反馈，确保系统始终整洁。
第九章：时间管理
关于会议，有两条真理：
- 会议是必须的。
- 会议浪费了大量的时间。
专业开发人员同样清楚会议的高额成本，他们同样清楚自己的时间是宝贵的，他们同样需要时间来写代码，来处理日程表上的事务。所以，如果会议没有限时且显著的成效，他们会主动拒绝。
邀请你参加会议的人并不负责管理你的时间，为时间负责的只有你。所以，如果你收到会议邀请，务必确保出席会议可以给自己目前的工作带来切实且显著的成效，否则，不必参与。
会议并不总是按计划进行的。有时候你正参加某个会议，但是发现如果之前对此会议知道的多一点，就不会来。还有时候，会议临时增加了议题，或者某个讨厌的家伙霸占了讨论。这些年来，我学到了一条简单的规则：如果会议让人厌烦，就离席。你可以解释说，自己抽不出更多的时间用于这场会议，问问有没有办法加快讨论，或者另选时间。
敏捷开发的武器库中包含“立会”：在开会时，所有参会者都必须站着。到场的人依次回答以下三个问题：
- 我昨天干了什么？
- 我今天打算干什么？
- 我遇到了什么问题？
专业开发人员会用心管理自己的时间和注意力。他们知道优先级错乱的有货，他们也诊视自己的声誉，所以会抵制优先级错乱。他们永远有多种选择，永远敞开心扉听取其他解决方案，他们从来不会执拗于某个无法放弃的解决方案。他们也时刻警惕着正在显露的泥潭，一旦看清楚，就会避开。最糟糕的事情，莫过于看到一群开发人员在徒劳的拼力工作，结果却陷入越来越深的泥潭。
第十章：预估
专业开发人员懂得如何为业务人员提供可信的预估结果，以便做出计划。如果做不到，或者不确定能做到，专业开发人员不会给出承诺。
专业开发人员一旦做了承诺，就会提供确定的数字，按时兑现。但是大多数情况下，他们都不会做这种承诺，二是提供概率预估，来描述期望的完成时间及可能的变数。
对需要妥善对待的预估结果，专业开发人员会与团队的其他人协商，已取得共识。
第十一章：压力
在压力下保持冷静的最好方式，便是规避会导致压力的处境。规避的方式也许无法完全检出压力，但是可以大大降低压力并缩短高压力期的时间。
让系统、代码和设计尽可能整洁，就可以避免压力。这并非是说我们要花无情无尽的时间去清理代码，而只是说不要容忍混乱。混乱会降低速度，导致工作延误，承诺失信。因此，要尽力保持输出成果整洁干净。
应对压力的诀窍在于，能回避压力时尽可能的回避，当无法回避时则勇敢直面压力。可以通过慎重承诺、遵守自己的纪律原则、保持整洁等来回避压力。直面压力时，则要保持冷静，与别人多多沟通，坚守自己的原则纪律，并寻求他人的帮助。
第十二章：协作
我们并非是喜欢和其他人在一起工作才选择做程序员的。我们都认为人际关系难以应付而且毫无规律。编程用的机器整洁，行为也可预见 如果一个人可以待在房间里数十个小时沉浸在一些真正有趣的问题上，那将会是最开心的时光。
第十三章：团队与项目
理想团队是由12名成员组成的，7名程序员，2名测试人员，2名分析师和1名项目经理。
团队比项目更难构建。因此，组件稳健的团队，让团队在一个有一个项目中整体移动共同工作是较好的做法。并且，团队也可以同时承接多个项目。在组建团队时，要给予团队充足的时间，让他们形成凝聚力，一直共同工作，成为不断交付项目的强大引擎。
附录：工具
永远不要迁入没有通过全部测试的代码，永远不要。
标签：Coder,Clean,原则,开发人员,读书笔记,会议,测试,压力,团队 来源： https://www.cnblogs.com/smallbuilding/p/16590197.html