编程的6个原则

原作：Joseph Ottinger

 

这篇文章实际表述了编程时应引起注意的很重要的6个思想：

快速失败；

写更少的代码（不要让自己重复）；

程序是写给人看的；

做正确的事情；

消减状态；

了解你的“创造”

（fail fast, write less code (and don't repeat yourself), computer programs are for people, do the right thing, reduce state, and know your 'stuff.'）

快速失败：当程序出现问题时，产生大的、可见的、不可忽视的异常。以防止不明显的bug一遍遍逃过QA的检查。把隐藏在深处的问题暴露出来。

写更少的代码（似乎是理所当然的）：去除冗余，即把程序所要解决的问题展示得更加清晰、明了。

程序是写给人看的：即“学识编程”（Literate Programming），我们程序的读者是其他的人而不是编译器。我们知道c/java/lisp/haskell这些编程语言并不比简单的汇编更加强大，之所以我们使用它们，是因为它们的表述更加清晰，更不容易范些低级的错误。没有任何一个程序能做到只能用一种书写，而不能用另一种，而且，这些语句，最终都要被翻译成机器指令（有些在运行期，有些在编译期，不过都不重要），如此说来，我们使用高级程序设计语言的唯一理由就是——和人进行交流。Don Knuth写下了这个想法，并把它命名为“Literate Programming”，他还设计了一个叫WEB的系统，他的想法非常出色，但他的实现却很糟糕。他的想法是：在程序中加入一篇说明程序是如何运行的的文章。

做正确的事情：实际编程去让正确的程序去做正确的事情，而不是写一个看似正常工作程序。
我知道最佳的解决方案，但需要改变许多东西。在我的经验里，经常有让你做错误事情的机会：计划、经理、合作者，甚至是参与到项目中来的客户，这些群体都想尽快看到你的可以工作的程序，他们并不关系你是如何写这些程序的。但除了事实上写这些程序的程序员外，没有人知道，在编码过程中所作的权衡、割舍。然后隐藏在代码背后的问题就会像圣诞节的幽灵一样以P0 bugs的形式出现（P0 bug:致命缺陷——译者注）。最终，我不得不顶着上面巨大的压力，带给公司更多的花费。让早就该做好的程序去做正确的事情。

消减状态：即简化代码，尤其要注意并发的情况，这时会出现如：x.equals(x)这样的奇怪代码，而且在一些特殊的情况下会返回false,当然，这取决于x.equals(Object)是怎样编码的。

了解你的“创造”：正如可工作的解决方案总是你尝试的最后一个解决方案一样，无法诊断的bug总是存在于你还不了解的软件层中。你必须去了解直接包裹在你代码周围的那些层——对于大多数程序员来说，这可能意味着要从操作系统开始。如果你从事底层编程，你很可能还要了解一些计算机体系结构。但这个观点比直接找到隐藏的bug要大，主要用来清除那些不易解决的问题，一个了解操作系统内核的人，一定有能力去解决他们遇到的绝大多数问题。