1 Unix哲學(xué)

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

(1) 每個(gè)程式應(yīng)專注於完成一項(xiàng)任務(wù)，遇到新任務(wù)時(shí)應(yīng)重新開始，避免在原始程式中新增功能而導(dǎo)致複雜度增加。 (2) 假設(shè)程式的輸出將成為另一個(gè)程式的輸入，即使下一個(gè)程式尚不清楚，也應(yīng)確保輸出中不包含無關(guān)資訊。 (3) 儘早將設(shè)計(jì)和編寫的軟體投入試用，對低品質(zhì)程式碼應(yīng)果斷放棄並重新編寫。 (4) 使用工具優(yōu)先於低效率的輔助手段來減輕程式設(shè)計(jì)任務(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í)務(wù)工具和傳統(tǒng)，導(dǎo)致程式設(shè)計(jì)師無法執(zhí)行這些原則。他們常常受制於糟糕的工具、設(shè)計(jì)不良、過度勞累和冗餘程式碼。

2.1 ?模組原則：使用簡潔的介面拼合簡單的零件

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

彙編語言、編譯語言、流程圖、流程化程式設(shè)計(jì)、結(jié)構(gòu)化程式設(shè)計(jì)、物件導(dǎo)向、以及軟體開發(fā)方法論，過度吹捧。但它們卻增加了程序的複雜度，超出人腦處理能力。

為了成功開發(fā)複雜軟體，降低整體複雜度並透過簡單模組的清晰介面組合是關(guān)鍵。這樣可以使問題局限在特定部分，從而更容易改善局部而不影響整體。

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

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

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

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

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

#如果程式彼此之間無法有效通信，那麼軟體就難免會陷入複雜度的泥淖。

在輸入輸出方面， Unix 傳統(tǒng)極力提倡採用簡單、文字化、面向流、裝置無關(guān)的格式。在經(jīng)典的 Unix 下，多數(shù)程式都盡可能採用簡單過濾器的形式，即將一個(gè)輸入的文字流處理為一個(gè)簡單的文字流輸出。撇開世俗眼光，Unix程式設(shè)計(jì)師偏愛這種做法並不是因?yàn)樗麄兂鹨晥D形使用者介面，而是因?yàn)槿绻淌讲粧裼煤唵蔚奈淖州斎胼敵隽?，它們就極難銜接。

Unix 中文字流之於工具，就如同在物件導(dǎo)向環(huán)境中的訊息之於物件。文字流介面的簡潔性加強(qiáng)了工具的封裝性。而許多精緻的進(jìn)程間通訊方法，例如遠(yuǎn)端過程調(diào)用，都存在著各程式牽扯過多的傾向。

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

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

當(dāng)程式無法自然地使用序列化、協(xié)定形式的介面時(shí)，正確的 Unix 設(shè)計(jì)至少是，把盡可能多的程式設(shè)計(jì)元素組織為一套定義良好的 API 。這樣至少可以透過連結(jié)呼叫應(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ī)制寫出較好的測驗(yàn)。

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

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

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

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

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

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

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

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

2.7 ?透明原則：設(shè)計(jì)要可見，以便檢視與除錯(cuò)

因?yàn)檎{(diào)試通常會佔(zhàn)用四分之三甚至更多的開發(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è)專案全過程帶來好處。調(diào)試選項(xiàng)的設(shè)定盡量不要在事後，而應(yīng)該在設(shè)計(jì)之初便考慮進(jìn)去，程序不但應(yīng)該能展示其正確性，也應(yīng)該能把原開發(fā)者解決問題的思維模型告訴後來者。

程式如果要展示其正確性，應(yīng)該使用足夠簡單的輸入輸出格式，這樣才能保證很容易地檢驗(yàn)有效輸入和正確輸出之間的關(guān)係是否正確。出於充分考慮透明性和顯見性的目的，也應(yīng)該提倡介面簡潔，以方便其它程式對其進(jìn)行操作，尤其是測試監(jiān)視工具和偵錯(cuò)腳本。關(guān)注微信公眾號【嵌入式系統(tǒng)】

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

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

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

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

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

模組化(程式碼簡樸，介面簡潔)是組織程式以達(dá)到更簡潔目的的方法。

2.9 ?表示原則：將知識疊成資料求邏輯質(zhì)樸而健壯

#資料要比程式邏輯更容易駕馭，在設(shè)計(jì)中，應(yīng)該主動將程式碼的複雜度轉(zhuǎn)移到資料之中去。

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

進(jìn)行資料驅(qū)動程式設(shè)計(jì)時(shí)，需要把程式碼和程式碼作用的資料結(jié)構(gòu)劃分清楚，這樣，改變程式的邏輯時(shí)，只要編輯資料結(jié)構(gòu)而不是程式碼。資料驅(qū)動程式設(shè)計(jì)有時(shí)會跟著物件導(dǎo)向混淆起來，後者是另一種以資料組織為中心的風(fēng)格。它們之間至少有兩點(diǎn)不同。第一，在資料驅(qū)動程式設(shè)計(jì)中，資料不只是某個(gè)物件的狀態(tài)，實(shí)際上還定義了程式的控制流程；第二，物件導(dǎo)向首先考慮的是封裝，而資料驅(qū)動程式設(shè)計(jì)看重的是編寫盡可能少的固定代碼。

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)行建模。

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

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

2.11 ?緘默原則：如果程式?jīng)]什麼好說的，就保持沉默

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

簡潔是 Unix 程式的核心風(fēng)格。一旦程式的輸出成為另一個(gè)程式的輸 入，就很容易把需要的資料挑出來。站在人的角度上來說，重要資訊不應(yīng)該混雜在冗長的程序內(nèi)部行為資訊中。如果顯示的資訊都是重要的，那就不用找了。設(shè)計(jì)良好的程式將使用者的注意力視為有限的寶貴資源，只有在必要時(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í)作來說，Unix 傳統(tǒng)有一點(diǎn)很好，就是從不相信任何所謂的「不二法門」。 Unix 奉行的是廣泛採用多種語言、開放的可擴(kuò)展系統(tǒng)和用戶定制機(jī)制；吸收並借鑒各種優(yōu)秀的設(shè)計(jì)思想，不斷完善自己的設(shè)計(jì)方法和風(fēng)格。

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

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

設(shè)計(jì)協(xié)定或文件格式時(shí)，應(yīng)使其具有充分的自描述性以便可擴(kuò)展。要麼包含版本號，要麼採用獨(dú)立、自描述的語句，按照可以隨時(shí)插入新的、換掉舊的，而不會破壞格式讀取程式碼的方法組織格式。 Unix 經(jīng)驗(yàn)表示：稍微增加一點(diǎn)讓資料部署具有自描述性的開銷，就可以在無需破壞整體的情況下進(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í)候反而把問題複雜化，就會反過來抱怨代碼怎麼那麼臃腫、難以調(diào)試。

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

4 態(tài)度

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

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