Unix编程哲学和软件设计方法
?
??????Unix編程哲學：
?1，模塊原則：使用簡潔的接口拼合簡單的部件。
2，清晰原則：清晰勝于機巧。
3，組合原則：設計時考慮拼接組合。
4，分離原則：策略同機制分離，接口同實現引擎分離。
5，簡潔原則：設計要簡潔，復雜度能低則低。
6，吝嗇原則：除非確無它法，不要編寫龐大的程序。
7，透明性原則：設計要可見，以便審查和調試。
8，健壯原則：健壯源于透明與簡潔。
9，表示原則：把知識疊入數據以求邏輯質樸而健壯。
10，通俗原則：接口設計避免標新立異。
11，緘默原則：如果一個程序沒什么好說的，就沉默。
12，補救原則：出現異常時，馬上退出并給出足夠的錯誤信息。
13，經濟原則：寧花機器一分，不花程序員一秒。
14，生成原則：避免手工hack，盡量編寫程序去生成程序。
15，優化原則：雕琢前先要有原型，跑之前先學會走。
16，多樣原則：絕不相信所謂“不二法門”的斷言。
17，擴展原則：設計著眼未來，未來總比預想來得快。
?
另外：
一個程序只做一件事情，并做好。
程序要能協作。
程序要能處理文本流，因為這是最通用的接口。
?? ? ?來自《Unix編程藝術》一書。這些原則在很多軟件工程，設計模式，敏捷開發書籍中都有提到。 ? ?
?
?? ? ?有時因為設計問題受到同事的挑戰。解釋起來又挺麻煩的，不是三言兩語能說明白的。 以后就把這些原則背出來，再遇到挑戰就說是根據**原則設計的，如果不清楚看《Unix編程藝術》這本書或者敏捷開發的書，省得解釋了。
?
?? ? ?一些人喜歡使用二進制協議，覺得文本協議太浪費資源。其實文本協議浪費不多（xml格式除外），能處理的程序多，糾錯能力強。最主要的是便于人查看和編輯。
?
?? ? 一些人為了提高機器執行效率，到處要求優化。其實很多是廢的。甚至因為引入了bug起發作用。至少使代碼更難理解。應該優化經測試真正的瓶頸，而不是想當然。
?
?? ? 一些人喜歡用一個巨大的程序完成任務，而不是多個小程序。因為覺得線程間交互簡單；而進程間交互復雜，而且要使用進程間通訊，效率低。多個小程序的好處是，提供了機制而不是策略。便于重用，具有更大的靈活性，能夠滿足多種需要。
?
?? ? ?而且能夠積累不少可重用的工具，提高日后的開發效率。 有些公司辦了很多年，一點積累都沒有，每次來項目都要從頭開始寫。
?? ??
?? ? 如果不愿意或者不能分成多個小程序，至少也應該提供service和GUI層的邏輯上的隔離。這樣service層等模塊可以打包成動態鏈接庫，jar包等，便于重用。 ?
?
?? ? 這樣，至少如果有一天你的Web程序要提供openAPI（現在很流行）時，不需要大動干戈，重寫很多代碼。
?
?? ? ?另外，Linux等開源代碼，之所以質量優秀，就是充分的源代碼公開和源代碼review。 建議公司在項目內形成開誠布公的源代碼review風氣，改善代碼質量。當然這個在一些公司政治嚴重的團隊很難實現。在程序員間容易產生矛盾。
?? ??15，優化原則：雕琢前先要有原型，跑之前先學會走。
<!-- @page { margin: 2cm } P { margin-bottom: 0.21cm } A:link { so-language: zxx } -->
?? ? 一些工程師，喜歡瀑布式的開發方式。一上來設計文檔寫個幾個月，未來描繪得非常美好。代碼一行未動。
?? ? ?項目最后是一延再延，最后發現架構設計有根本性的問題，BUG修復很難，項目只能取消，或者徹底重寫。
?
?? ? ?沒有深入到問題內部，和它近距離接觸，是很難在腦子中憑空想清楚整個技術方案的。
?? ? ?我喜歡先設計原型，搭起架子，找到有風險的技術問題，先予以解決。和問題近身肉搏，然后調整、重構，得到可工作的原型，同時也得到了設計方案。再一步步實施。
?? ? ?
?? ? ?我很奇怪，一些工程師對問題還沒想透，技術風險還沒排除，就敢直接花大量的時間寫詳盡的設計方案!
?? ? ?如果是概要性質的，還可以理解，畢竟項目總體的設計不會有太大的改變。
?
?
?
?? ?
???
?
?
?
?
?
?
?
?
?
總結
以上是生活随笔為你收集整理的Unix编程哲学和软件设计方法的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 安装SQL SERVER 2000时提示
- 下一篇： qhd屏幕（QHD）