代码整洁之道：程序员的职业素养 读书笔记_程序员的职业素养 robert c. martin

代码整洁之道：程序员的职业素养
作者：（美）罗伯特 C. 马丁（Robert C. Martin）
译者：余晟，章显洲

这是一本风趣幽默的关于程序员的故事书，这本书让我在专业技术之外，了解了更多程序员应有的能力和素质。

引言摘抄：本书是编程大师“Bob 大叔”40余年编程生涯的心得体会的总结，讲解要成为真正专业的程序员需要具备什么样的态度，需要遵循什么样的原则，需要采取什么样的行动。作者以自己以及身边的同事走过的弯路、犯过的错误为例，意在为后来者引路，助其职业生涯迈上更高台阶。

第一章 专业主义

什么是程序员的专业主义？

1. 担当责任，要对自己的错误负责。
2. 不要破坏软件功能，让 QA 找不出任何问题，确保代码正常运行。
3. 不要破坏代码结构，不可维护的代码显而易见的不专业。

第二章 说“不”

“有可能写出好代码吗，有可能坚守专业主义精神吗？”

你有没有遇到过在规定时间一定做不完的需求？在面对需求讨论的时候，我们和产品（或者说项目组，总之是发布任务的人）会形成一种对抗关系，这时候一定要坚持自己的观点（写不完就是写不完，不需要为此羞愧）。

在对抗过程中，事实要比 “为什么” 更重要，对方不一定有足够的技术水平和良好的脾气去倾听我们的想法。我们可以去更多的了解最核心需求，在有限的时间里做好最重要的事情。

对待不合理的需求时间，一定要坚决“不”。对项目中自己的工作有一个坚定的评估，是一种团队精神。千万不要给出犹豫不决的试试看，人总是会偏向更好的想法，对更差的可能视而不见。试试看对领导来说也是一种未尽全力的表述。而且在试试看的过程中为了尽快完成任务，很可能采取会复制粘贴、胡乱起变量名等等会破坏程序长久性的做法，维护的痛苦和成本都是潜在的工作量，并且会给领导留下这个人没有能力写出好代码的印象。

“是的，但你要学会如何说 ‘不’ ”。

第三章 说“是”

“口头上说。心里认真。付诸行动。”

1. 缺乏承诺的征兆

   需要（我需要减肥了。）
   应该（我应该能成功吧。）
   让我们（而不是让我，让我们把这事做完。）

   实际情况中，不仅我们同事，我们自己也会陷入类似的词语陷阱。只要认真搜寻，你会发现所有人都有竭力逃避责任的倾向。识别这样的言语，已经迈出了第一步。

2. 真正的承诺

   “我将在……之前……”（我将在周二之前完成工作。）

   做出承诺之后，我们就要继续下面两个步骤了 “言必信，行必果” 。

很多时候，我们是有借口不能完成承诺的。下面是一些常见的原因和解决方式：


1. 之所以没有成功，是因为寄希望某某做这件事情。
只承诺自己能完成的事情。如果自己的任务必须需要合作，那么可以承诺一些具体行动。比如：




2. 之所以没有成功，是因为我不确定能不能完成。
即使目标无法完成，仍然全力以赴，缩短和目标的距离。
如果我们一周修复 25 个 bug ，那么我们要和 QA 一起过一下这 25 个 bug ，先全部复现一遍，尝试逐一修复 （笔者言：有时候复现的时候，会少掉一部分 bug ，或者根本复现不出来，这时候就会很快乐。）。


3. 之所以没有成功，是因为真的无能为力。
提前预警。如果评估之后，真的不能完成承诺，像利益相关方提前发出预警。
如果不尽早告诉他人有可能呢的问题，就错失了他人帮助你达成目标、完成承诺的机会。

3. 学习如何说 “是” ，坚守原则。

   专业人士不需要对所有要求说 “是” ，但是也要尽可能做到有求必应。当专业人士给出肯定回答时，会使用正式的承诺，以确保各方都能明白无误的理解承诺内容。

第四章 编码

1. 做好准备

编码时一项颇有挑战的智力活动。相比其他类型的活动，编码要求更加聚精会神。因为在编码时你必须平衡多种因素。

（1）首先代码能够正常工作。
（2）代码必须能够解决客户提出的问题。很多时候，客户的需求并不难解决他的问题，这需要你与客户沟通。
（3）代码必须与现有的系统结合得天衣无缝。你的代码不能让系统更僵硬，更脆弱。
（4）其他程序员必须能读懂你的代码。比如注释……

无法全神贯注的编码，所写代码就可能出错。心烦意乱的工作，只会造成严重的浪费。

• 凌晨三点时写下的代码

  疲劳的时候，千万不要写代码。奉献精神和职业素养，更多意义上指要遵守纪律原则，而非要成为长时间工作的工作狂。

• 焦虑时写下的代码

  内心焦虑削弱工作效率，最好还是花时间安静下来。此时硬逼自己写代码，憋出来的代码也不得不抛弃（如果还要长期与之相伴，那就更糟糕了）。

2. 流态区

高效率状态，称之为“流态区”。不管用什么名字，你可能都不陌生，甚至有过这种体验。这是程序员在编写代码时会进入的一种意识高度专注但思维视野却会收拢到狭窄的状态。在这种状态下，会感到效率极高，但是，这种意识状态并非真的极为高效，也绝非毫无错误。这其实只是一种“浅层冥想”状态，在这种状态下，为了追求所谓的速度，理性思考的能力会下降。

可以通过走开一小段时间，来避免进入这种状态。比如看封邮件、去吃个午饭。
也可以去找一个结对编程的搭档（笔者言：作者非常推荐结对编程）。

3. 阻塞

死活写不出代码来的状态。
解决方案：

• 结对编程
• 创造性输入（抛开问题几个小时，去看或者做一些激励自己创造力的事情，比如阅读、听音乐、看电影、看电视）

4. 调试

通过测试驱动开发（TDD），减少代码的调试时间

5. 保持节奏

软件开发是一场马拉松，而不是短跑冲刺。你无法全程一直以最快的速度冲刺来赢得比赛，只有通过保存体力和维持稳定节奏来取胜。无论是赛前还是赛中，马拉松选手都会仔细调整好自己的身体状态。专业程序员也会同样仔细地保存好自己的精力和创造力。
知道什么时候应该离开一会，休息同样很重要

6. 进度延迟

• 期望：当期望时长达不到预估时长，那就一定完成不了工作，让团队和利益相关者明白这一点。
• 盲目冲刺：其实快速冲刺是做不到的。你无法更快地写完代码。你无法更快地解决问题。如果试图这么做，最终只会让自己变得更慢，同时也只能制造出一堆混乱，让其他人也慢下来。
• 加班加点：除非是短期加班，并且老板有加班失败的预备措施，你不应该接受加班的方案来赶进度。
• 交付失误：在程序员所能表现的各种不专业行为中，最糟糕的是明知道还没有完成任务却宣称已经完成。我们自己给自己找借口说，其他还没来得及完成的工作可以等有更充裕时间的时候再来处理。
• 定义完成：只有完全的通过验收测试才叫完成，不是仅仅写完了代码。

7. 帮助

• 帮助他人
• 接受他人帮助，主动寻求帮助
  
  

第五章 测试驱动开发（TDD）

即编程之前先写测试。

本节要点可以归结为一句话：TDD是专业人士的选择。它是一项能够提升代码确定性、给程序员鼓励、降低代码缺陷率、优化文档和设计的原则。对TDD的各项尝试表明，不使用TDD就说明你可能还不够专业。

TDD的三项法则

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

TDD的优势

（1）确定性：只要通过自动化测试，就有把握交付工作。
（2）缺陷注入率：显而易见，这种模式可以降低bug风险
（3）勇气：有完整的TDD，就很容易对待进行改动修复，而不用担心改动出问题来。
（4）文档：它们是最好的底层文档。它们描述了系统设计的最底层设计细节。
（5）设计：提前设计代码，避免了各种变量函数耦合的问题。

（笔者对这一部分不太了解，笔者的经验是在开发之前可以先写文档，以写代码的心态沉浸式写技术文档，可以用来技术评审，也可以用来做自己的开发指南，到真正写代码的时候，就很省力。）

第六章 练习

练习的道德

无论如何，专业人士都需要练习。他们这么做，是因为他们关心自己能做到的最好结果。更重要的是，他们用自己的时间练习，因为他们知道保持自己的技能不落伍是自己的责任，而不是雇主的责任。练习的时候你是赚不到钱的，但是练习之后，你会获得回报，而且是丰厚的回报。

推荐几个笔者练习的网站（前端）
力扣
牛客
Codewars

第七章 验收测试

交流细节信息是件麻烦事。尤其是开发方和业务方交流关于程序的细节时，更是如此。通常，各方握手言欢，以为其他人都明白自己的意思。双方以为取得了共识，然后带着截然不同的想法离开。
要解决开发方和业务方沟通问题，唯一有效的办法就是编写自动化的验收测试。这些测试结果有权威性，不会造成模糊，也不可能与真实系统脱节。它们，就是无可挑剔的需求文档。

第八章 测试策略

QA找不到任何错误

专业开发人员遵循测试驱动开发的要求来创建单元测试。专业开发团队使用验收测试定义系统需求，使用持续集成保证质量稳步提升；同时，这些测试又属于全局测试体系。拥有一套单元测试和验收测试的同时，还需要有更高层次的测试，这样QA才找不出任何错误。

TDD很强大，验收测试是表达和强化需求的有效方式。但它们都只是整体测试策略的一部分。为了更好地做到“QA应该找不到任何错误”，开发团队要和QA紧密协作，创建由单元测试、组件测试、集成测试、系统测试和探索式测试构成的测试体系。应该尽可能频繁地运行这些测试，提供尽可能多的反馈，确保系统始终整洁。

第九章 时间管理

8小时其实非常短暂，只有480分钟，28800秒。身为专业开发人员，需要在这短暂的时间里尽可能高效地工作，取得尽可能多的成果。
专业开发人员会用心管理自己的时间和注意力。他们知道优先级错乱的诱惑，他们也珍视自己的声誉，所以会抵制优先级错乱。他们永远有多种选择，永远敞开心扉听取其他解决方案，他们从来不会执拗于某个无法放弃的解决方案。他们也时刻警惕着正在显露的泥潭，一旦看清楚，就会避开。最糟糕的事情，莫过于看到一群开发人员在徒劳地拼力工作，结果却陷入越来越深的泥潭。

• 会议：礼貌的拒绝没有必要的会议；选个合适的时间，离开没有太多意义的会议；确定议程与目标；每日参加立会；参加迭代会议；参加迭代回顾与demo展示；
• 保证注意力点数：睡眠和适量的咖啡因可以保证充足的注意力点数；一旦注意力点数耗尽，就没有办法控制注意力了，因此适当的小憩、闲聊，漫步是必要的；定期训练肌肉注意力点数（瑜伽、健身、太极、木工活、清理花园），可以提升注意力上限；
• 时间拆分与番茄工作法：25分钟高效不受打扰的编程，这25分钟之后处理其他事情（比如回消息），休息五分钟；开启下一个循环。
• 评估优先级：专业开发人员会评估每个任务的优先级，排除个人的喜好和需要，按照真实的紧急程度来执行任务。
• 死胡同：在走入死胡同时，有足够的勇气走回头路

第十章 预估

专业开发人员懂得如何为业务人员提供可信的预估结果，以便做出计划。如果做不到，或者不确定能做到，专业开发人员不会给出承诺。
专业开发人员一旦做了承诺，就会提供确定的数字，按时兑现。但是大多数情况下，他们都不会做这种承诺，而是提供概率预估，来描述期望的完成时间及可能的变数。

PERT

PERT（Program Evaluation Review Technique)计划评审技术。它非常简单有效的把预估变为了概率分布。

可以根据3个数字预估某个任务

• O: 乐观预估。 异常顺利情况下的完成时间。通常为了使得乐观估计是有意义的，这个数字对方的发生概率应该小于1/1000。
• N: 标称预估。这是概率最大的数字，如果是柱状图，标称预估就是最高的那个。
• P: 悲观预估。这是最糟糕的数字。为了保证有效性，该数值的发生的概率也要小于1/1000。

有了以上三种评估，可以像下面一样描述概率分布：

μ = ( O + 4 N + P ) / 6 μ = (O + 4N + P) / 6μ=(O+4N+P)/6

μ表示任务期望的完成时间。

σ = （ P − O ) / 6 σ = （P-O)/6σ=（P−O)/6

σ是这个任务的概率分布标准差，用于衡量不确定性。

用μ/σ作为预估。

如果一个人同时参与多个任务，可以同时进行评估。

任务 乐观预估 标称预估 悲观预估 μ σ

把所有任务加和，得到所有的任务统计分布

μ(seq) = ∑μ(task)

对于依次完成的任务，总的期望完成时间就是这些任务的期望完成时间的和。 对上表来说，其预估4.2/1.8、3.5/2.2、 6.5/1.3，那么大概需要4.2 + 3.5 + 6.5 = 14天才能完成。

总的方差就是各个任务标准差平方之和的平方根，也就是1.8 * 1.8 + 2.2 * 2.2 + 1.3 * 1.3 再开根号，大约是3。

所以所有任务完成的时间大概需要14天，也有可能是17天(1σ)或者20天(2σ)，都有可能。

悲观估计将各个任务的不确定性都累加起来，让整个计划更加贴近真实。 PERT是一种较好的避免乐观预估的合理方法。

第十一章 压力

1. 避免压力

• 在压力下保持冷静的最好方式，便是规避会导致压力的处境
• 让系统、代码和设计尽可能整洁，就可以避免压力。不要容忍混乱。混乱会降低速度，导致工期延误，承诺失信。
• 遵守纪律：选择那些你在危机时刻依然会遵循的纪律原则，并且在所有工作中都遵守这些纪律。

2. 应对压力

• 不要惊慌失措，放松下来，正确应对压力
• 沟通，让你的团队和主管了解你的困境
• 依靠你的纪律原则，不要因此放弃的
• 寻求帮助；在他人陷入困难，也要主动帮助别人

第十二章 协作

• 程序员与雇主：程序员的首要职责是满足雇主的要求，最糟糕的表现是两耳不闻窗外事，只将自己扎进技术堆里；
• 程序员与程序员：整个团队共同拥有代码，通过合作学习系统的不同部分和业务；所有人都不是不可替代的；
• 专业人士会共同合作。

第十三章 团队与项目

团队比项目更难构建。因此，组建稳健的团队，让团队在一个又一个项目中整体移动共同工作是较好的做法。并且，团队也可以同时承接多个项目。在组建团队时，要给予团队充足的时间，让他们形成凝聚力，一直共同工作，成为不断交付项目的强大引擎。

第十四章 辅导、学徒期与技艺

1. 辅导

辅导缺乏经验的程序员是经验丰富的程序员的职责

（1）凭借兴趣慢慢了解
（2）看书获得知识
（3） 观察被人的行为模式，在被帮助的过程中，在合作的过程中，并加以学习
（4）自己教自己（艰难的锤炼）

2. 学徒期

• 大师：他们是那些已经领导过多个重要软件项目的程序员。一般说来，他们已经拥有10年以上的从业经验，曾在多个不同类型的系统、语言和操作系统上工作过。他们懂得如何领导和协调多个团队，他们是熟练的设计师和架构师，能够游刃有余地编程。他们通过阅读、研究、练习、实践和教学来维持自身的技术水平。公司会把项目在技术方面的主要职责交由大师承担。
• 熟练工：熟练工在大师或者其他资深熟练工的督导下工作。他们在严格的督导下进行工作。他们的代码会被人仔细复查。随着经验不断积累，他们的自主能力也会不断增长。对其直接介入指导的地方也会变得越来越少，指导内容也会越来越趋向那些微妙之处。
• 实习生：学徒期应该至少持续一年，并在这个阶段大量的学习基础知识。

3. 技艺
   技艺是工匠所持的精神状态。技艺的“模因”（meme）中包含着价值观、原则、技术、态度和正见。

学校能够传授的是计算机编程的理论。但是学校并不会也无法传授作为一名编程匠者所需掌握的原则、实践和技能。这些东西只有经由师徒个体间多年的细心监督和辅导才能获得。软件行业中像我们这样的一批人必须要面对这一事实，即指引下一代软件开发人员成熟起来的重任无法寄希望于大学教育，现在这个重任已经落到了我们肩上。建立一种包含学徒期、实习期和长期指引的机制已是迫在眉睫。