《代码整洁之道 - 程序员的职业素养》读书笔记

一 前言

  《代码整洁之道 - 程序员的职业素养》的作者是Robert C. Martin，大家喜欢喊他Bob大叔。这本书主要是Bob大叔40年编程生涯的心得体会，主要讲述了一个专业的程序员需要具备什么样的态度，遵循什么样的原则，采取什么样的行动。Bob大叔以自己亲身踩过的坑为例，为我们这些后来者传授经验。

二 结构

​ 本书共包含14章内容，接下来我会以每一章为基础单位去总结Bob大叔写下来的精华。

1. 专业主义

     专业主义不但象征着荣誉与骄傲，而且明确意味着责任与义务。专业主义的精髓就在于将公司利益视同个人利益，就意味着担当责任。

     作者讲述了1979年自己在Teradyne公司担任负责工程师期间，为了修复现存系统的几个小故障和一项新功能推出了一版新发布。为了按时交付软件，且修复的故障部分都不涉及原本系统的”夜间例行程序“的编码，作者便没有对这部分功能进行测试。新版本发布之后，”夜间例行程序“没能正常执行，遭到大部分的客户抱怨投诉。此时，作者才意识到问题的严重性，开始对”夜间例行程序“进行测试。虽然重现了问题，但是对于故障排查，作者并没有把握。由此，作者告诉现场服务经理Tom应建议客户使用旧版软件，但是Tom却发火说，这样做对于客户来说是个双重打击，因为新版本的发布已经导致了数据的丢失，若是再回退版本则会导致客户无法使用事先承诺的新功能。最终，作者找到了缺陷所在，重新交付了修复问题的新程序。但是这已经是几天之后了，这期间，每天作者都会收到客户的抱怨投诉。经历此事，作者在老板心中的印象大大下降。后续作者反思：没有对例行程序进行测试就交付软件是不负责任的。作者本应该在首次交付前就担起责任，告诉Tom测试还未完成，自己无法按时交付。虽然这样会使得Tom不开心，但不会发生丢失数据，客户投诉的事情。

   如何承担责任？

     要不行损害之事。从纯软件的角度来说就是：不要破坏软件的功能与架构。

     (1)不要破坏软件功能。但是开发过程中难免会出现bug，哪怕有些bug实际上在所难免，我们也应该对这些bug负责。出现问题之后，首要的事情就是道歉，后续应当避免出现类似的错误。虽然失误率永远不可能等于零，但是我们有义务让它无限接近于零。如何做到呢？①确信代码正常运行，加强自测，自己写过的代码测试的覆盖率应该达到100%。②让QA找不出任何问题，应该把QA当成客户来对待，什么意思呢？我们应该把确保没有问题的代码交给QA测试，而不是让QA去测试我们没有把握的代码，或是我们明知有缺陷的代码。③自动化QA，作为开发人员，我们需要有一个迅捷可靠的机制，以此帮助我们判断所写的代码是否能够正常工作。

     (2)不要破坏结构。软件要易于修改，结构良好的代码更为灵活。代码是一个不断优化的过程，每次读代码，都可以做一些简单的修改。大多数人认为对上线运行的软件不断地做修改是危险的。错！让软件保持固定不变才是危险的！

   要有职业道德：要持续学习，每天应当抽出一些时间来给自己充电，这样才能有助于让自己在职场中立于不败之地。了解自己行业的领域、坚持学习、要练习、学会合作、辅导新人、了解业务领域、与雇主/客户保持一致、要学会谦逊。

2. 说“不”

     能就是能，不能就是不能。不要说“试试看”。

     作者讲述了在20世纪70年代初，在ASC公司工作时发生的一件事。作者所在团队研发的系统在预期上线的前一周才把系统完整的搭起来，但还存在很多待解决的bug。作者及其团队需要一定的时间去解决这些bug，但是ASC的经理Frank强制要求按期完工，到期交货，不容置喙。作者及其团队只能加班加点，昼夜颠倒的去排查解决现存bug，没有单独思考的时间。如期上线之后，悲剧了，系统无法正常使用，需要以一小时一次的频率一直重启系统。客户拒绝使用系统知道系统能够正常使用。Frank大发雷霆，要求本周五之前必须让系统正常运行，但是作者预估系统稳定下来的时间是4周。在Frank的强烈要求下，作者所在团队妥协，说试试看。上线之后，原本的bug偶尔还会出现，除此外还有其他问题也暴露出来了。只能不断地去解决客户那边不断涌来的问题。

     要懂得说“不”，对于明知在deadline前完不成的工作，不要做出承诺。“试试看”这样的字眼也不要说，这样的词只会让经理认为你其实是有一定几率可以做到的。要和经理达成一致，找到我们和经理共同的目标，挖掘经理在deadline前最想要看到的效果，以及我们能帮助其实现什么样的效果。因为经理可能不理解为什么一个简单的功能会需要那么多时间去做。就比如登录功能，经理只要能登录就行了，至于其它的忘记密码、登录互斥、输错密码3次账号锁死等衍生功能会认为是没有必要的。提供更多细节，只会招致更多的微观管理。所以我们没有必要去解释为什么需要那么多时间，我们只需要找到我们和经理的共同目标，提供给经理一个暂时演示的版本，用于经理给客户演示。

     要有团队精神，与大家多交流，关心队友，当队友遭遇困境时要及时援助，尽职尽责。不要说“试试看”，许诺“尝试”，就意味着你承认自己之前未尽全力，承认自己还有余力可施。许诺“尝试”，其实就是承诺确保会成功，若是尝试没有达成预期的成果，那么就表示你失败了，这期间的压力和后果就需要你自己来抗了。

3. 说“是”

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

     不要说一些模棱两可，缺乏承诺的话，例如：我需要减肥。要表现出对某一件事情的掌握性，承诺可以做到，例如：我将在下周二之前减掉1斤体重。承诺的关键在于对自己将要做某件事有了清晰的事实陈述，而且明确说明了完成期限。不是可能会做，可能做到，而是一定做到，必须做到。

     若是你无法兑现承诺，那么最重要的就是尽早向你的承诺对象发出预警，越快越好，越早越好。因为越早向各利益相关方发出预警信号，整个团队就越有机会做出响应，减少不必要的损失。

     专业人员不需要对所有的请求都回答“是”，但是应尽力寻找创新方法，尽可能做到有求必应。要做到既不破坏开发人员的原则，又能够承诺确保能完成的任务，准确表达出自己能够在期限内做到的任务。

4. 编码

     编码是一项颇具挑战也十分累人的智力活动，当你无法全神贯注地编码时，所写代码就有可能出错。如果感到疲劳或者心烦意乱时，千万不要编码，因为大概率这些代码需要返工。要学会将睡眠、健康和生活方式调整到最佳状态。

     作者以自己切身经历讲述了自己在凌晨3点写出的代码，在当时感觉无比完美的代码，后续却一遍一遍的肆虐作者及其团队。关于高效率状态，有时候程序员编写代码时会进入一种意识高度专注但思维视野却会收拢到狭窄的状态，又称“流态区”。在这种状态下，他们会感觉效率极高，绝无错误。但一些进入这种状态又从中摆脱出来的人给出忠告：避免进入流态区。因为这其实是一种浅层冥想状态，在这种状态中理性思考能力会下降，会敲出更多的代码，收获一种愉悦感或征服感。但这种状态下写出的代码并没有顾及全局，导致后续需要重构。所以，当察觉到自己快要进入这种状态时，离开座位，转换一下思维。

     软件开发是一场马拉松，而不是短跑冲刺，只有保持节奏才能取胜。专业的程序员应仔细保存好自己的精力和创造力。当你碰到问题受阻时，感到疲倦时，就离开一会儿，让富有创造力的潜意识接管问题。有很多问题是在回家路上、洗澡的时候想通的。

     创造性输出依赖于创造性输入。平时可以广泛的去阅读一些资料，例如：科幻小说等，去激发自己的创造力。

5. 显示