Unix編程藝術(shù)中的17點(diǎn)編程哲學(xué)原則????????

? ---設(shè)計(jì)開發(fā)者的至高準(zhǔn)則

?

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

參考文獻(xiàn)：The Art of Unix Programming
By Eric Steven Raymond

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

一、unix編程藝術(shù)一書介紹
本書主要介紹了Unix系統(tǒng)領(lǐng)域中的設(shè)計(jì)和開發(fā)哲學(xué)、思想文化體系、原則與經(jīng)驗(yàn)，
由公認(rèn)的Unix編程大師、開源運(yùn)動領(lǐng)袖人物之一Eric S. Raymond傾力多年寫作而成。

?

包括Unix設(shè)計(jì)者在內(nèi)的多位領(lǐng)域?qū)＜乙矠楸緯暙I(xiàn)了寶貴的內(nèi)容。
本書內(nèi)容涉及社群文化、軟件開發(fā)設(shè)計(jì)與實(shí)現(xiàn)，覆蓋面廣、內(nèi)容深邃，完全展現(xiàn)了作者極其深厚的經(jīng)驗(yàn)積累和領(lǐng)域智慧。

二、unix哲學(xué)基礎(chǔ)
unix管道的發(fā)明人、unix傳統(tǒng)的奠基人之一Doug McIlroy在<<unix的四分之一世紀(jì)>>中，
這樣總結(jié)unix的哲學(xué)：
編寫的一個程序只做一件事，并做好。編寫的程序要相互協(xié)作，
同時，要能處理文本流，因?yàn)槟鞘亲钇胀?或最基本)的接口。

?

Rob Pike，是最偉大的c語言大師之一，他在<<Notes on C Programming>>一書中，
從各個不同的角度，闡述了unix哲學(xué)的幾個原則：
原則1：你無法斷定程序會在哪個地方耗費(fèi)它的運(yùn)行時間。瓶頸常常出現(xiàn)在意想不到的地方，
所以，別急著胡亂找個地方，亂改一通，除非你確實(shí)已經(jīng)找到并證實(shí)問題的癥結(jié)所在。

?

原則2：估量。在你還沒有對程序代碼進(jìn)行整體估量之前，尤其是還沒找到最耗時的那部分之前，
別去天真的想著優(yōu)化速度。

?

原則3：花俏的算法通常在n比較小時，很慢。因?yàn)?#xff0c;花俏而不切實(shí)際的算法的常數(shù)復(fù)雜度很大。
除非你能確定n一定是很大的，否則，不要去冒昧的使用花俏算法(即使n很大，也要優(yōu)先考慮原則2)。

?

原則4：花俏的算法比簡單而切實(shí)際的算法更容易出錯(bug)、且更難實(shí)現(xiàn)(維護(hù))。所以，非情不得已時，
盡量采用簡單的算法，與簡單的數(shù)據(jù)結(jié)構(gòu)相配合。

?

原則5:數(shù)據(jù)壓倒一切。如果，你已經(jīng)選擇了正確的數(shù)據(jù)結(jié)構(gòu)并且把一切都組織的井井有條，
那么，正確高效的算法不言而喻。編程的核心在數(shù)據(jù)結(jié)構(gòu)，而不在算法。(僅代表Rob Pike個人觀點(diǎn))。

?

Ken Thompson，unix最初版本的設(shè)計(jì)者，和實(shí)踐者，面對上述Rob Pike的原則4時，說道：
如果你拿不準(zhǔn)，就窮舉吧。

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

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

1、Rule of Modularity: Write simple parts connected by clean interfaces.
1、模塊原則：盡量使用簡潔的接口套和簡單的組件。
正如，Brian Kernighan 曾經(jīng)說過，"計(jì)算機(jī)編程的本質(zhì)就是盡量控制(降低)程序的復(fù)雜度"。
設(shè)計(jì)一個程序，調(diào)試糾錯往往占了大部分的開發(fā)時間，最終弄出一個拿得出手的可用系統(tǒng)，
與其說是才華橫溢的設(shè)計(jì)成果，還不如說是一路磕磕碰碰的結(jié)果。

?

編寫復(fù)雜而龐大的軟件，唯一的方法，就是控制好，并降低程序的整體復(fù)雜度，用清晰的接口把若干的模塊組合成一個復(fù)雜軟件。

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

2、Rule of Clarity: Clarity is better than cleverness.
2、清晰原則:清晰勝于取巧。
寫的程序，是給計(jì)算機(jī)執(zhí)行的，但卻是給人看的，如程序后期的維護(hù)。
一個艱深晦澀的程序，將使后期的維護(hù)、修正、甚至性能提升、算法優(yōu)化等工作，都將重重受阻。

?

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

3、Rule of Composition: Design programs to be connected to other programs.
3、組合原則：設(shè)計(jì)時，要考慮連接組合。
考慮盡量讓程序彼此之間能通信，讓程序具有組合性，彼此模塊獨(dú)立。

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

?

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

5、Rule of Simplicity: Design for simplicity; add complexity only where you must.
5、簡潔原則：設(shè)計(jì)盡可能簡潔，復(fù)雜度能低則低。
有的程序員，常常喜歡搗一些錯綜復(fù)雜的東西，來顯示或滿足自己的優(yōu)越感、虛榮感。
程序員都很聰明，因自己有足夠的能力玩轉(zhuǎn)一些復(fù)雜而抽象的東西，而引以為傲，這本無可厚非。

?

但與此同時，他們在玩弄復(fù)雜、故弄玄虛的之后，必將深感厭惡程序之糾錯調(diào)試工作。
因?yàn)?#xff0c;故弄玄虛的代價(jià)，就是一堆代價(jià)高昂的廢品。

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

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

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

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

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、表示(法)原則：把知識疊入數(shù)據(jù)，以求邏輯結(jié)構(gòu)質(zhì)樸而健壯。
建模，以求邏輯結(jié)構(gòu)清晰。

10、Rule of Least Surprise: In interface design, always do the least surprising thing.
10、通俗原則：接口設(shè)計(jì)，避免標(biāo)新立異。
程序的好壞由用戶來評判，最簡單易用、最通俗易懂的程序，往往是最受用戶歡迎的程序。

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、補(bǔ)救原則：出現(xiàn)異常時，馬上退出并適當(dāng)給出足夠的出錯信息。
盡可能讓程序以一種容易診斷出錯誤的方式終止掉。

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

time.
13、經(jīng)濟(jì)原則：寧可多花機(jī)器一分，也不浪費(fèi)程序員一秒。
時刻記住，程序員的時間是寶貴的，不要無故浪費(fèi)一分一秒。

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

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

?

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

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

?

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

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

think.
17、擴(kuò)展原則：設(shè)計(jì)要著眼于未來，因?yàn)橛袝r未來來的要比想象中的快。
永遠(yuǎn)不要認(rèn)為自己的設(shè)計(jì)已經(jīng)完美了，可以終止優(yōu)化、或提升了。

所以，要為數(shù)據(jù)格式，和代碼留下可擴(kuò)展的空間，后期你自會發(fā)現(xiàn)，當(dāng)初的選擇是明智的。

因此，設(shè)計(jì)要著眼于未來。
ok，更多請參考原書。完。
---------------------------------

?

作者聲明：
本人July對本博客所有文章和資料享有版權(quán)，轉(zhuǎn)載或引用任何文章、資料請注明出處。
向您的厚道致敬。謝謝。July、二零一一年一月十三日。

轉(zhuǎn)載于:https://www.cnblogs.com/myitworld/archive/2011/01/13/2214689.html

總結(jié)

以上是生活随笔為你收集整理的unix编程艺术中的17点编程原则--设计开发者的至高准则的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。