原作: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要大,主要用来清除那些不易解决的问题,一个了解操作系统内核的人,一定有能力去解决他们遇到的绝大多数问题。