1 Do not add new functionality unless an implementation cannot complete
a real application without it.

除非一件真正的应用程式非用某种功能否则无法完成, 不然就不要添加新的功能.

按: 太多功能却处处相似劣於将他们整合为一个功能, 太多相似的功能往往造成
程式设计的选择困扰, 也就是去芜存菁, 方能显现功能的真正实用价值.

2 It is as important to decide what a system is not as to decide what it
is. Do not serve all the world's needs, but make the system extensible
so that additional needs can be met in an upwardly compatible fashion.

要决定一个系统是什麽跟决定一个系统不是什麽是同等重要的. 不须满足全世界
的需求, 而应让系统能够延伸扩张, 以便额外的需求能以往上相容的方式被满足.

按: 往上相容的意思是, 系统只须再做微小修改便可以将功能更新或扩充.

3 The only thing worse than generalizing from one example is generalizing
from no example at all.

唯一比从一个例子中归纳做出结论更糟只有从完全无例子中归纳做出结论.

按: 也就是说, 从许多例子中归纳做出结论是好的, 优於自己凭空造想.

4 If a problem is not completely understood, it is probably best to
provide no solution at all.

如果不能完全了解一个问题, 大概最好别提供任何解决之道.

按: 可能解决之道不符合问题本意, 误入歧途, 浪费精力.

5 If you get 90 percent of the desired effect for 10 percent of the work
required to get 100 percent, use the simpler solution.

如果因为一件工作的百分之十(该工作要求做到 100%), 你得到想要的效果之 90%,
则使用比较简单的解决之道.

按: 10% work -> 90% effect (easy) ; 剩馀 90% work 才 10% more effect (hard) ;
10% work 是比较好的解决之道, 简单, 有效率, 纵使不能尽善尽美.

6 Isolate complexity as much as possible.

尽可能把复杂性独立出来.

7 Provide mechanism rather than policy. In particular, place user interface
policy in the client's hands.

与其提供施行方针不如提供处理机制. 特别将使用者介面的施行方针交由客户处理.

按: policy => 大纲, 处理规定.
mechanism => 细则, 处理流程.

上述中文翻译与编按部分由我一手完成, 如有错谬之处, 欢迎来信指正. (ee)
--
well ... here is my E-mail: daniel@rs560.ncu.edu.tw
 
 

本文转自中文Linux论坛