亲近代码

摘要：代码是我们的老朋友了，记得我们最先看到的就是这些逻辑严密的文字，代码让我们进入一个玄妙的逻辑世界，让我们收获每一份的喜悦和成就感。曾几何时，我们远离了代码，疏忽了代码，进入所谓的更高层次，比如架构啊，设计啊，模式啊，框架等，然而，我们得到了更好的结果了吗？我们的软件质量提高了吗？我们的客户更满意了吗？本文想重新说一说代码的事儿。

 

思想篇

代码，或者叫编程语言，本质上是一种表达，一种表达事物的语言，相比于其他表达方式,如声音,文字,图表, 代码应该是世界上最准确的语言之一．一个例子是UML, 每个人对UML的理解能力不同，加上自身的表达能力，它在实践中的应用并不顺利，也远没有编程语言应用的广泛，多数人觉得还是代码来的实在和精确．

 

然后编程语言固然清晰准确，却需要太多的语句，太多的周折，絮絮叨叨，多数人没有耐性去看它的表达，所以我们需要它的简化和抽象，而简化和抽象的东西，却并不能编译执行，我们只能叫它伪代码。它只是抽象和准确的一种妥协。

 

我们现在的问题就是在这个妥协中，你要抽象，就失去了准确，你要准确，就失去了抽象。鉴于人类的智慧，我们谈一件事情，只能先从自然语言（需求）起，然后是模型语言（设计），最后是编程语言，（至于机器语言，纯粹是其他学科的事，没有工程师们的事情）。用的也是逐步求精的法子，最后我们要的，就是好长好长的编程语言，虽然长，却最精确，虽然长，却是我们的目标。就如小说的价值在它那冗长的文字，而不是它的框架和提纲．

 

需求文档是半成品，设计图表是半成品，代码却是成品，如果你的精力都用到了半成品上，所有的努力就是达到一个半成品，忽视了后续的加工，那就是本末倒置，丧失了本质。实际上，工匠越到最后，越小心翼翼，越全神贯注！

 

代码里可以看到设计和需求，反之却不然。所以我们可以说代码即是设计，代码既是需求。如果你觉得这个结论太偏颇，那么一些常见的事情却是你我熟悉的：我们不断的在代码阶段修正你的设计，也是在代码阶段补充你的需求，甚至是更改你的需求。需求文档和设计文档最终都是为代码服务的，客户要求的也是能执行的代码，而不是一大堆的需求和设计文档。

 

也许有人说，我们用心测试就行了，让测试人员来把关，经验证明，寄希望于测试是天真和代价高昂的，自己写的乱七八糟的代码，自己都不愿意去检查，他人怎么能找到所有的明显和潜在的错误呢？就算都找到了，那也是数倍于编程的努力。你认真的梳理，平心静气的一行一行的去检查，会省却多少测试人员的工夫，审查代码，作为一种保证质量方式，成本远比测试来的小。

 

一些人认为编写代码者只是最底层的工人，纯粹是体力劳动，此大谬也。德鲁克在<<卓有成效的管理者>>一书中说，每一位知识工作者其实都是管理者—即使他没有所谓的职权，只要他能为组织做成贡献。我非常赞同这句话，体力劳动者都有现成的程序和标准来指导他，一切照程序工作即可，而知识劳动者需要用智慧处理变化的东西，是你在管理着这些变化，是你的决策影响着产品，其他人不会做和你一模一样的东西，你对组织的贡献是独一无二的! 生产线上生产代码是一向情愿的美丽设想。

 

技巧篇

我们都对大规模代码有恐惧和疏远的心理，无论是别人的代码或者自己的，这种下意识的心理，让阅读代码变为我们避之不及的东西，对自己写的代码，急于去测试，急于去验证它。早早的和你的代码拉开了距离；对于别人的代码，更是视之为天书，宁愿自己重写．

 

亲近代码，首要的就是要克服这种恐惧的心理，在内心里去接近你的代码，心平气和的去阅读你的代码, 心理问题解决了，其他的就好办了。

 

借鉴阅读文学的技巧，我们完全可以提高我们阅读代码的水平，就如在少年时期阅读那些美文一样，阅读文章有泛读，精读之分，有不求甚解和苦苦推敲之分。还记得我们中学里学的阅读技巧吗？首先通读第一遍，求个大概意思，然后精读重要的部分，最后根据问题去思索它背后的含义！

 

对于代码，首先，你要理解代码的背景，它是做什么的，解决什么问题的，哪些人用它，怎么用它，甚至代码的作者是谁，是什么水平，什么习惯等等，了解这些大的背景，非常有助于我们靠近这些代码，和它们交上初步的友谊！（就如语文老师告诉我们文章的社会环境，作者生平一样！）如果你不了解写这些代码幕后的人，可能你对一段玄妙莫测的代码研究了半天，最后才知道只是干了一件在你看来清晰明了的任务，而某一些你认为很容易的代码背后却是天才的思维！

 

其次就是了解代码所在的模块，具体的需求是什么，它是什么样的模型，什么样的架构和设计，很有可能你根本没有这些文档，那并不可怕，我们可以自己去想，去思考，按照正常的逻辑和自己的经验，它可能是什么样的，可能是怎样设计的。

 

最后就是阅读代码了，阅读代码，最重要的技巧就是全局观，沉下去，可以立马浮上来；最忌讳的就是思维被局部的代码所隔离了，每一处的代码是分散的，不相往来的，没有需求和设计在引导了，这样阅读是痛苦和恐怖的，你是被牵着鼻子走的，很容易就丧失信心，变得烦躁了。

 

在条件允许下，尽可能的单步调试去阅读你的代码，调试可以让你很快的找到脉络所在，调试的时候依然循着由粗到细的方法，有些代码什么时候进去，什么时候要略过，这需要很多次的实验和经过思考的判断。往往通过调试并不能阅读到所有的逻辑，因为逻辑依赖于输入的数据和环境设置，除非你有了所有可能的输入，可以进行任何路线的调试。不过调试仍不失一个快速理解代码的利器．

 

所有的软件都是有输入和输出的，你要牢牢把握住这两极，任何的模块，函数，你都要搞清楚它的输入和输出。数据流向，数据的依赖关系，这些都不应该被冗长的代码所掩盖。也许你用得着一些工具，比如草稿纸，记录你的思路，这样下次再来看这些代码，很容易继续前进。

 

还有很多的方法，比如以类的形式来看整个代码；还有查找功能，对一个类，或者变量，方法进行全面搜索，你会马上看到它在整个项目的应用情况，它的重要性和依赖性，都会得到充分的展现。

 

除了阅读别人的代码，更重要的是，你要为你自己的代码负责，要跟它交上朋友，能管理它，使之与你的思路吻合，一旦你觉得它面目可蹭，就必须对它重构，不断,及时的重构和完善，才能使它漂亮和优雅。这方面的技巧我们是比较熟悉的，这里就不赘述．

结束语

记得一个很有名的故事，大意是说的一个工厂设备坏了，请一个外国专家过来，老外在设备的某个地方用粉笔画了一个圈，说就是这个地方，你们打开修理吧。结果老外拿到10000美元，有人说画一个圈就拿那么多钱，老外回答是:画圈, 1美元, 找到在哪里画圈,9999美元。我们都熟悉这个故事，无论真假，作为软件工程师来说，你对自己的产品有这个自信吗? 你能配得上一个”专家”的称号吗?