作者: 罗伯特·C.马丁 (Robert C.Martin)
出版社: 人民邮电出版社
原作名: The Clean Coder:A Code of Conduct for Professional Programmers
译者: 余晟 / 章显洲
内容简介
-
汇聚编程大师40余年编程生涯的心得体会
-
阐释软件工艺中的原理、技术、工具和实践
-
助力专业软件开发人员具备令人敬佩的职业素养
成功的程序员在以往的工作和生活中都曾经历过大大小小的不确定性，承受过永无休止的压力。他们之所以能够成功，是因为拥有一个共同点，都深切关注创建软件所需的各项实践。他们将软件开发视为一种需要精雕细琢加以修炼的技艺，他们以专业人士的标准要求自己，他们具有职业素养。
软件开发大师Robert C. Martin在书中介绍了真实软件技艺中的各项原则、技术、工具和实践，展示了怎么以自豪、自尊和自信的心态进行软件开发，怎么取得卓越表现和丰硕成果，怎么做到有效沟通和确切估算，怎么以坦诚的心态面对困难，并引导读者认识到专业程序员肩负的责任重大，阐述了什么才是程序员的职业素养。
书中的具体内容包括：
● 成为真正的软件专业人士需要具备哪些条件，如何应对彼此冲突又紧张的进度表和不近情理的管理人员；
● 如何做到流畅编程，克服阻塞状态；
● 如何应对无休止的工作压力，避免崩溃；
● 如何培养坚持不懈的态度，如何拥抱新的开发范式；
● 如何管理好时间，避免身陷泥潭无法自拔；
● 如何培育有利于程序员和开发团队茁壮成长的环境；
● 什么时候应该说“不”，怎么说；
● 什么时候应该说“是”，承诺意味着什么。
软件强大、优雅而实用，让人惊叹不已，不论是开发者还是用户都乐于使用这样的软件。它们并非是由机器编写出来的，而是出自那些对软件技艺拥有坚定信念的专业软件开发者之手。本书将帮助读者成为专业软件开发者中的一员，并赢得只有他们才能拥有的荣誉感和成就感。
读书笔记
书摘： 我在招聘中经常会问:“在你过去的工作中，遭遇过哪些印象深刻的困难，最后是怎么解决的?”依我的经验，简历写得再漂亮的人，如果这个问题答不好，大都可以直接忽略。为什么会有这种结论?因为我们需要招聘的不是“经历丰富”的人，而是“有职业素养”的人。你遇到的问题可能很容易也可能很难，但我看重的并不是问题的难度，而是解决问题的方式、步骤以及反思的程度。恢复误删数据，对很多人来说这是非常简单的任务。我更感兴趣的是怎样分析问题，找了怎样的资料，采取了怎样的步骤，此后做了哪些措施来避免这种错误再次出现。在我看来，与问题本身的难度相比，解决问题的方式、步骤以及反思的程度，才能体现出一个人的职业素养。
书摘： 什么样的代码是有缺陷的呢？哪些你没有把我的代码都是！
书评： 写代码的过程中，出现Bug的地方，不仅是我们意料之外的地方，还有的就是我们觉得不妥的地方，逻辑不够清晰的 地方，最后总会爆出问题。
书摘： 但是有些代码不是很难测试吗?是的，但之所以很难测试，是因为设计时就没考虑如何测试。唯一的解决办法就是要设计易于测试的代码，最好是先写测试，再写要测的代码。 这一方法叫做测试驱动开发(TDD)，我们在随后的章节里会继续谈到。
书评： 这个恐怕程序员圈说的最多的一种方法了，但是应该很少程序员这么做吧？
书摘： 下面列出了每个专业软件开发人员必须精通的事项。 - 设计模式。必须能描述GOF书中的全部24种模式，同时还要有POSA书中的多数模式的实战经验。 - 设计原则。必须了解SOLID原则，而且要深刻理解组件设计原则。 - 方法。必须理解XP、Scrum、精益、看板、瀑布、结构化分析及结构化设计等。 - 实践。必须掌握测试驱动开发、面向对象设计、结构化编程、持续集成和结对编程。 - 工件。必须了解如何使用UML图、DFD图、结构图、Petri网络图、状态迁移图表、流程图和决策表。
书摘： 谦逊 编程是一种创造性活动。写代码是无中生有的创造过程，我们大胆地从混沌之中创建秩序。我们自信地发布准确无误的指令，稍有差错，机器的错误行为就可能造成无法估量的损失。因此，编程也是极其自负的行为。 专业人士知道自己自负，不会故作谦逊。他们熟知自己的工作，并引以为荣;他们对 自己的能力充满自信，并因此勇于承担有把握的风险。专业人士不是胆小鬼。 然而，专业人士也知道自己会摔跟头，自己的风险评估也有出错的时候，自己也有力不从心的时候。这时候，如果他们照照镜子，会看到那个自负的傻瓜正对着自己笑。 因此，在发现自己成为笑柄时，专业人士会第一个发笑。他从不会嘲讽别人，自作自受时他会接受别人的嘲讽。反之，他则会一笑了之。他不会因别人犯错就对之横加贬损，因为他知道，自己有可能就是下一个犯错的人。 专业人士都清楚自己的自负，也知道上天会注意到这种自负，并加以惩戒。如若果真遭遇挫折，最好的办法就是按照霍华德说的——一笑了之吧!
书摘： 专业人士敢于说明真相而不屈从于权势。专业人士有勇气对他们的经理说“不”。 你怎么能对自己的老板说“不”呢?毕竟，他们可是你的老板啊!难道不该照你老板说 的去做吗? 不应该照做。只要你是一名专业人士，那就不应该照做。 奴隶没有权利说“不”。劳工或许也对说“不”有所顾虑。但是专业人士应该懂得说“不”。事实上，优秀的经理人对于敢于说“不”的人，总是求贤若渴。因为只有敢于说“不”，才能真正做成一些事情。
书评： 只有对于老板提出的不合理要求说“不”，才能够体现自己的专业性。因为只有你足够专业，你才能通过自己的专业能力知道老板的提议是不合理的。
书摘： 进行沟通或者汇报时，进行少的提及开发细节，因为提供太多细节，只会招致更多的微观管理。
书摘： 以下示例中包含的几个用词和短语，会透露“缺乏承诺”的蛛丝马迹，要注意搜寻， 需要/应当。“我们要把这活做完。”“我需要减肥。”“有人应当负责去推动这件事。 希望/但愿。“希望明天我能完成这个任务。”“希望改天我们能再见面。”“但愿我有时间做这件事。”“但愿电脑能快点。” 让我们(而不是“让我”)。“让我们回头再见。”“让我们把这事做完。” 只要去搜寻你就会发现，在自己身边，这类词语比比皆是，甚至在你对别人说的话里也时常出现。 你会发现，我们有竭力逃避承担责任的倾向。 如果你或者其他人工作的一部分依赖于那些承诺，那就大事不妙了。不过你已经迈开了第一步，开始能够在你周边的人(包括你自己)的言语里捕获可能存在“缺乏承诺”的征兆了。 我们已经明白有哪些词语会暴露“缺乏承诺”。那么，该怎么识别真正的承诺呢‘
书摘： “我将在周二之前完成这个任务。” 这句话的关键在哪里呢?你对自己将会做某件事做了清晰的事实陈述，而且还明确说明了完成期限。那不是指别人，而是说的自己。你谈的是自己会去做的一项行动，而且，你不是可能去做，或是可能做到，而是必须做到。
书摘： 关于高效率状态，大家已经写了很多，这种状态通常被称为“流态”。有些程序员将之称，为“流态区”。不管用什么名字，你可能都不陌生，甚至有过这种体验。这是程序员在编写代码时会进入的一种意识高度专注但思维视野却会收找到狭窄的状态。在这种状态下，他们会感到效率极高;在这种状态中，他们会感到“绝无错误”因此他们一直苦苦追求进入这种状态，并经常以能在那种状态下维持多久来衡量自我价值。 一些曾经进入这种状态但终又从中摆脱出来的人给出了一点儿忠告:避免进入流态 区。这种意识状态并非真的极为高效，也绝非毫无错误。这其实只是一种“浅层冥想”状态，在这种状态下，为了追求所谓的速度，理性思考的能力会下降。
书评： 现在都叫做“心流”状态 ，这个状态下，写代码真的是感觉如行云流水般的舒畅，但是事后再看代码会发现确实存在一些Bug，并且这些Bug会觉得特别低级，自己只要稍微思考一下就不会这样。
书摘： 辅导缺乏经验的程序员是那些经验丰富的程序员的职责。培训课程无法替代，书本也无法替代。除了自身的内驱力和资深导师的有效辅导之外，没有东西能将一名年轻的软件开发人员更快地提升为敏捷高效的专业人士。因此，再强调一次，花时间手把手地辅导年轻程序员是资深程序员的专业职责所在。同样道理，向资深导师寻求辅导也是年轻程序员的专业职责。
书评： 这个真的是这样的，个人在从事开发工作时，确实是这样，有经验的程序员指导下的感觉，确实是跟书籍或者视频的效果不一样。
书摘： 职业程序员用自己的时间来练习。老板的职责不包括避免你的技术落伍，也不包括为你打造一份好看的履历。医生练习手术不需要病人付钱，球员练习绕桩(通常)不需要球迷付钱，乐手练习音阶也不需要乐迷付钱。所以老板没有义务为程序员的练习来买单。
书评： 这个可能很多程序员或者从业者无法理解，觉得公司应该提供这样的条件。作为一名程序员（执行者）时，我也这么认为。当我坐在管理者的位置时，我要从公司的利益考虑，我开出来的工资和支付的工资买的就是你已有的能力和你的潜在能力，这个潜在能力就需要你自己来体现了。这个如何体现，就要靠你自己的学习和输出。
书摘： 在工作中，有一种现象叫观察者效应，或者不确定原则。每次你向业务方展示一项功能，他们就获得了比之前更多的信息，这些新信息反过来又会影响他们对整个系统的看法。 最终结果就是，需求完成得越精细，就越容易被忽视，系统因此也谈不上完工。
书评： 这个情况太常见了，尤其是没有产品经理出原型图的情况下。针对这样的情况，只能是前期定好需求，针对再增加的需求，一律排期或者替换掉已有的排期功能。
书摘： 如果收到会议邀请，务必弄清楚指定的议题是什么，每个议题花多长时间，要取得什么成果。如果得不到确切的答案，你可以礼貌拒绝。 如果你已经出席会议，但发现已经偏离或是放弃了原有议程，你应当要求详细列出新的议题和议程。如果没有答案，也应当在合适的时候礼貌离席。
书评： 不管你是管理者还是执行者，都不要浪费时间在无效的会议上。
书摘： Kent Beck曾告诉我一个深刻的道理;“凡是不能在5分钟内解决的争论，都不能靠辩论解决。”争论之所以要花这么多时间，是因为各方都拿不出足够有力的证据。所以这类争论依据的不是事实，而是信念。 有人会尝试借助个人能力赢得争论。他们可能提高嗓门，近距离与你对视，或者摆出不屑的姿态。但这都不重要，长期来看，强力是无法解决争论的，最终还是需要数据。
书评： 如果争论方是上级领导，你还没有准确数据以表明自己的观点，那就在第6分钟同意他的观点。如果是同级或者合作部门，那就在第6分钟提出暂停，保留这个观点，线下确认相关数据，再做定夺。
书摘： 专业人士之所以结对，是因为结对是复查代码最好的方式。系统中不应该包含未经其他程序员复查过的代码。代码复查的方法很多，但大多数方法效率都极其低下。最有效率且最有效果的代码复查方法，就是以互相协作的方式完成代码编写。
书评： 除非代码特别简单，简单到无法两人协作开发，否则最安全也是最稳妥的方式就是两人协作开发。如果总是一个人开发，那这不是一个好的现象，我建议你换份工作，可能是公司的开发习惯有问题。
