隨著時間的流逝，人們開發出了一套設計與編寫軟體工具的原則。在本書用來解決問題的程式中，你將會看到這些原則的應用示例。好的軟體工具應該具備下列特點：
一次做好一件事
在很多方面，這都是最重要的原則。若程式只做一件事，那麼無論是設計、編寫、除錯、維護，以及生成檔案都會容易得多。舉例來說，對於用來查詢檔案中是否有符合樣式的grep程式，不應該指望用它來執行算術運算。
這個原則的結果，自然就是會不斷產生出更小、更專用於特定功能的程式，就像專業木匠的工具箱裡，永遠會有一堆專為特定用途所設計的工具。
處理文字行，不要處理二進位制資料
文字行是unix的通用格式。當你在編寫自己的工具程式時便會發現，內含文字行的資料檔案很好處理，你可以用任何唾手可得的文字編輯器來編輯它，也可以讓這些資料在網路與各種機器架構之間傳輸。使用文字檔案更有助於任何自定義工具與現存的unix程式之間的結合。
使用正規表示式
正規表示式（regular expression）是很強的文字處理機制。了解它的運作模式並加以使用，可適度簡化編寫命令指令碼（script）的工作。
此外，雖然正規表示式多年來在工具與unix版本上不斷在變化，但posix標準僅提供兩種正規表示式。你可以利用標準的庫程式進行模式匹配的工作。這樣就可以編寫出專用的工具程式，用於與grep一致的正規表示式（posix稱之為基本型正規表示式，basic regular expressions，bre），或是用於與egrep一致的正規表示式（posix稱之為擴充套件型正規表示式，extended regular expressions，ere）。
預設使用標準輸入輸出
在未明確指定檔名的情況下，程式缺省會從它的標準輸入讀取資料，將資料寫到它的標準輸出，至於錯誤資訊則會傳送到標準錯誤輸出（這部分將於第2章討論）。以這樣的方式來編寫程式，可以輕鬆地讓它們成為資料過濾器（filter），例如，組成部分的規模越大，越需要複雜的管道（pipeline）或指令碼來處理。
避免喋喋不休
軟體工具的執行過程不該像在"聊天"（chatty）。不要將"開始處理"（starting processing）、"即將完成"（almost done）或是"處理完成"（finished processing）這類資訊放進程式的標準輸出（至少這不該是預設狀態）。
當你有意將一些工具串成一條管道時，例如：
1. tool_1 datafile tool_2 tool_3 tool_4 resultfile
若每個工具都會產生"正處理中"（yes i『m working）這樣的資訊並送往管道，那麼別指望執行結果會像預期的一樣。此外，若每個工具都將自己的資訊傳送至標準錯誤輸出，那麼整個螢幕畫面就會布滿一堆無用的過程資訊。在工具程式的世界裡，沒有訊息就是好訊息。
這個原則其實還有另外乙個含義。一般來說，unix工具程式一向遵循"你叫它做什麼，你就會得到什麼"的設計哲學。它們不會問"你確定嗎？"（are you sure）這種問題，當使用者鍵入rm somefile，unix的設計人員會認為使用者知道自己在做什麼，然後毫無疑問地rm刪除掉要刪除的檔案（注5）。
輸出格式必須與可接受的輸入格式一致
雖然unix程式並非完全符合你的需求，但是現有的工具或許已經可以為你完成90%的工作。接下來，若有需要，你可以編寫乙個功能特定的小型程式來完成剩下的工作。與每次都從頭開始來解決各個問題相比，這已經讓你省去許多任務作了。
構建特定工具前，先想想
如前所述，若現存系統裡就是沒有需要的程式，可以花點時間構建滿足所需的工具。然而，動手編寫乙個能夠解決問題的程式前，請先停下來想幾分鐘。你所要做的事，是否有其他人也需要做？這個特殊的工作是否有可能是某個一般問題的乙個特例？如果是的話，請針對一般問題來編寫程式。當然，這麼做的時侯，無論是在程式的設計或編寫上，都應該遵循前面所提到的幾項原則。
摘自：《shell指令碼學習指南》
通過學習本書，你不僅能了解unix工具集，還能吸收到unix的中心思想與軟體工具設計的原則。
shell軟體工具設計的原則 轉
隨著時間的流逝，人們開發出了一套設計與編寫軟體工具的原則。在本書用來解決問題的程式中，你將會看到這些原則的應用示例。好的軟體工具應該具備下列特點 一次做好一件事 在很多方面，這都是最重要的原則。若程式只做一件事，那麼無論是設計 編寫 除錯 維護，以及生成檔案都會容易得多。舉例來說，對於用來查詢檔案中...
軟體設計的原則
了解設計模式的朋友們，想必都聽說過 六大設計原則 吧。其實最經典的 23 種設計模式中或多或少地都在使用這些設計原則，也就是說，設計模式是站在設計原則的基礎之上的。所以在學習設計模式之前，很有必要對這些設計原則先做一下了解。gof 四人幫 傳說中的四位大神們，他們聯手搞出了一套設計模式，堪稱 ood...
軟體設計原則 開閉原則
對擴充套件開放，對修改關閉。在程式需要進行拓展的時候，不能去修改原有的 實現乙個熱插拔的效果。簡言之，是為了使程式的擴充套件性好，易於維護和公升級。想要達到這樣的效果，我們需要使用介面和抽象類。因為抽象靈活性好，適應性廣，只要抽象的合理，可以基本保持軟體架構的穩定。而軟體中易變的細節可以從抽象派生來...