代码设计的探索 (上)

代码设计的探索 (上)

---

51CMM.COM原创 作者：河清 [2005/04/27] 

计算的世界每时每刻都在变化，步伐看起来是越来越快。程序员必须不断应付新的语言、新的工具和新的系统，它们总有一些与老东西不兼容的新特性。程序越来越大，界面越来越复杂，而任务的时限也越来越短。但是，总有某些东西是不变的，总有一些稳定点，在这种地方从过去中学到的东西和洞察力，对于未来必定能有所帮助。

简单性和清晰性是第一位的、最重要的。因为几乎所有其他东西都只能跟着它们而来。做那种最简单的能解决问题的东西，选择那些应该是足够快的最简单的算法、能够满足需要的最简单的数据结构；用整齐清楚的代码把它们组合起来。除非性能测试的结果说明需要做更多的事，我们绝不要把事情复杂化。接口应该是整齐和简单的，至少是在发现无可辩驳的证据、说明把它弄得复杂一些有极大优越性之前。

普遍性常与简单性同在。它使我们可能一次就完全解决了问题，而不是对各种情况一个个地重复去做。普遍性常常也是达到可移植的正确途径：找一个一般性的，能够在所有系统上工作的解，而不是去扩大不同系统之间的差异。

不断进化。想第一次就构造出一个绝好的程序通常是不可能的。发现正确解决方法的必要洞察力只能来自思考和经验的结合；纯粹的内省不可能造就出好系统，纯粹靠玩命干也不行。由用户得来的反馈在这个地方非常重要。通过循环的方式：原型、试验、用户反馈和进一步精化，常常是最有效的。我们自己构建的程序常常进化的不够；从别人那里买来的大程序变得太快，根本没经过必要的改进。

减少耦合。接口是程序设计战斗中的一个大战场，接口问题出现在许多不同的地方。程序库是最明显的例子，还有不同程序之间的、程序与用户之间的接口问题。对简单性和普遍性的需求在接口设计方面表现得特别强烈。我们应该使接口具有一致性，容易学习和使用，应该一丝不苟地追求这些东西。应该把实现细节都隐蔽在边界后面，这永远是最安全的方法。

符号标记。一直被忽视，实际上它远不仅仅是程序员告诉计算机去做什么时采用的方式。符号标记提供了一种组织框架，在实现应用领域非常广泛的各种工具方面，对指导人们去构造那种写程序的程序方面都很有价值。我们对大型的通用程序设计语言都很习惯了，它们为我们的大量程序设计工作服务。但有时也会发现面前的工作变得非常集中，已经理解得很清楚，写这种程序几乎完全是机械性的。这可能就预示着一个时机，说明应该建立一种能自然地表达有关工作的符号标记和一个实现它的语言。正则表达式是我们最喜爱的例子，实际中存在着无数的这种机会，在那里我们可以为对付特殊工作建立一个小语言。当然，这种语言绝不应该复杂到抵消掉其收益的程度。

作为程序员，我们很容易沉醉于新的工具和技术，但是，从长远的观点看，真正起作用的还是看我们在使用一些基础技术和规则的情况下工作的怎么样。通过应用本文中的某些思想，你将能够发现你的代码更容易用了，你的排错过程也不再那么痛苦了，你对自己的程序设计更加有自信心了。希望你在自己的程序员生涯中获得更多的成果和回报。

代码设计的过程

他（洛克菲勒）用经营管理的方法将打球（高尔夫）的动作分解开；一天他将球打出了160码远，于是它的妻子惊叹：“我应当知道，你做什么都比别人强”
------ 荣 . 切尔诺

我开始这样做的时候，我的代码至少减少了50%的BUG，而开发的效率提高了更多；当我成了项目经理的时候，我毫不迟疑的将它推广到整个项目组，它如此优秀超出了我的预想，以至于我觉得要向你收取费用！

目标的认识
对代码干什么、有哪些限制和约束、编码规范是什么等等，要有清晰、明确的认识，如果文档或者任务安排有不明白的地方要“不耻下问”，当然有时会有争论，但是总比最后痛苦的修改代码强。

算法和技术的准备
好多算法和技术不是那么清楚，没有办法只能学习加研究。往往会有很多的实验性代码。对于这些代码一定不要直接“拷贝”到程序中去。如果你这样做了，80%的情况下，你会后悔。

结构的规划
进入了正式的工作，根据任务的特点画一画流程图、状态图、协作图，考虑一下变量和常量，这些会使你工作的有条不紊，而且代码结构优良。现在我发现UML真是一个好东西。

编写代码
好了，你将建设自己的大厦。当然施工的过程中有一些“魔杖”，我们会在后面描述。

测试
没有经过有效测试的代码只是一堆文字。如果你们公司有单元测试规范，那么按照它进行。在XP方法中要求在编码前就设计测试，我觉得只要进行了有效测试就可以了，至于有效测试是怎样的，我们就不在这里讨论了。

排错
对有些项目，调试可占到整个开发时间的50％。对许多程序员来说，调试是编程最为困难的部分。曾经为了解决的程序中的一个错误睡眠中也念念不忘，接连几天没日没夜地工作——即使所编的程序并不复杂，在这里往往会体验到编程中有某种令人兴奋的东西。

注释的编写
不要忘了这一步。有时为了确认注释是否有效，可以找另外一位程序员看看，这样往往可以发现一些自身的盲点。有效注释不是时间的浪费，但是太多注释和没有注释一样糟糕。

代码的特性

代码的味道是对程序的一种感觉，他们具备一种能力，能看出你的代码的好坏。 如果代码有异味，他们会捂着鼻子走开
2002年6月15日

我们评价一个代码有很多的标准，如果我们进行总结，往往发现他们其实也不是那么的繁多。这里只总结了朴素的四条，通过一个售票员来说明，希望您的代码不会被“解雇”。

业务
“你是干什么的？”“我是卖票的”“那你怎么在扫垃圾”。是的，代码首先应当做它应当承担的责任。无论打扫的如何干净，他都不是一个好的售票员。不要小看这个问题，许多程序员经常自作主张添加一些额外的“精彩”内容，而“本职”的却在那墙角的边上。好的代码做好了它的职责，同样不会去做它不应当做的事情，即便那很精彩。

效率
“干得怎么样？”“一分钟卖一张”“太慢了”，老板的脸色已经有些难看了。我们评价一个代码还要看看它完成任务的效率和开销。不过在当前的硬件技术水平下，我们大多数时候可以把它放在其他“味道”的后面。

结构
“你卖票的过程是怎样的”“这个随便了，先收钱、或者先给票都有”，老板已经愤怒了。代码功能的划分、代码段的大小、代码之间的接口非常重要，有些研究者认为“首先为人编写程序，其次才是计算机”。没有好的代码结构，再多的注释也是惘然。结构不好，注释的结构也不好，甚至无法描述，如果你的程序是一个迷宫，那么迷宫的地图也会让你头昏脑胀。

容错
“如果卖票出了错怎么办？”“没办法只能听天由命”，于是老板决定解雇这个售票员。代码就像一辆汽车，它驾驶员的行为都是不可预测的。在容错性编程中，其中心思想是，即使一个子程序被传入了坏数据，它也不会被伤害，哪怕这个数据是由其它子程序错误而产生的。不管它被输入的是什么，一个好程序的特点是“输入垃圾，什么也不产生”，或“输入垃圾，输出错误信息”，也可以是“不允许垃圾进入”。从现在的观点来看“输入垃圾，输出垃圾”，往往是劣质程序。

当我对代码的味道有了解，我将我碰到的程序员进行了分类，可能不会包括所有，但是应当覆盖了大部分。我遇到过一些让我敬佩的程序员，有时甚至让我自卑，当然是前两种！

强悍型
他们追求代码执行的效率，总是在考虑更高的执行速度、更小的资源消耗、更大的安全性；他们的世界主要就是计算，他们的思维就是0和1的运算，有时反应快的就像闪电。

系统型
他们总是在编码前很好的规划代码的结构，追求代码结构的合理；在他们的手里无论多么复杂的算法就像建房子一样，许多的简单却结合成一个宏伟的大厦。他们的代码就像诗歌，一样让人充满了美感。

卖弄型
他们往往了解一些低层的东西，所以总是使用低层的东西，而不考虑哪些简单的办法；他们最大的骄傲在于大家都不懂的他的算法。