从“把代码写得简单易懂到底好不好”想到的

引自我的博客：从“把代码写得简单易懂到底好不好”想到的

昨天在V2EX上看到一个话题，大意是“把代码写得简单易懂到底好不好”，题主的忧虑是代码写的简单易懂别人很容易上手，感觉可被取代感略大，容易遇到职业危机。初时一笑了之，夜里睡不着觉竟又想到了这个题目，今天不禁随记一篇。

代码写的简单易懂，说的高大上一点，就是代码的可读性高。从我一直以来受到的软件教育和工作经历来看，可读性绝对是软件高手追求的编码要点之一。甚至在APP层面，编译器越来越强大的今天，对可读性的重视甚至超过了代码执行效率，比如整型数除法，大可以直接使用“/”，没有必要殚精竭虑的使用移位运算“>>”去优化效率，因为不少效率上的优化编译器会搞定。代码本身是人与机器的沟通，就开发者本人而言，人的记忆是有限度的，以我这种资质较低的情况而言，自己编写的两个月以前的代码，如果没有相关的注释和文档，很难说能一目了然、记起当时的思路；并且大多数情况，软件开发是团队性质的，也就是说你的代码不仅仅是你一个人在维护，所以代码的可读性的提高，也是降低团队软件成员间沟通成本的方法。从代码质量的角度讲，刚好赶上最近正在译注、整理sonar的规则，几乎所有的代码风格规则和小部分的静态质量规则都是针对可读性来设立的。也就是说，就普通工程师而言，绝对是越高的手写的代码越通俗易懂，当然各路天才怪杰可能除外。所谓大巧若拙，大概就是这个道理吧。

有位同年的同事常玩笑说，每个程序员都是一块砖，言外之意是你干我干都一样，也有点被取代感略大、忧患意识强烈的意思。既然死于安乐，有点忧患意识总是好的。不过寄希望于把代码写的难懂来提高不可替代性，窃以为略不科学。因为代码写的难懂，除你之外无人愿意维护或者队员很难接手你的代码来合作，直接导致团队合作低效、这是能力不足的表现，是合格性问题。并且代码难懂并不是多么难处理的问题，对很多get到“重构”技能的程序员而言弄个新版本也不过是时间问题，地球离了谁都照样转。说一千道一万，这种想法最有可能的结果是——搬起石头砸自己的脚。

话虽如此，不可替代性还是提高一些的好，追求美好生活嘛，是每个人的权利和义务。如果不转道做产品的话，单纯从软件人员的角度讲，我所见到的有三个等级，码农、设计师、架构师，这个似乎也是职称考试相应的等级……如果觉得自己不可替代性较弱努力升个级就好了。当然不是说去考个高级点儿的证书，那玩意作用有限。初级阶段的猿类基本是靠ctrl+c和ctrl+v生存的，调一调系统的API，照着网上找来的demo改一改堆一堆，出了问题谷歌一下也能搞定，这样的状态自然易被取代。这个时候就要渐渐试图去理解什么是设计，具体有什么成系统方法也不好说，因为本猿也正在此道挣扎着，自问离正果还有些距离。至于成为设计师之后，应当是翻云覆雨、大巧若拙的境界吧，至于架构师，就是更高一级的存在了，倚楼听风雨、淡看江湖路。简单说，越往上，考虑的越是抽象的东西，但是这都基于对具体的东西的理解，打个比方，建一栋房子，有建筑师、有泥瓦匠，泥瓦匠是实施者，不同的匠人弄好自己那堆砖瓦泥浆就可以；建筑师是设计者，他只提供一张图纸，但是他的图纸也是基于对一砖一瓦的熟悉得来的，什么材料用于承重、什么材料用于装饰等等，都要成竹于胸才能画出合格的图纸。所以说目前的段位，努力提高自己的编码水平，领悟好什么是设计才是正道。

原题目下好多大牛回复，题主的问题想必也弄明白了。我不过是记下自己今时的想法，聊以自勉罢了。