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、二零一一年一月十三日。
轉載于:https://www.cnblogs.com/myitworld/archive/2011/01/13/2214689.html
總結
以上是生活随笔為你收集整理的unix编程艺术中的17点编程原则--设计开发者的至高准则的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 关于初级java程序员面试题总结（每月更
- 下一篇： g ++在linux下编译rapidxm