这是why技术的第32篇原创文章

春节期间读了两本技术相关的书籍：编程大师Bob大叔的《代码整洁之道》和《代码整洁之道：程序员的职业素养》。

《代码整洁之道》出版于2010年，其内容主要是偏向于技术的"技"。全书都在说一些如何让代码更加整洁的方法和规则。

《代码整洁之道:程序员的职业素养》出版于2016年，其内容主要偏向于技术的"术"。全书内容和代码整洁关系不大，更多的是阐述软件开发者的专业精神。书中给出了很多务实性的意见。

代码整洁之道

写代码犹如写文章。这就是Bob大叔在书里所提倡的论点。

关于本书豆瓣网友有个评论写的还是不错的，可以引用过来：

本书中Bob大叔提倡”写代码犹如写文章“，又说到“大师级程序员把系统当故事来讲，而不是当做程序来写”，对此观点我印象深刻！在此之前我从未听说过可以把代码当成故事、文章来写，Bob大叔太有才了！

如何才能写出整洁代码呢？

总的原则无非是KISS（Keep It Simple Stupid）：让代码简单直接，让阅读者可以很容易地看出设计者的意图。

本书中给出了很多方法与规范，遵循这些规则可以帮你写出更加的整洁代码。

这是一本不错的书。给本书打4星，是因为本书在讲述代码重构方面不如《重构--改善既有代码的设计》、讲述代码编写方面不如《代码大全》、讲述代码设计方面不如《敏捷软件开发》（Bob大叔自己的上一本经典著作）。另外中文版价格偏高，翻译质量也很一般。

读书笔记：

第一章 整洁代码

1，整洁代码力求集中，每个函数、每个类和每个模块都全神贯注于一件事。

2，整洁代码简单直接，从不隐藏设计者的意图。

3，整洁代码应当有单元测试和验收测试。它使用有意义的命名，代码通过其字面表达含义。

4，消除重复代码，提高代码表达力。

5，时时保持代码整洁。

第二章 有意义的命名

1，使用体现本意的命名能让人更容易理解和修改代码。

2，编程本来就是一种社会活动。

3，尽力写出易于理解的代码

第三章 函数

1，一个函数应该只做一件事（高内聚），无副作用。

2，自顶向下阅读代码，如同是在阅读报刊文章。

3，长而具有描述性的函数名称，好过描述性的长注释。

4，使用异常代替返回错误码，错误处理代码就能从主路径代码中分离出来得到简化。

5，写代码很像是写文章。先想怎么写就怎么写，然后再打磨：分解函数、修改名称、消除重复。

6，编程其实是一门语言设计艺术，大师级程序员把程序系统当做故事来讲。使用准确、清晰、富有表达力的代码来帮助你讲故事。

第四章 注释

1，别给糟糕的代码加注释----重写吧。

2，把力气花在写清楚明白的代码上，直接保证无需编写注释。

第五章 格式

1，代码格式很重要。代码格式关乎沟通，而沟通是专业开发者的头等大事。

2，向报纸格式学习代码编写。

第六章 对象和数据结构

1，对象把数据隐藏于抽象之后，只提供操作数据的函数。数据结构暴露其数据，没有提供有意义的函数。

2，The Law of Demeter：模块不应去了解它所操作的对象内部细节。

第七章 错误处理

1, 使用异常而非返回错误码。

2, try-catch-finally, log出错信息。

3, 不要返回null，不要传递null。NULL Object模式, 例：Collections.emptyList();

第十章 类

1，自顶向下原则：让程序读起来就像是一篇报纸文章。

2，method可以是protected，以便于单元测试。

3，SRP：类或模块应有且仅有一个加以修改的原因。类名应准确描述其职责。高内聚。

4，开放闭合原则、依赖倒置原则。

5，变量名、方法名、类名都是给代码添加注释的一种手段。

第十二章 迭代前进

1，紧耦合的代码难以编写单元测试。

2，单元测试消除了对清理代码会破坏代码的恐惧。

3，写出自己能理解的代码很容易，软件项目的主要成本在于长期维护。

4，代码应当清晰表达其作者的意图；测试代码可以通过实例起到文档作用。

第十四章 逐步改进

1，编程是一种技艺。要编写整洁代码，必须先容忍脏代码，然后清理！

2，写出好文章就是一个逐步改进的过程。

程序员的职业素养

在《代码整洁之道：程序员的职业素养》一书中，Bob大叔主要试图回答下面的问题：

1.什么是软件专业人员？

2.软件专业人士如何行事？

3.软件专业人士如何处理冲突，应对很紧的工期，如何和不讲道理的管理人员打交道？

4.软件专业人士何时应该说“不”？怎么说？

5.软件专业人士如何应对压力。

在读这本书的时候，你能感受到针对上面的问题，书中除了提出一些务实性的意见，你还能感受到一种说不清道不明的积极态度。

这种态度提倡要诚信，要富有荣誉感、自尊心和自豪感，要勇于承担作为一名手艺人和工程师所肩负的重大责任。

这种责任包括要努力工作，出色完成任务；要擅于沟通，能就事论事；要管理好时间，能够坦然面对艰难的“风险回报”决策。

除了责任感外，还有一种神圣的使命感。身为一名工程师，你比任何管理者可能都了解得更透彻。了解这些你也意味着你肩负着要敢于行动的重大责任。

针对上面的问题，我这篇文章中肯定是说不全的。毕竟人家是一本书，如果我浓缩到了一篇文章中，那就有点泛泛而谈了。

我主要想分享一下我读完这本书体会比较大的其中的一个点，并且经过这几年的开发，我也深以为然的一个点。

在书的1.4 职业道德 小节中作者提起了下面这几点：

其中诸如坚持学习、联系、合作之类的老生常谈的话题我就不多说了。我主要想谈谈我标记了的了解你的领域和了解业务领域这两个点。

了解你的领域了，我的领域就是程序员领域。不，这样的格局太小。我的领域就是互联网领域。

近50年来，各种观点、实践、技术、工具与术语在我们这一领域层出不穷，如果想要成为一名专业的开发者，就需要对其中的大部分有所了解，而且要不断地扩展这一知识面。

作为一个专业的程序员，对于自己所在领域的技术必须了解并且时刻进行迭代更新。

了解你的领域就是了解自己"吃饭"的范围。

大家都知道，在这个行业中知识是层出不穷的。我们学习的速度永远赶不上知识更新的速度。正是因为这样的，所以我们在巩固知识的同时也需要坚持学习。让自己尽量晚的被淘汰出局。

为什么说我们这个行业是一个吃青春饭的行业呢？

我觉得是因为随着年龄的增长和所承担的社会角色越来越复杂，学习能力和精力会随之下降。到某个时候，不用别人说，你就自己感受到了，学习的劲头越来越赶不上这波年轻人了。

这个时候，你就需要看自己有没有核心竞争力了。

每个人的核心竞争力大多不同，但是向上抽离的话你会发现，大多数都和业务领域相关。这个时候就体现出了解业务领域的重要性了。

每位专业软件开发人员都有义务了解自己开发的解决方案所对应的业务领域。

每个人的业务领域也不相同，就拿我自己来说，我做过支付、做过账户、做过贷款，自认为我是属于互联网金融行业的。

相信也有很多朋友和我所处的行业是一样的。

那你身处这个领域那你知道什么银联吗？

网联为什么诞生吗？

什么是大小额通道？

什么是聚合支付？

什么是二清？

为什么要打击二清？

知道支付牌照对于支付公司来说有多么重要吗？

知道央行的217号文件中的那句：全面检查对于持证机构(银行、银联、第三方支付机构、各地方清算中心)违规为无证经营支付业务机构提供支付清算服务的行为。这句话对于整个支付行业的震荡有多大吗？

......

这些问题都是写到这里的时候一瞬间涌入到我脑海中的问题。这样的和技术无关，但是和所属领域有关的问题还有很多很多。

我想要表达的东西和书里面表达的是一样的。

如果编写财务系统，你就应该对财务领域有所了解；如果编写旅游应用程序，那么你需要去了解旅游业。

你未必需要成为该领域的专家，但你仍需要用功，付出相当的努力来认识业务领域。

而最糟糕、最不专业的做法就是，简单的按照规则说明来编写代码，但却对为什么那些业务需要那些的规格定义不求甚解。

而这也是刚刚入行的新人所常常面对的问题，只关心技术，不关心业务。

年前极术社区搞了一个活动：分享你所在的行业或者所学专业过去十年你觉得变化最大的技术是什么，未来十年你觉得哪个技术发展最值得期待。

这个活动其实就是对我上面说到的了解你的领域和了解业务领域这两个点的结合。我认为任何一个有几年开发经验的程序员都应该能写上几句，表达自己的观点。观点也许很浅显，也许不一定正确，但是那也是有自己的思考在里面。

我当时的回复是这样的：

其实在我看来我说的都不算是观点，就是我在这个行业里面待了几年的时间，亲眼看到，亲耳听到的事情。

一些了不得的、波澜壮阔的事情，正在通过互联网金融的这个业务领域，改变着人类生活的方方面面。

另外，书里还说到一个点，我也觉得应该分享一下：作为你的领导或者协作者在工作的过程中，最不喜欢听到的应该是诸如“我试试，我尽量...”这样的话。比较负责任的，好一点的回答是：我将在....之前....（例如：我将在下周二之前完成这个任务）。

最后，再分享一个个人工作的小技巧吧。和我做过同事的朋友应该能发现，我随时耳朵上都挂着蓝牙耳机。其实耳机里面并没有放任何音乐。但是当我做一些比较复杂的编程工作的时候，我带上没有声音、但是有降噪功能的耳机后的效率就是会高一些。能够让我更加专注于眼前的事情。

但是这样有个弊端就是有可能会给同事带来一种你不好接近，比较高冷的感觉。所以平时还是需要多和同事交流交流哦。

好了。感谢您的阅读，我坚持原创，十分欢迎并感谢您的关注。

以上。

欢迎关注公众号【why技术】。在这里我会分享一些技术相关的东西，主攻java方向，用匠心敲代码，对每一行代码负责。偶尔也会荒腔走板的聊一聊生活，写一写书评，影评。愿你我共同进步。