1 Unix哲學(xué)

Unix哲學(xué)強(qiáng)調(diào)實(shí)用性，源自豐富經(jīng)驗(yàn)，不受傳統(tǒng)方法學(xué)或標(biāo)準(zhǔn)限制。這種知識更像是潛在的、半本能的。Unix程序員通過開發(fā)經(jīng)驗(yàn)積累的知識可讓其他程序員受益。

(1) 每個(gè)程序應(yīng)專注于完成一項(xiàng)任務(wù)，遇到新任務(wù)時(shí)應(yīng)重新開始，避免在原程序中添加新功能而導(dǎo)致復(fù)雜性增加。(2) 假設(shè)程序的輸出將成為另一個(gè)程序的輸入，即使下一個(gè)程序尚不清楚，也應(yīng)確保輸出中不包含無關(guān)信息。(3) 盡早將設(shè)計(jì)和編寫的軟件投入試用，對低質(zhì)量代碼應(yīng)果斷放棄并重新編寫。(4) 使用工具優(yōu)先于低效的輔助手段來減輕編程任務(wù)的負(fù)擔(dān)，精益求精，必須善用工具。

2 編碼原則

Unix 哲學(xué)的精髓并非僅僅是先賢們口頭傳達(dá)的，更多地體現(xiàn)在他們的實(shí)踐和Unix系統(tǒng)本身的設(shè)計(jì)。這一哲學(xué)可以概括為幾個(gè)關(guān)鍵點(diǎn)：

初學(xué)軟件工程時(shí)，應(yīng)深入體會這些原則。雖然大部分文章都推崇這些準(zhǔn)則，但很多系統(tǒng)缺乏實(shí)踐工具和傳統(tǒng)，導(dǎo)致程序員無法貫徹這些原則。他們常常受制于糟糕的工具、設(shè)計(jì)不佳、過度勞累和冗余代碼。

2.1 ?模塊原則：使用簡潔的接口拼合簡單的部件

編程的核心在于管理復(fù)雜性。解決錯(cuò)誤占據(jù)了大部分開發(fā)時(shí)間。一個(gè)可用系統(tǒng)的成功更多是由于不斷嘗試、調(diào)整，而不僅僅是天賦或設(shè)計(jì)技巧。

匯編語言、編譯語言、流程圖、過程化編程、結(jié)構(gòu)化編程、面向?qū)ο蟆⒁约败浖_發(fā)方法論，被過分吹捧。但它們卻增加了程序的復(fù)雜度，超出人腦處理能力。

為了成功開發(fā)復(fù)雜軟件，降低整體復(fù)雜度并通過簡單模塊的清晰接口組合是關(guān)鍵。這樣可以使問題局限在特定部分，從而更容易改進(jìn)局部而不影響整體。

2.2 ?清晰原則：清晰勝于機(jī)巧

編寫代碼時(shí)要考慮到未來維護(hù)的復(fù)雜性和成本。代碼應(yīng)該易于閱讀和理解，以便他人或自己在必要時(shí)能夠輕松修改和維護(hù)。

在Unix傳統(tǒng)中，這個(gè)原則不僅僅適用于代碼注釋。在Unix的最佳實(shí)踐中，也強(qiáng)調(diào)在選擇算法和實(shí)現(xiàn)時(shí)要考慮到未來的可擴(kuò)展性。盡管為了稍微提升程序性能而增加技術(shù)復(fù)雜性和混亂性可能誘人，但這種做法是得不償失的。這不僅因?yàn)閺?fù)雜的代碼容易引發(fā)bug，還因?yàn)樗鼤黾尤蘸蟮拈喿x和維護(hù)難度。相反，優(yōu)雅且清晰的代碼不僅更加穩(wěn)定，還更易于其他人理解和修改。這一點(diǎn)至關(guān)重要，特別是因?yàn)榭赡茉谖磥頂?shù)年內(nèi)需要回頭修改這些代碼的人可能會是你自己。

永遠(yuǎn)不要去吃力地解讀一段晦澀的代碼三次。第一次也許僥幸成功，但如果發(fā)現(xiàn)必須重新解讀一遍——離第一次太久了，具體細(xì)節(jié)無從回想，那就該注釋代碼了，這樣第三次就相對不會那么痛苦了。

2.3 ?組合原則：設(shè)計(jì)時(shí)考慮拼接組合

如果程序彼此之間不能有效通信，那么軟件就難免會陷入復(fù)雜度的泥淖。

在輸入輸出方面， Unix 傳統(tǒng)極力提倡采用簡單、文本化、面向流、設(shè)備無關(guān)的格式。在經(jīng)典的 Unix 下，多數(shù)程序都盡可能采用簡單過濾器的形式，即將一個(gè)輸入的文本流處理為一個(gè)簡單的文本流輸出。拋開世俗眼光，Unix程序員偏愛這種做法并不是因?yàn)樗麄兂鹨晥D形用戶界面，而是因?yàn)槿绻绦虿徊捎煤唵蔚奈谋据斎胼敵隽?，它們就極難銜接。

Unix 中文本流之于工具，就如同在面向?qū)ο蟓h(huán)境中的消息之于對象。文本流界面的簡潔性加強(qiáng)了工具的封裝性。而許多精致的進(jìn)程間通訊方法，比如遠(yuǎn)程過程調(diào)用，都存在各程序牽扯過多的傾向。

要想讓程序具有組合性，就要使程序彼此獨(dú)立。在文本流這一端的程序應(yīng)該盡可能不要考慮文本流另一端的程序。將一端的程序替換為另一個(gè)截然不同的程序，而完全不驚擾另一端應(yīng)該很容易做到。GUI ?可以是個(gè)好東西，在做 GUI前，應(yīng)該想想可不可以把復(fù)雜的交互程序跟干粗活的算法程序分離開，每個(gè)部分單獨(dú)成為一塊，然后用一個(gè)簡單的命令流或者是應(yīng)用協(xié)議將其組合在一起。

在構(gòu)思精巧的數(shù)據(jù)傳輸格式前，有必要實(shí)地考察一下，是否能利用簡單的文本數(shù)據(jù)格式；以一點(diǎn)點(diǎn)格式解析的代價(jià)，換得可以使用通用工具來構(gòu)造或解讀數(shù)據(jù)流的好處是值得的。

當(dāng)程序無法自然地使用序列化、協(xié)議形式的接口時(shí)，正確的 Unix 設(shè)計(jì)至少是，把盡可能多的編程元素組織為一套定義良好的 API 。這樣至少可以通過鏈接調(diào)用應(yīng)用程序，或根據(jù)不同任務(wù)的需求粘合使用不同的接口。

2.4 ?分離原則：策略同機(jī)制分離，接口同引擎分離

策略和機(jī)制是按照不同的時(shí)間尺度變化的，策略的變化要遠(yuǎn)遠(yuǎn)快于機(jī)制。把策略同機(jī)制揉成一團(tuán)有兩個(gè)負(fù)面影響：一來會使策略變得死板，難以適應(yīng)用戶需求的改變，二來也意味著任何策略的改變都極有可能動搖機(jī)制。相反，將兩者剝離，就有可能在探索新策略的時(shí)候不足以打破機(jī)制。另外，也更容易為機(jī)制寫出較好的測試。

實(shí)現(xiàn)剝離的一個(gè)方法，將應(yīng)用程序分成可以協(xié)作的前端和后端進(jìn)程，通過套接字上層的專用應(yīng)用協(xié)議進(jìn)行通訊。前端實(shí)現(xiàn)策略，后端實(shí)現(xiàn)機(jī)制。比起僅用單個(gè)進(jìn)程的整體實(shí)現(xiàn)方式來說，這種雙端設(shè)計(jì)方式大大降低了整體復(fù)雜度 ，bug 有望減少，從而降低程序的壽命周期成本。

2.5 ?簡潔原則：設(shè)計(jì)要簡潔，復(fù)雜度能低則低

來自多方面的壓力常常會讓程序變得復(fù)雜（由此代價(jià)更高， bug ?更多)，其中 一種壓力就是來自技術(shù)上的虛榮心理。程序員們都很聰明，常常以能玩轉(zhuǎn)復(fù)雜東西和耍弄抽象概念的能力為傲，這一點(diǎn)也無可厚非。但正因如此常常會與同行們比試，看看 誰能夠鼓搗出最錯(cuò)綜復(fù)雜的美妙事物，他們的設(shè)計(jì)能力大大超出他們的實(shí)現(xiàn)和排錯(cuò)能力，結(jié)果便是代價(jià)高昂的廢品。

”錯(cuò)綜復(fù)雜的美妙事物”聽來自相矛盾。Unix ?程序員相互比的是誰能做到 “簡潔而漂亮”，這一點(diǎn)雖然只是隱含在這些規(guī)則之中，但還是很值得公開提出來強(qiáng)調(diào)一下。

至少在商業(yè)軟件領(lǐng)域里，過度的復(fù)雜性往往來自于項(xiàng)目的要求，而這些要求常?；谕其N熱點(diǎn)，而不是基于顧客的需求和軟件實(shí)際能夠提供的功能。許多優(yōu)秀的設(shè)計(jì)被市場推銷所需要的大堆“特性清單”扼殺，實(shí)際上這些特性功能幾乎從未用過。然后，惡性循環(huán)開始了，比別人花哨的方法就是把自己變得更花哨。很快，龐大臃腫變成了業(yè)界標(biāo)準(zhǔn)，每個(gè)人都在使用臃腫不堪、bug 極多的軟件，連軟件開發(fā)人員也不敢敝帚自珍。

避免這些陷阱，唯一的方法就是鼓勵另一種軟件文化，以簡潔為美。這是一個(gè)非常看重簡單解決方案的工程傳統(tǒng)，總是設(shè)法將程序系統(tǒng)分解為幾個(gè)能夠協(xié)作的小部分，并本能地抵制任何用過多噱頭來粉飾程序的企圖。

2.6 ?吝嗇原則：除非確無它法，不要編寫龐大的程序

“大”有兩重含義：體積大，復(fù)雜程度高。程序大了，維護(hù)起來就困難。由于對花費(fèi)了大量精力才做出來的東西難以割舍，結(jié)果導(dǎo)致在龐大的程序中，把投資浪費(fèi)在注定要失敗，或并非最佳的方案上。避免不必要的代碼和邏輯，保持代碼精簡。

2.7 ?透明性原則：設(shè)計(jì)要可見，以便審查和調(diào)試

因?yàn)檎{(diào)試通常會占用四分之三甚至更多的開發(fā)時(shí)間，所以一開始就多做點(diǎn)工作以減少日后調(diào)試的工作量會很劃算。一個(gè)有效的減少調(diào)試工作量的方法，就是設(shè)計(jì)時(shí)充分考慮透明性和顯見性。

軟件系統(tǒng)的透明性是指一眼就能看出軟件在做什么以及怎樣做的。顯見性指程序帶有監(jiān)視和顯示內(nèi)部狀態(tài)的功能，這樣程序不僅能夠運(yùn)行良好，而且還可以看出它以何種方式運(yùn)行。

設(shè)計(jì)時(shí)如果充分考慮到這些要求會給整個(gè)項(xiàng)目全過程帶來好處。調(diào)試選項(xiàng)的設(shè)置盡量不要在事后，而應(yīng)該在設(shè)計(jì)之初便考慮進(jìn)去，程序不但應(yīng)該能展示其正確性，也應(yīng)該能把原開發(fā)者解決問題的思維模型告訴后來者。

程序如果要展示其正確性，應(yīng)該使用足夠簡單的輸入輸出格式，這樣才能保證很容易地檢驗(yàn)有效輸入和正確輸出之間的關(guān)系是否正確。出于充分考慮透明性和顯見性的目的，還應(yīng)該提倡接口簡潔，以方便其它程序?qū)ζ溥M(jìn)行操作，尤其是測試監(jiān)視工具和調(diào)試腳本。關(guān)注微信公眾號【嵌入式系統(tǒng)】

2.8 ?健壯原則：健壯源于透明與簡潔

軟件的健壯性指軟件不僅能在正常情況下運(yùn)行良好，而且在超出設(shè)想的意外條件下也能夠運(yùn)行良好。

大多數(shù)軟件禁不起磕碰，毛病多，就是因?yàn)檫^于復(fù)雜，很難通盤考慮。如果不能正確理解一個(gè)程序的邏輯，就不能確信其是否正確，也就不能在出錯(cuò)的時(shí)候修復(fù)它。讓程序健壯的方法，就是讓程序的內(nèi)部邏輯更易于理解，要做到這一點(diǎn)主要有兩種方法：透明化和簡潔化。

就健壯性而言，設(shè)計(jì)時(shí)要考慮到能承受極端輸入，這一點(diǎn)也很重要。在有異常輸入的情況下，保證軟件健壯性的一個(gè)相當(dāng)重要的策略就是避免在代碼中出現(xiàn)特例，bug ?通常隱藏在處理特例的代碼以及處理不同特殊情況的交互操作部分的代碼中。

軟件的透明性就是指一眼就能夠看出來是怎么回事。如果“怎么回事”不算復(fù)雜，即不需要絞盡腦汁就能夠推斷出所有可能的情況，那么這個(gè)程序就是簡潔的。程序越簡潔，越透明，也就越健壯。

模塊化(代碼簡樸，接口簡潔)是組織程序以達(dá)到更簡潔目的的一個(gè)方法。

2.9 ?表示原則：把知識疊入數(shù)據(jù)以求邏輯質(zhì)樸而健壯

數(shù)據(jù)要比編程邏輯更容易駕馭，在設(shè)計(jì)中，應(yīng)該主動將代碼的復(fù)雜度轉(zhuǎn)移到數(shù)據(jù)之中去。

此種考量并非 Unix 的原創(chuàng)，但是許多 Unix 代碼都顯示受其影響。特別是C 語言對指針使用控制的功能，促進(jìn)了在內(nèi)核以上各個(gè)編碼層面上對動態(tài)修改引用結(jié)構(gòu)。在結(jié)構(gòu)中用非常簡單的指針操作就能夠完成的任務(wù)，在其它語言中，往往不得不用更復(fù)雜的過程才能完成。

進(jìn)行數(shù)據(jù)驅(qū)動編程時(shí)，需要把代碼和代碼作用的數(shù)據(jù)結(jié)構(gòu)劃分清楚，這樣，在改變程序的邏輯時(shí)，只要編輯數(shù)據(jù)結(jié)構(gòu)而不是代碼。數(shù)據(jù)驅(qū)動編程有時(shí)會跟面向?qū)ο蠡煜饋?，后者是另一種以數(shù)據(jù)組織為中心的風(fēng)格。它們之間至少有兩點(diǎn)不同。第一，在數(shù)據(jù)驅(qū)動編程中，數(shù)據(jù)不僅僅是某個(gè)對象的狀態(tài)，實(shí)際上還定義了程序的控制流；第二，面向?qū)ο笫紫瓤紤]的是封裝，而數(shù)據(jù)驅(qū)動編程看重的是編寫盡可能少的固定代碼。

2.10 ?通俗原則：接口設(shè)計(jì)避免標(biāo)新立異

也就是眾所周知的“最少驚奇原則”。最易用的程序就是用戶需要學(xué)習(xí)新東西最少的程序，就是最切合用戶已有知識的程序。因此，接口設(shè)計(jì)應(yīng)該避免毫無來由的標(biāo)新立異和自作聰明。

如果你編制一個(gè)計(jì)算器 程序， ?‘+’應(yīng)該永遠(yuǎn)表示加法。設(shè)計(jì)接口的時(shí)候，盡量按照用戶最可能熟悉的同樣功能接口和相似應(yīng)用程序來進(jìn)行建模。

關(guān)注目標(biāo)受眾，他們也許是最終用戶，也許是其他程序員，也許是系統(tǒng)管理員。對于這些不同的人群，最少驚奇的意義也不同。關(guān)注傳統(tǒng)慣例，這些慣例的存在有個(gè)極好的理由：緩和學(xué)習(xí)曲線。

最小立異原則的另一面是避免表象相似而實(shí)際卻略有不同。這會極端危險(xiǎn)， 因?yàn)楸硐笙嗨仆鶎?dǎo)致人們產(chǎn)生錯(cuò)誤的假定。所以最好讓不同事物有明顯區(qū)別，而不要看起來幾乎一模一樣。

2.11 ?緘默原則：如果程序沒什么好說的，就保持沉默

行為良好的程序應(yīng)該默默工作，決不嘮嘮叨叨。沉默是金，這個(gè)原則的起始是源于Unix 誕生時(shí)還沒有視頻顯示器，每一行多余的輸出都會嚴(yán)重消耗用戶的寶貴時(shí)間?，F(xiàn)在這種情況已不復(fù)存在， 但一切從簡的這個(gè)優(yōu)良傳統(tǒng)流傳至今。

簡潔是 Unix 程序的核心風(fēng)格。一旦程序的輸出成為另一個(gè)程序的輸 入，就很容易把需要的數(shù)據(jù)挑出來。站在人的角度上來說，重要信息不應(yīng)該混雜在冗長的程序內(nèi)部行為信息中。如果顯示的信息都是重要的，那就不用找了。設(shè)計(jì)良好的程序?qū)⒂脩舻淖⒁饬σ暈橛邢薜膶氋F資源，只有在必要時(shí)才要求使用，避免不必要的信息對用戶的打擾。

2.12 ?補(bǔ)救原則：出現(xiàn)異常時(shí)，馬上退出并給出足量錯(cuò)誤信息

軟件在發(fā)生錯(cuò)誤的時(shí)候也應(yīng)該與在正常操作的情況下一樣，有透明的邏輯。最理想的情況當(dāng)然是軟件能夠適應(yīng)和應(yīng)付非正常操作；而如果補(bǔ)救措施明明沒有成功，卻悄無聲息地埋下崩潰的隱患，直到很久以后才顯現(xiàn)出來，這就是最壞的一種情況。

因此，軟件要盡可能從容地應(yīng)付各種錯(cuò)誤輸入和自身的運(yùn)行錯(cuò)誤，如果做不到這一點(diǎn)，就讓程序盡可能以一種容易診斷錯(cuò)誤的方式終止。

“寬容地收，謹(jǐn)慎地發(fā)”。就算輸入的數(shù)據(jù)不規(guī)范，設(shè)計(jì)良好的程序也會盡量領(lǐng)會其中的意義，盡量與別的程序協(xié)作；然后，要么響亮地倒塌，要么為工作鏈下一環(huán)的程序輸出一個(gè)嚴(yán)謹(jǐn)干凈正確的數(shù)據(jù)。

設(shè)計(jì)時(shí)要考慮寬容性，不是用過分縱容的實(shí)現(xiàn)來補(bǔ)救標(biāo)準(zhǔn)的不足，否則一不留神你會死得很難看。

2.13 經(jīng)濟(jì)原則：寧花機(jī)器一分，不花程序員一秒

在 Unix.早期的小型機(jī)時(shí)代，這一條觀點(diǎn)還是相當(dāng)激進(jìn)的；隨著技術(shù)的發(fā)展，開發(fā)公司和大多數(shù)用戶都能夠得到廉價(jià)的機(jī)器，所以這一準(zhǔn)則的合理性就不用多說。

在保證質(zhì)量的前提下，盡量使用計(jì)算機(jī)資源完成任務(wù)，減輕程序員負(fù)擔(dān)，另一個(gè)可以顯著節(jié)約程序員時(shí)間的方法是，教會機(jī)器如何做更多低層次的編程工作。關(guān)注微信公眾號【嵌入式系統(tǒng)】

2.14 ?生成原則：避免手撕, 盡量編寫程序去生成程序

眾所周知，人類很不善于干辛苦的細(xì)節(jié)工作。程序中的任何手工操作都是滋生錯(cuò)誤和延誤的溫床，由程序生成代碼幾乎總是比手寫代碼廉價(jià)并且更值得信賴。

對于代碼生成器來說，需要手寫的重復(fù)而麻木的高級語言代碼，與機(jī)器碼一樣是可以批量生產(chǎn)的。當(dāng)代碼生成器能夠提升抽象度時(shí)，即當(dāng)生成器的說明性語句要比生成碼簡單時(shí)，使用代碼生成器會很合算，而生成代碼后就根本無需再費(fèi)力地去手工處理。在 Unix 中大量使用代碼生成器使易于出錯(cuò)的細(xì)節(jié)工作自動化。

2.15 ?優(yōu)化原則：雕琢前先得有原型，跑之前先學(xué)會走

原型設(shè)計(jì)最基本的原則，“90%的功能現(xiàn)在能實(shí)現(xiàn)，比100%的功能永遠(yuǎn)實(shí)現(xiàn)不了強(qiáng)”。做好原型設(shè)計(jì)可以避免為蠅頭小利而投入過多的時(shí)間。

“ 不應(yīng)考慮蠅頭小利的效率提升，過早優(yōu)化是萬惡之源”，不知道瓶頸所在就匆忙進(jìn)行優(yōu)化，這可能是唯一一個(gè)比亂加功能更損害設(shè)計(jì)的錯(cuò)誤。從畸形的代碼到雜亂無章的數(shù)據(jù)布局，犧牲透明性和簡潔性而片面追求速度，滋生無數(shù)bug, ? 耗費(fèi)以百萬計(jì)的人時(shí)，這點(diǎn)芝麻大的好處，遠(yuǎn)不能抵消后續(xù)排錯(cuò)所付出的代價(jià)。

過早的局部優(yōu)化實(shí)際上會妨礙全局優(yōu)化，從而降低整體性能。在整體設(shè)計(jì)中可以帶來更多效益的修改常常會受到一個(gè)過早局部優(yōu)化的干擾，導(dǎo)致出來的產(chǎn)品既性能低劣又代碼過于復(fù)雜。

在 Unix 世界里，有一個(gè)非常明確的悠久傳統(tǒng)：先制作原型，再精雕細(xì)琢。優(yōu)化之前先確保能用，先能走，再學(xué)跑。從另一種不同的文化將這一點(diǎn)有效地?cái)U(kuò)展為：先求運(yùn)行，再求正確，最后求快。

所有這些話的實(shí)質(zhì)其實(shí)是一個(gè)意思：先設(shè)計(jì)做個(gè)未優(yōu)化的、運(yùn)行緩慢、很耗內(nèi)存但是正確的實(shí)現(xiàn)，然后進(jìn)行系統(tǒng)地調(diào)整，尋找那些可以通過犧牲最小的局部簡潔性而獲得較大性能提升的地方。

2.16 多樣原則：決不相信所謂“不二法門”的斷言

即使最出色的軟件也常常會受限于設(shè)計(jì)者的想象力。沒有人能聰明到把所有東西都最優(yōu)化，也不可能預(yù)想到軟件所有可能的用途。

對于軟件設(shè)計(jì)和實(shí)現(xiàn)來說，Unix 傳統(tǒng)有一點(diǎn)很好，即從不相信任何所謂的“不二法門”。Unix 奉行的是廣泛采用多種語言、開放的可擴(kuò)展系統(tǒng)和用戶定制機(jī)制；吸收并借鑒各種優(yōu)秀的設(shè)計(jì)思想，不斷完善自己的設(shè)計(jì)方法和風(fēng)格。

2.17 擴(kuò)展原則：設(shè)計(jì)著眼未來，未來總比預(yù)想快

為數(shù)據(jù)格式和代碼留下擴(kuò)展的空間，否則，就會發(fā)現(xiàn)常常被原先的不明智選擇捆住了手腳，因?yàn)闊o法既要改變它們又要維持對原來的兼容性。

設(shè)計(jì)協(xié)議或文件格式時(shí)，應(yīng)使其具有充分的自描述性以便可擴(kuò)展。要么包含版本號，要么采用獨(dú)立、自描述的語句，按照可以隨時(shí)插入新的、換掉舊的，而不會破壞格式讀取代碼的方法組織格式。Unix 經(jīng)驗(yàn)表示：稍微增加一點(diǎn)讓數(shù)據(jù)部署具有自描述性的開銷，就可以在無需破壞整體的情況下進(jìn)行擴(kuò)展，小的付出也可得到成千倍的回報(bào)。

設(shè)計(jì)代碼時(shí)，要有很好的組織，讓將來的開發(fā)者增加新功能時(shí)無需拆毀或重建整個(gè)架構(gòu)。這個(gè)原則并不是說隨意增加根本用不上的功能，而是建議在編寫代碼時(shí)要考慮到將來的需要，使以后增加功能比較容易。程序接合部要靈活，在代碼中加入“如果擴(kuò)展…需要…”的注釋,有義務(wù)給之后使用和維護(hù)自己編寫的代碼的人做點(diǎn)好事，也許將來就是自己來維護(hù)代碼，設(shè)計(jì)為將來著眼，節(jié)省的有可能就是自己的精力。

3 應(yīng)用Unix哲學(xué)

這些富有哲理的原則決不是模糊籠統(tǒng)的泛泛之談。在Unix 世界中，這些原則都直接來自于實(shí)踐，并形成了具體的規(guī)定。

運(yùn)用Unix 哲學(xué)，就應(yīng)該不斷追求卓越。軟件設(shè)計(jì)是一門技藝，值得付出智慧、創(chuàng)造力和激情。否則就不會超越那些簡單、老套的設(shè)計(jì)和實(shí)現(xiàn)；就會在應(yīng)該思考的時(shí)候急急忙忙去編程，就會在該無情刪繁就簡的時(shí)候反而把問題復(fù)雜化，就會反過來抱怨代碼怎么那么臃腫、難以調(diào)試。

要良好地運(yùn)用 Unix 哲學(xué)，永遠(yuǎn)不要蠻干；要多用巧勁，省下力氣到需要的時(shí)候再用，好鋼用在刀刃上。善用工具，盡可能將一切都自動化。

4 態(tài)度

軟件設(shè)計(jì)和實(shí)現(xiàn)是一門充滿快樂的藝術(shù)， 一種高水平的游戲。為什么要從事軟件設(shè)計(jì)而不是別的呢?可能現(xiàn)在只是為了賺錢或打發(fā)時(shí)間，也可能曾經(jīng)也認(rèn)為軟件設(shè)計(jì)改變世界，值得付出激情。

以上是Unix哲學(xué)之編程原則的詳細(xì)內(nèi)容。更多信息請關(guān)注PHP中文網(wǎng)其他相關(guān)文章！