Robert C. Martin，世界级编程大师，设计模式和敏捷开发先驱，敏捷联盟首任主席，C++ Report前主编，被后辈程序员尊称为“Bob大叔”。20世纪70年代初成为职业程序员，后创办Object Mentor公司并任总裁。

Robert C. Martin

Martin还是一名多产的作家，至今已发表数百篇文章、论文和博客文章。著有《代码整洁之道》《代码整洁之道：程序员的职业素养》《敏捷软件开发：原则、模式和实践》《UML：Java程序员指南》等。

著名的对象范型和C++专家考帕里安(James O. Coplien)曾这样评价Bob大叔：

那班求索者多年来并肩奋斗，不但是为求一己之进步，更将他们的知识通过和你手上正在做的事一般的工作奉献给这个行业，使得编程世界略有改善。

扫描二维码关注公众号，回复： 10531182 查看本文章

天才少年Bob的成长之路

1964年，12岁的Bob写下人生第一行代码。

1965年，Bob开启了人生中算得上专业的第一次合作，与小搭档John Marchese一起造电脑，Bob思考，John动手，两个人忙活了数百个小时，捣鼓出了不少看着相当有型的家伙，上面装着继电器、按钮、小灯，甚至还安装了一个电传打字机！虽然这些电脑没法用，但是看起来真的很棒，他们也确实很用心，这对于两个13岁的小朋友来说，相当了不起了！

电动打字机

1968年，在中学第一年认识了新的小伙伴Tim Conrad，开始了新一轮的造电脑工程，这次由Tim思考，Bob动手，Tim还教给了Bob一些电子学知识，Tim也是第一个给Bob介绍PDP-8的人。他们用了一些很基础的元器件，真的造出了一台可以工作的18位二进制计算器，能够进行加减乘除的运算，他们兴奋极了，那年他们把所有的假期都投了进去。

后来，他们还自学了计算机课程，在那个年代，这是一个相当不容易的事情，但他们做到了。他们特别找来了有关PDP-8汇编器、FORTRAN、COBOL、PL/1，他们就像海绵一般在书中汲取知识，并写了一堆根本根本没有可能去实际执行的程序，因为那时根本没有计算机可以供实操，但纯粹出于爱好，他们仍然孜孜不倦写了许多程序。

PDP-8汇编器

1969年，Tim、Bob以及他们的伙伴Richard Lloyd成为了ACS公司的程序员，为芝加哥卡车司机工会开发实时会计系统。17岁的他们觉得上大学是浪费时间，决定马上进入职场，在那里他们遇到了Bill Hohri、Frank Ryder、Big Carlin和John Miller，他们为这些年轻人提供了学习专业编程的实战机会，Bob在其中颇受教益。

这份工作经历也让Bob意识到，作为一个程序员还应该具备某些素养，例如对着你的上司，说“YES”和“NO”。

Bob在ASC工作时，他的上司 Frank 是一位退役的空军上校，这位领导的处事风格雷厉风行：我发出指令、你们按时上线。初入职场的一众小年轻，包括Bob，根本不敢看他的眼睛，更不敢抗议时间不够，最终的结果是系统按时上线，故障频发，无限次数的系统崩溃、系统重启。

Bob认为，程序员往往太容易说“YES”，总是在没有明确目标和期限的情况下，就第一时间草率地给出了确认的答复，任务交付时却无法实现自己的承诺。

有时候，获取正确决策的唯一途径，便是勇敢无畏地说出“不”字……我们要明白，委屈专业原则以求全，并不是问题的解决之道。舍弃这些原则，只会制造出更多的麻烦。

只要你愿意尝试，在工作中对着那些不合理的工作任务，主动说几次“NO”，之后你会逐渐发现：你只需要花三分的力气去拒绝那些无法完成的工作任务，就可以节省十分甚至二十分开发的时间；相反，如果在没有明确目标和期限的情况下，就草率给出了确认的答复，往往会非常被动，到最后，项目就落得著名的 IBM OS/360 操作系统的失败下场。

在Bob的经典书籍《代码整洁之道》中也提到，作为一个程序员不仅是懂得“NO”背后所蕴含的意义和责任，“YES”背后的意义和责任同样重要。

（说“YES”时）你对自己将会做某件事做了清晰的事实陈述，而且还明确说明了完成期限。那不是指别人，而是指你自己。你陈述的是自己会去执行的一项行动，而且，你不是“可能”去做，或是“可能做到”，而是 “会”做到。

但“YES”背后常常跟着的是屡见不鲜的项目延期，绝大部分原因就是在这种不负责任的情况下说 “YES”导致的。

在Bob的学生时代、职业生涯中，直接导师并不多，因为他的成长的年代中并没有很多有经验的老师、程序员。Bob在工作项目的摸索及读一些杰出人物的著作来汲取知识、积累经验，这些人包括Grady Booch（《UML用户指南》作者）, Tom DeMarco（《项目百态》作者）, Meilir Page-Jones（《UML 面向对象设计基础》作者）, Erich Gamma（《设计模式》作者）, Martin Fowler（《重构》作者）, Bertrand Meyer（《面向对象软件构造》作者）, Kent Beck（《测试驱动开发》作者），等等。Bob感觉这些教导都是充满价值的。

随后Bob在Teradyne工作，他从老板、工作伙伴们的身上学到了许多他认为有价值的东西，特别是Mike Carew，他们成为了黄金搭档，“如果你想活儿干得又快又好，就把他交给Bob和Mike！“他们共事的时光充满欢乐。

糟糕的代码能让一个公司关门大吉！

在一个项目中，某位同事花三个星期写完一串代码后离职了，在没有批注、没有规律的情况下，果然没有人能够理解这串代码，最终只能由新的同事重新撰写。这段经历让他从此对代码的整洁深感重视。

1987年，Bob开始和Jim Newkirk搭档，随后他们相继离开Teradyne，加入了Clear Communication。

于此同时，有家公司写了一个很流行的杀手应用，许多专业人士都买来用，包括Bob。然后，发布周期开始拉长，缺陷总是不能修复，装载时间越来越久，崩溃的概率也越来越大，至今Bob还记得自己在某天沮丧地关掉那个程序，从此再不用它时的绝望心情。果不其然，在那之后不久，该公司就关门大吉了。

后来，Bob见到那家公司的一位早期雇员，问他发生了什么事，而他的回答令Bob愈发恐惧起来。原来，当时他们赶着推出产品，代码写得乱七八糟，特性越加越多，代码也越来越烂，最后再也没法管理这些代码了，只好放着不管，最终，糟糕的代码毁了这家公司。这个事情更是让Bob确定了代码的整洁是需要引起重视的，软件质量，不但依赖架构及项目管理，而且与代码质量紧密相关，但当时的他并没有能力来改变这一切。

Robert C. Martin

99%的程序员都在为糟糕代码头痛！

Bob和Jim一起在Clear Communication拼搏了好几年后，共同创办了Object Mentor公司，Bob认为，在他有幸共事过的人中，Jim是最率直、最严谨和最专注的人，从Jim身上获益良多。

直到现在，Bob仍坚持阅读这一习惯，每天花费大量的时间阅读，甚至包括博客和文章，从中紧跟科技发展。他曾坦言自己一直都在寻找值得一读的好书。

想到那个困扰了他许久的难题，也是大部分程序员都遭遇过的难题——糟糕的代码，他本能的就想迎头而上，像他的导师们一样，像Jim一样，给别人带来帮助。于是，他开始写作，在《代码整洁之道》一书中分享了自己多年编程生涯所累积的项目实践经验，将代码整洁的多种解决办法倾囊相授，受到了广大程序员的喜爱及追捧。

Bob曾在为 ASD 所写的序中写道：

最好的软件开发人员都知道一个秘密：美的东西比丑的东西创建起来更廉价，也更快捷。

而构建、维护一个美的软件系统所花费的时间、金钱都要少于丑的系统。

美的系统是灵活、易于理解的，构建、维护它们就是一种快乐。”

如果说 ASD 中更多的是设计思想和模式精髓的阐述，那么在《代码整洁之道》中，Bob 为程序员们提供了更为详尽的微距视角，涉及“命名”、“函数”、“代码格式”、 “异常处理”、“单元测试”等编码主题，巨细靡遗地向软件工匠们极力传授整洁编码的艺术，进一步向软件开发社区慷慨分享了他在探索“软件之美”旅途中的参证心得。

Bob还在书中提出一种观点：代码质量与其整洁度成正比。干净的代码，既在质量上较为可靠，也为后期维护、升级奠定了良好基础。

他认为，无论是敏捷开发流派还是传统开发流派，想要保证软件质量，不仅仅依赖架构及项目管理，更与代码质量紧密相关。

《代码整洁之道》中提到 Bob大叔认为把代码变得整洁的，就首先要了解三个注释，即：

不恰当的信息

让注释传达本该更好地在源代码控制系统、问题追踪系统或任何其他记录系统中保存的信息，是不恰当的。

例如，修改历史记录只会用大量过时而无趣的文本搞乱源代码文件。通常，作者、最后修改时间、 SPR 数等元数据不该在注释中出现。

注释只应该描述有关代码和设计的技术性信息。

废弃的注释

过时、无关或不正确的注释就是废弃的注释。注释会很快过时。最好别编写将被废弃的注释。

如果发现废弃的注释，最好尽快更新或删除。

废弃的注释会远离它们曾经描述的代码，变成代码中无关和误导阅读者的浮岛。

糟糕的注释

值得编写的注释，也值得好好写。

如果要编写一条注释，就花时间保证写出最好的注释，字斟句酌，使用正确的语法和拼写，别闲扯，别画蛇添足，要保持简洁。

糟糕的代码最终会成为吞噬人的黑洞

上面的图片是《代码整洁之道》的封面，是用来自于哈勃望远镜那副著名的可见光相片和Spitzer（斯比泽）轨道探测器最新红外影像组合而成的M104：草帽星系，它坐落于处女座，离地球仅3000万光年，其核心是一个质量超大的黑洞，有100万个太阳那么重，仿佛经历了大爆炸之后碎片四溅的产物。

让人不禁联想到那些代码不整洁、风格各异且不可维护的项目，就像一个个的黑洞，存在着某天会定时爆发的风险，而当它真正爆发时，这个项目的所有人都会因此遭殃。

当你负责一个小型项目时，如果追求速度，力求快速出成果，这时可以率性而为。当项目逐渐扩大，规范就会逐步显出它的重要性。在软件开发中也是一样，归置到位的工具能提升生产力。软件质量，不但依赖于架构及项目管理，而且跟代码质量息息相关。代码质量与其整洁度成正比。干净的代码，既在质量上较为可靠，也为后期维护、升级奠定了良好的基础。