代码整洁之道:程序员的职业素养

出版者:人民邮电出版社

作者:罗伯特·C.马丁 (Robert C.Martin)

页数:170

译者:余晟

出版时间:2016-9-1

价格:49.00元

装帧:平装

isbn号码:9787115434159

具体描述

1. 汇聚编程大师40余年编程生涯的心得体会

2. 阐释软件工艺中的原理、技术、工具和实践

3. 助力专业软件开发人员具备令人敬佩的职业素养

成功的程序员在以往的工作和生活中都曾经历过大大小小的不确定性，承受过永无休止的压力。他们之所以能够成功，是因为拥有一个共同点，都深切关注创建软件所需的各项实践。他们将软件开发视为一种需要精雕细琢加以修炼的技艺，他们以专业人士的标准要求自己，他们具有职业素养。

软件开发大师Robert C. Martin在书中介绍了真实软件技艺中的各项原则、技术、工具和实践，展示了怎么以自豪、自尊和自信的心态进行软件开发，怎么取得卓越表现和丰硕成果，怎么做到有效沟通和确切估算，怎么以坦诚的心态面对困难，并引导读者认识到专业程序员肩负的责任重大，阐述了什么才是程序员的职业素养。

书中的具体内容包括：

● 成为真正的软件专业人士需要具备哪些条件，如何应对彼此冲突又紧张的进度表和不近情理的管理人员；

● 如何做到流畅编程，克服阻塞状态；

● 如何应对无休止的工作压力，避免崩溃；

● 如何培养坚持不懈的态度，如何拥抱新的开发范式；

● 如何管理好时间，避免身陷泥潭无法自拔；

● 如何培育有利于程序员和开发团队茁壮成长的环境；

● 什么时候应该说“不”，怎么说；

● 什么时候应该说“是”，承诺意味着什么。

软件强大、优雅而实用，让人惊叹不已，不论是开发者还是用户都乐于使用这样的软件。它们并非是由机器编写出来的，而是出自那些对软件技艺拥有坚定信念的专业软件开发者之手。本书将帮助读者成为专业软件开发者中的一员，并赢得只有他们才能拥有的荣誉感和成就感。

作者简介

作者:[美]罗伯特 C. 马丁（Robert C. Martin） 译者:余晟 章显洲

作者介绍

Robert C. Martin，软件开发大师，设计模式和敏捷开发先驱，敏捷联盟首任主席，C++ Report前主编，被后辈程序员尊称为“Bob大叔”。20世纪7 0年代初成为职业程序员，后创办Object Mentor公司并任总裁。Martin还是一名多产的作家，至今已发表数百篇文章、论文和博客文章。除本书外，还著有《代码整洁之道》《敏捷软件开发：原则、模式和实践》《UML：Java程序员指南》等。他创办了cleancoders.com网站，专为软件开发人员提供教育视频。

译者介绍

余晟，混迹软件开发和互联网行业多年，目前在沪江网负责研发和架构管理工作。业余喜爱阅读、思考，关注工程师的全面发展，探索更聪明的技术方案，乐于帮助外界更多理解IT行业的约束、规律和习惯。

章显洲，蚂蚁金服高级项目专家，业余以技术翻译作为个人修炼与回馈软件开发社区的途径。自2009年来，翻译和与人合译多本技术管理书籍，偶尔也会出现在技术社区聚会上作一些分享。近年来主要致力于蚂蚁金服基础设施和架构升级方面的项目集管理。

目录信息

必读引言1
第1章 专业主义 7
1.1 清楚你要什么 8
1.2 担当责任 8
1.3 首先，不行损害之事 10
1.3.1 不要破坏软件功能 10
1.3.2 不要破坏结构 12
1.4 职业道德 13
1.4.1 了解你的领域 14
1.4.2 坚持学习 16
1.4.3 练习 16
1.4.4 合作 17
1.4.5 辅导 17
1.4.6 了解业务领域 17
1.4.7 与雇主／客户保持一致 18
1.4.8 谦逊 18
1.5 参考文献 18
第2章 说“不” 19
2.1 对抗角色 21
2.2 高风险时刻 24
2.3 要有团队精神 25
2.3.1 试试看 26
2.3.2 消极对抗 28
2.4 说“是”的成本 30
2.5 如何写出好代码 35
第3章 说“是” 37
3.1 承诺用语 39
3.1.1 识别“缺乏承诺”的征兆 40
3.1.2 真正的承诺听起来是怎样的 40
3.1.3 总结 43
3.2 学习如何说“是” 43
3.2.1 “试试”的另一面 43
3.2.2 坚守原则 44
3.3 结论 46
第4章 编码 47
4.1 做好准备 48
4.1.1 凌晨3点写出的代码 49
4.1.2 焦虑时写下的代码 50
4.2 流态区 51
4.2.1 音乐 52
4.2.2 中断 53
4.3 阻塞 53
4.4 调试 55
4.5 保持节奏 57
4.5.1 知道何时应该离开一会 58
4.5.2 开车回家路上 58
4.5.3 洗澡 58
4.6 进度延迟 58
4.6.1 期望 59
4.6.2 盲目冲刺 59
4.6.3 加班加点 60
4.6.4 交付失误 60
4.6.5 定义“完成” 61
4.7 帮助 61
4.7.1 帮助他人 61
4.7.2 接受他人的帮助 62
4.7.3 辅导 62
4.8 参考文献 63
第5章 测试驱动开发 65
5.1 此事已有定论 66
5.2 TDD的三项法则 67
5.3 TDD的优势 68
5.3.1 确定性 68
5.3.2 缺陷注入率 68
5.3.3 勇气 69
5.3.4 文档 69
5.3.5 设计 70
5.3.6 专业人士的选择 70
5.4 TDD的局限 70
5.5 参考文献 71
第6章 练习 73
6.1 引子 73
6.1.110的22次方 74
6.1.2 转变 75
6.2 编程柔道场 76
6.2.1 卡塔 77
6.2.2 瓦萨 78
6.2.3 自由练习 78
6.3 自身经验的拓展 79
6.3.1 开源 79
6.3.2 关于练习的职业道德 79
6.4 结论 80
6.5 参考文献 80
第7章 验收测试 81
7.1 需求的沟通 81
7.1.1 过早精细化 83
7.1.2 迟来的模糊性 83
7.2 验收测试 85
7.2.1 “完成”的定义 85
7.2.2 沟通 88
7.2.3 自动化 88
7.2.4 额外工作 89
7.2.5 验收测试什么时候写，由谁来写 90
7.2.6 开发人员的角色 90
7.2.7 测试的协商与被动推进 91
7.2.8 验收测试和单元测试 93
7.2.9 图形界面及其他复杂因素 93
7.2.10 持续集成 94
7.3 结论 95
第8章 测试策略 97
8.1 QA应该找不到任何错误 98
8.1.1 QA也是团队的一部分 98
8.1.2 需求规约定义者 98
8.1.3 特性描述者 98
8.2 自动化测试金字塔 98
8.2.1 单元测试 99
8.2.2 组件测试 100
8.2.3 集成测试 100
8.2.4 系统测试 101
8.2.5 人工探索式测试 102
8.3 结论 102
8.4 参考文献 102
第9章 时间管理 103
9.1 会议 104
9.1.1 拒绝 104
9.1.2 离席 105
9.1.3 确定议程与目标 105
9.1.4 立会 106
9.1.5 迭代计划会议 106
9.1.6 迭代回顾和DEMO展示 107
9.1.7 争论／反对 107
9.2 注意力点数 108
9.2.1 睡眠 108
9.2.2 咖啡因 108
9.2.3 恢复 109
9.2.4 肌肉注意力 109
9.2.5 输入与输出 109
9.3 时间拆分和番茄工作法 110
9.4 要避免的行为 110
9.5 死胡同 111
9.6 泥潭 111
9.7 结论 112
第10章 预估 113
10.1 什么是预估 115
10.1.1 承诺 115
10.1.2 预估 115
10.1.3 暗示性承诺 117
10.2 PERT 118
10.3 预估任务 120
10.4 大数定律 122
10.5 结论 123
10.6 参考文献 123
第11章 压力 125
11.1 避免压力 127
11.1.1 承诺 127
11.1.2 保持整洁 127
11.1.3 危机中的纪律 128
11.2 应对压力 128
11.2.1 不要惊慌失措 128
11.2.2 沟通 129
11.2.3 依靠你的纪律原则 129
11.2.4 寻求帮助 129
11.3 结论 129
第12章 协作 131
12.1 程序员与人 133
12.1.1 程序员与雇主 133
12.1.2 程序员与程序员 135
12.2 小脑 137
12.3 结论 138
第13章 团队与项目 139
13.1 只是简单混合吗 139
13.1.1 有凝聚力的团队 140
13.1.2 如何管理有凝聚力的团队 141
13.1.3 项目承包人的困境 142
13.2 结论 142
13.3 参考文献 143
第14章 辅导、学徒期与技艺 145
14.1 失败的学位教育 145
14.2 辅导 146
14.2.1 DIGI—COMPI，我的第一台计算机 146
14.2.2 高中时代的ECP—18148
14.2.3 非常规辅导 150
14.2.4 艰难的锤炼 150
14.3 学徒期 151
14.3.1 软件学徒期 152
14.3.2 现实情况 154
14.4 技艺 154
14.5 结论 155
附录 工具 157
· · · · · · (收起)

读后感

专业主义 1.精进技艺，保持时间上的投入，保持关注 2.负责，为制造的bug负责，而不是抱着“人非圣贤孰能无过”的态度 充足的测试用例->对修改代码没有恐惧->经常性的改善代码->高质量代码 说“不” 和 说“是” 不要说试试看，给出明确答案，“是”或者“否 敢于说“不（提出...  

一本很好的书，书名虽然是代码整洁之道，但是书中却没有一行代码，写出好的代码不在于纠结编码格式化和如何使用设计模式等等，更多的如何和高效的沟通，在写之前应该花更多的时间去思考为什么要这么写，如何为之后的测试留下方法，也简述了现在比较有名的TDD 测试驱动开发的开...  

Robert C.Martin的大名咱就不说啥了。这本书写的深入浅出，感觉像读一本小说，流畅自然，但自然而然的就学到了很多东西。结合工作经验，常有种“确实如此”的感觉。 该书尤其适合我等初入职场，试图成为“专业人员”的人。其中永远不要说“我试试”和有关测试的章节给我留下了...  

Robert C.Martin的大名咱就不说啥了。这本书写的深入浅出，感觉像读一本小说，流畅自然，但自然而然的就学到了很多东西。结合工作经验，常有种“确实如此”的感觉。 该书尤其适合我等初入职场，试图成为“专业人员”的人。其中永远不要说“我试试”和有关测试的章节给我留下了...  

用户评价

我选择阅读《代码整洁之道:程序员的职业素养》，很大程度上是因为我对“职业素养”这个词的解读。在我看来，一个真正的程序员，不仅仅是技术的堆砌者，更是问题的解决者，而解决问题的前提，是清晰的思维和严谨的态度。我之前的工作经历中，遇到过很多才华横溢但代码混乱的同事，他们的代码就像一个黑箱，你永远不知道里面到底发生了什么，这让协作变得异常困难。我希望这本书能够为我提供一套切实可行的指导，帮助我写出那些“别人看一眼就能懂”的代码。我尤其关心书中关于“测试驱动开发”以及“持续重构”的理念，因为我觉得这是保证代码质量的两个关键环节。我希望它能够教我如何从一开始就编写可测试的代码，以及如何在一个不断变化的需求下，保持代码的整洁和可维护性。这本书在我眼中，不仅仅是一本技术书籍，更是一本关于如何成为一名更加成熟、更加专业的程序员的书。它能够帮助我培养一种对代码负责任的态度，一种追求卓越的精神，从而在职业生涯中不断进步，赢得他人的信任和尊重。

《代码整洁之道:程序员的职业素养》这本书，说实话，我是在一个技术论坛上偶然看到的推荐，当时就被“程序员的职业素养”这个副标题吸引住了。我是一名工作了几年、自认为写了不少代码的程序员，但每次回看自己写过的代码，总会有一种莫名的“不舒服”感，有时候甚至连自己都看不懂自己之前的逻辑，更别提让别人理解了。这种困境让我意识到，技术能力固然重要，但如果代码写得像一团乱麻，那么再精妙的算法、再巧妙的设计，也很难发挥出应有的价值，甚至会成为项目推进的绊脚石。我一直觉得，一个优秀的程序员，除了写出能运行的代码，更应该写出易于阅读、易于维护、易于扩展的代码，这是一种对代码的敬畏，也是一种对团队的责任。这本书的标题恰恰点出了这一点，让我觉得它可能能为我提供一些切实的指导，帮助我跳出“能写就行”的思维模式，走向更高的层次。我非常期待书中能够阐述如何通过代码风格、命名规范、模块划分等细节，来提升代码的可读性和可维护性，以及如何通过重构等手段，来逐步优化现有代码的质量。我也希望书中能探讨一些关于程序员职业道德和长远发展的话题，毕竟，技术更新迭代的速度太快了，只有不断提升自身的专业素养，才能在这个行业里走得更远，成为一名真正受人尊敬的工程师。

《代码整洁之道:程序员的职业素养》这本书，在我刚开始接触编程的时候，就被一些前辈推荐过。那时候的我，年轻气盛，觉得只要能实现功能，代码写得再怎么“随心所欲”也无所谓，反正自己看得懂就行。但随着工作年限的增长，我越来越发现，这种想法有多么天真和短视。我曾经因为一段难以理解的代码，导致项目延期了好几个月，那时候的挫败感至今难忘。我希望这本书能够提供一些“黄金法则”，让我们能够避免犯下同样的错误。我特别期待书中能够讲解一些关于“命名”的艺术，因为我觉得很多时候，一个清晰的命名，比长篇大论的注释更能说明问题。同时，我也希望能够学习到如何设计出更小的、更专注于单一职责的函数和类，这样不仅更容易测试，也更容易理解和复用。这本书对我来说，更像是一份“保险单”，能够帮助我规避潜在的风险，确保我的代码能够长久地健康运行，并且能够成为我职业生涯中一份宝贵的财富。我期待它能给我带来一种新的编程哲学，一种对代码精益求精的态度。

我最近入手了《代码整洁之道:程序员的职业素养》这本书，纯粹是因为最近接手了一个遗留项目，代码库庞大且杂乱无章，维护起来简直是噩梦。每次修改一个小小的功能，都感觉在雷区里行走，生怕一不小心就触发了什么意想不到的 Bug。这种糟糕的体验让我深刻反思，之前自己似乎过于注重功能实现的“快”，而忽略了代码本身的“美”和“健壮性”。我希望这本书能够提供一些系统性的方法论，帮助我理解“整洁”的代码到底是什么样的，以及如何才能逐步地将现有的“糟糕”代码，转化为“优秀”的代码。例如，书中会不会讲解一些常见的代码坏味道，以及如何针对性地进行重构？我特别好奇，对于一个庞大的遗留系统，有没有一套循序渐进的重构策略，能够让我们在不影响业务正常运行的前提下，逐步提升代码质量？另外，我也很想知道，书中是如何定义“职业素养”的，它不仅仅是关于写代码的风格，是否还包含了对代码的责任感、对错误的敬畏心，以及对团队协作的承诺？这本书在我看来，更像是一本“内功心法”，能够帮助我们从根本上解决代码维护的难题，提升整个项目的生命力。

这本《代码整洁之道:程序员的职业素养》，是我在一次技术分享会上，讲师在介绍他个人的编码经验时，反复提及的一本书。他当时强调了“职业素养”四个字，并举了一些他过去因为代码混乱而导致的团队沟通障碍和返工经历。我当时就觉得，这不仅仅是关于写代码的技巧，更是关于如何与人协作，如何在一个团队中扮演好自己的角色。作为一名在大型项目中摸爬滚打多年的程序员，我深切体会到，很多时候，问题的根源并非技术上的高深莫测，而是因为代码的可读性差，导致团队成员之间无法顺畅地交流和协作。一个难以理解的代码库，就像一个黑盒子，别人不敢轻易触碰，生怕一不小心就捅破了什么。我非常渴望从这本书中学习到，如何才能写出让团队成员“读得懂”、“信得过”、“易于上手”的代码。书中是否会提供一些具体的实践方法，比如如何有效地进行单元测试，如何设计出更具弹性的接口，如何在开发过程中更好地进行代码评审？我尤其关注那些能够帮助我们摆脱“代码孤岛”现象的理念和实践，让我们的代码能够真正地成为团队协作的润滑剂，而不是阻碍。这本书的价值，在我看来，远不止于个人技术的提升，更在于它能促进整个团队的健康发展，以及对项目长远生命力的保障。

买错了 本来想买clean code 但还是值得一看的 看第一章 以为就是些心灵鸡汤+TDD的陈词滥调 但从第二章开始 真心觉得需求管理混乱的人/团队有必要反复反复反复反复地读

感觉不出来这些原则有多大用处.我们处在目前的环境下,有多少机会和老大们说不? 至于预警还是蛮重要的. 至于Bob大叔所谓的专业主义是什么,感觉还是没有阐述清楚.

所有提到的坑在现在公司都碰到了。简直就是不专业的小公司的说明书。

Bob大叔是自洽于程序员这一工匠职业的人

在危机中也要保持平时坚持的整洁习惯。想想我的房间，泪目。