实战型开发--3/3，clean code

编程的纯粹

hmmm，一开始在这个环节想聊一些具体的点，其实也就是《clean code》这本书中的点，但这个就还是更流于表面；
因为编码的过程，就更接近于运动员打球，艺术家绘画，棋手下棋的过程，是一个更加纯粹的过程；
相比而言，谈及业务，谈及设计则是要理性综合多种因素，不似编程本身这么纯粹。

所以这个部分首先要谈的是《程序员的思维修炼》中的专家级工程师的思维方式，也就是技艺精通之后的左右脑结合的工作方式。

就个人经验来看，安静的写出好的程序，这件事情本身就是超爽的。
享受这个过程，追求技艺的精益求精，是写出clean code背后的最有力的动因和意义所在。
这点可以从

• john carmack在编写doom程序时候看到（《doom启示录》），
• 在吴清源追求致中和中看到：[吴清源新传]

所以写出简洁代码的核心要义在于：

• 编程的时候沉浸&享受其中
• 持续的追求“简洁优雅，无懈可击”，这是一个一直可以追求的状态

在这种状态下，持续的打磨自己的代码，那么即便不看clean code，里面的内容自己都可以悟出来；
这也是很多优秀同事的共同感受，大家看到clean code时候，没有太多的：“哦，原来要这么写”的意外，而是充满共鸣的“嗯，就是这样的，我也这么想的，我也这么做的”；

《clean code》

基本上《clean code》这个书覆盖了足够多的内容，里面也有足够的原因，这里谈及几个话题：

精简 & 实用平衡

比如naming这个章节，会谈及名字应该起的精简，但是需要：

• 表达出足够的含义
• 和干的事情匹配
• 要易于搜索（现在工具已经好多了，可以比较容易的检索到，这也让起名字更容易一些）

实际工作中看到一些同学追求极简，为了少几行代码，让程序的可理解性下降，就是实用性不足；

考虑到复杂度&脑力消耗

函数这个章节，需要控制函数的层级，规模；
一个巨大的函数，里面代码有的做的非常底层，有的有很高层这种层次不清就是一个糟糕的函数；
层次清晰，规模看起来很轻松，就是比较好的函数；
这点就是和复杂度以及人脑的承受度有关；

内力：让简洁代码成为习惯

简洁代码绝不是若干条规则就可以概括，更不是看书就能看出来的（看代码倒是有可能）；
这个源于长期的练习，我和周围得出的经验就是，要去崇尚简洁代码，并且每个代码模块都反复重构到以能写到的最简洁优雅，无懈可击的程度收尾。
笔者好友的经历就非常有代表性：
开始工作的时候，常常会把写好的代码反复重构重写3-4遍，到自己觉得完美为止；
过了几个月回过头来看当时觉得完美的代码，又是漏洞百出，又做一些整理重构；
时间长了之后，一般第一版就能写出不错的了，然后稍微整理加一些注释就好了；

到团队里一些功力深厚的同事确实也是这样的，每次写都是水准之上；

这种事情不止体现在代码上，也有程序设计甚至做事方式上，所以尽管有时候我们在rush，但是提交和代码依旧可以整洁不乱，不会出现莫名的不过，这就是内力