unix編程藝術中的17點編程原則–設計開發人員的至高準則

Unix編程藝術中的17點編程哲學原則        

  ---設計開發人員的至高準則

 

譯者:July   二零一一年一月十三日。

參考文獻：The Art of Unix Programming
By Eric Steven Raymond

博主說明：本文是依據unix編程藝術一書的英文版，第一章部分章節，所做的翻譯。
翻譯過程中，參考了其中文版(薑宏等譯)。若有更好的翻譯意見，歡迎留言提議。
---------------------------------------

一、unix編程藝術一書介紹
本書主要介紹了Unix系統領域中的設計和開發哲學、思想文化體系、原則與經驗，
由公認的Unix編程大師、開源運動領袖人物之一Eric S. Raymond傾力多年寫作而成。

 

包括Unix設計者在內的多位領域專家也為本書貢獻了寶貴的內容。
本書內容涉及社群文化、軟體開發設計與實現，覆蓋面廣、內容深邃，完全展現了作者極其深厚的經驗積累和領域智慧。

二、unix哲學基礎
unix管道的發明人、unix傳統的奠基人之一Doug McIlroy在<<unix的四分之一世紀>>中，
這樣總結unix的哲學：
編寫的一個程式只做一件事，並做好。編寫的程式要相互協作，
同時，要能處理文字資料流，因為那是最普通(或最基本)的介面。

 

Rob Pike，是最偉大的c語言大師之一，他在<<Notes on C Programming>>一書中，
從各個不同的角度，闡述了unix哲學的幾個原則：
原則1：你無法斷定程式會在哪個地方耗費它的已耗用時間。瓶頸常常出現在意想不到的地方，
所以，別急著胡亂找個地方，亂改一通，除非你確實已經找到並證實問題的癥結所在。

 

原則2：估量。在你還沒有對程式碼進行整體估量之前，尤其是還沒找到最耗時的那部分之前，
別去天真的想著最佳化速度。

 

原則3：花俏的演算法通常在n比較小時，很慢。因為，花俏而不切實際的演算法的常數複雜度很大。
除非你能確定n一定是很大的，否則，不要去冒昧的使用花俏演算法(即使n很大，也要優先考慮原則2)。

 

原則4：花俏的演算法比簡單而切實際的演算法更容易出錯(bug)、且更難實現(維護)。所以，非情不得已時，
盡量採用簡單的演算法，與簡單的資料結構相配合。

 

原則5:資料壓倒一切。如果，你已經選擇了正確的資料結構並且把一切都組織的井井有條，
那麼，正確高效的演算法不言而喻。編程的核心在資料結構，而不在演算法。(僅代表Rob Pike個人觀點)。

 

Ken Thompson，unix最初版本的設計者，和實踐者，面對上述Rob Pike的原則4時，說道：
如果你拿不準，就窮舉吧。

三、unix哲學原則
更多的unix哲學藝術，不是由先哲們口頭所闡述的，而是由他們所作的一切，包括unix本身，所體現出來

的。從整體上來說，可以概括為以下17點原則：

1、Rule of Modularity: Write simple parts connected by clean interfaces.
1、模組原則：盡量使用簡潔的介面套和簡單的組件。
正如，Brian Kernighan 曾經說過，"電腦編程的本質就是盡量控制(降低)程式的複雜度"。
設計一個程式，調試錯誤修正往往佔了大部分的開發時間，最終弄出一個拿得出手的可用系統，
與其說是才華橫溢的設計成果，還不如說是一路磕磕碰碰的結果。

 

編寫複雜而龐大的軟體，唯一的方法，就是控制好，並降低程式的整體複雜度，用清晰的介面把若干的模組組合成一個複雜軟體。

這就是，模組原則，即盡量模組化，各模組之間，減少耦合，如此獨立，才不會在改動時，牽一處，而動全身。

2、Rule of Clarity: Clarity is better than cleverness.
2、清晰原則:清晰勝於取巧。
寫的程式，是給電腦執行的，但卻是給人看的，如程式後期的維護。
一個艱深晦澀的程式，將使後期的維護、修正、甚至效能提升、演算法最佳化等工作，都將重重受阻。

 

所以，編寫程式的時候，時刻牢記：編寫清晰易懂的程式，添加良好有用的注釋。
於人於己，皆有利。

3、Rule of Composition: Design programs to be connected to other programs.
3、組合原則：設計時，要考慮串連組合。
考慮盡量讓程式彼此之間能通訊，讓程式具有組合性，彼此模組獨立。

4、Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
4、分離原則：策略同機制分離，介面同引擎分離。
如果，將策略同機制，雜糅成一團，將會有倆個負面影響，
一、是策略變得死板，難以適應使用者需求的改變；二、這樣做的同時，也將意味著任何策略的改變都將極有可能動搖到整個機制。

 

而，相反，將策略同機制，倆者分離的話，就可能在嘗試新策略的時候，不會打破原有機制。
且，我還能更容易的為機制編寫出較好的測試案例。

5、Rule of Simplicity: Design for simplicity; add complexity only where you must.
5、簡潔原則：設計儘可能簡潔，複雜度能低則低。
有的程式員，常常喜歡搗一些錯綜複雜的東西，來顯示或滿足自己的優越感、虛榮感。
程式員都很聰明，因自己有足夠的能力玩轉一些複雜而抽象的東西，而引以為傲，這本無可厚非。

 

但與此同時，他們在玩弄複雜、故弄玄虛的之後，必將深感厭惡程式之錯誤修正調試工作。
因為，故弄玄虛的代價，就是一堆代價高昂的廢品。

所以，最好的方式是，簡潔為美。一切，以簡潔至上。

6、Rule of Parsimony: Write a big program only when it is clear by demonstration that

nothing else will do.
6、吝嗇原則：除非別無他法，否則，不要去編寫龐大的程式。
這點，跟上第5點差不多，以簡潔為美，不要刻意去編寫龐大而複雜的程式。

7、Rule of Transparency: Design for visibility to make inspection and debugging easier.
7、透明原則：設計要透明可見，以便審查和調試。
充分考慮透明性、顯見性、簡潔性。

8、Rule of Robustness: Robustness is the child of transparency and simplicity.
8、健壯原則：健壯的程式源於透明與簡潔。
程式越簡潔，越透明，程式就越健壯。

9、Rule of Representation: Fold knowledge into data so program logic can be stupid and

robust.
9、表示(法)原則：把知識疊入資料，以求邏輯結構質樸而健壯。
建模，以求邏輯結構清晰。

10、Rule of Least Surprise: In interface design, always do the least surprising thing.
10、通俗原則：介面設計，避免標新立異。
程式的好壞由使用者來評判，最簡單易用、最通俗易懂的程式，往往是最受使用者歡迎的程式。

11、Rule of Silence: When a program has nothing surprising to say, it should say nothing.
11、緘默原則：如果一個程式沒什麼好挑剔的，那就保持沉默。
程式不要有多餘冗雜的部分，盡量簡潔為上，不需要的多餘功能，就不要有。

12、Rule of Repair: When you must fail, fail noisily and as soon as possible.
12、補救原則：出現異常時，馬上退出並適當給出足夠的出錯資訊。
儘可能讓程式以一種容易診斷出錯誤的方式終止掉。

13、Rule of Economy: Programmer time is expensive; conserve it in preference to machine

time.
13、經濟原則：寧可多花機器一分，也不浪費程式員一秒。
時刻記住，程式員的時間是寶貴的，不要無故浪費一分一秒。

14、Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
14、產生原則：避免手工hack(直譯了)，儘可能編寫程式，讓程式去產生程式。
程式規格越簡單，設計者就越容易做對。

15、Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
15、最佳化原則：雕刻前先要有模型，跑之前，要先學會走。
先製作原型，再精雕細琢。最佳化之前，先確保能用。否則，一切美妙的最佳化，都是白搭。
或者如，極限編程大師 Kent Beck所說，先求運行，再求正確，最後求快。

 

不要一味的去考慮那些蠅頭小利的所謂效率提升。過早最佳化，往往成為一切萬惡之根源。

16、Rule of Diversity: Distrust all claims for "one true way".
16、多樣原則：絕不要去相信什麼所謂"不二法則"的言論。
即使最出色的軟體，也常常會受限於設計者的想象力。
愛因斯坦曾說過一句話，這個世界缺乏的不是技術，而是想象力。

 

沒有人能聰明到把所有的東西，都能事先預言安排好。

17、Rule of Extensibility: Design for the future, because it will be here sooner than you

think.
17、擴充原則：設計要著眼於未來，因為有時未來來的要比想象中的快。
永遠不要認為自己的設計已經完美了，可以終止最佳化、或提升了。

所以，要為資料格式，和代碼留下可擴充的空間，後期你自會發現，當初的選擇是明智的。

因此，設計要著眼於未來。
ok，更多請參考原書。完。
---------------------------------

 

作者聲明：
本人July對本部落格所有文章和資料享有著作權，轉載或引用任何文章、資料請註明出處。
向您的厚道致敬。謝謝。July、二零一一年一月十三日。