作為Linux的忠粉，《UNIX編程藝術(shù)》這本書自然不可放過。書中第一章哲學(xué)部分，從多個方面闡述了Unix哲學(xué)。對于Unix哲學(xué)的普適性，作者認為，
“在其他操作系統(tǒng)下，要做到良好實踐通常要相對困難一些，但是盡管如此，Unix文化中的有益經(jīng)驗仍然可以借鑒”
近來對移動應(yīng)用開發(fā)有所涉獵，故嘗試從Unix哲學(xué)角度談?wù)剬PP開發(fā)的一些認知。
1、模塊原則：使用簡潔的接口拼合簡單的部件
模塊化自始至終都是軟件設(shè)計要遵循的重要原則之一，移動開發(fā)自然也不例外。在日常開發(fā)時，嘗試把可能單獨剝離出來的模塊分離出來，形成自己的“輪子”倉庫，無論從開發(fā)效率的提高，還是對于降低無端的BUG出現(xiàn)概率，都是極好的。這些可能獨立出來的模塊有：
- 日志記錄
- 文件讀寫
- 本地參數(shù)讀寫（Android中為SharedPreferences）
- 配置文件讀寫（如xml、ini等）
- 數(shù)據(jù)加解密（AES、DES、MD5等）
- http協(xié)議類（POST/GET）
- 圖片操作
- 二維碼生成
- 其他等等
這些模塊，不管是自己沉淀下來的，還是借鑒他人的（阮一峰：如何選擇開源許可證？），關(guān)鍵在于可復(fù)用性。當(dāng)然你還可以開源出來，造福更多的猿兒們。
2、清晰原則：清晰勝于機巧
程序員重讀自己代碼的可能性非常之高，而自己的代碼被他人閱讀應(yīng)視為一種榮幸（畢竟沒有死在自己手里）。每天在指尖流淌出來的應(yīng)該是優(yōu)雅而清晰的代碼，日久天長方能匯成一股清溪；倘若濁且顏色不正，最終毀的是自己的時間，甚至得到他人畫的圈圈。
對于注釋，如若架構(gòu)設(shè)計清晰，文件及變量命名易懂，是可以不寫的。但也正如書中所言：
永遠不要去吃力地解讀一段晦澀的代碼三次。第一次也許僥幸成功，但如果發(fā)現(xiàn)必須重新解讀一遍——離第一次太久了，具體細節(jié)無從回想——那么你該注釋代碼了，這樣第三次就相對不會那么痛苦了。
3、組合原則：設(shè)計時考慮拼接組合
如果程序彼此之間不能有效通信，那么軟件就難免會陷入復(fù)雜度的泥淖。
的確如此。在Unix中，提倡用簡單、面向流、設(shè)備無關(guān)的文本來實現(xiàn)多個程序間的通訊。而在Android中，也有類似的機制，那就是URI。URI將大部分的Android資源都以字符串的形式表示出來，其他應(yīng)用通過簡單的接口調(diào)用即可與之通訊（調(diào)用）。
同樣的，你的應(yīng)用也可以自定義URI，并開放給第三方應(yīng)用。這樣的機制確實給應(yīng)用間的通信帶來了極大的便利。
4、分離原則：策略同機制分離，接口同引擎分離
調(diào)侃點說，分離原則實際上就是把活潑的和安靜的兩位同學(xué)分開。那些容易發(fā)生變化的，如書中所舉例的策略和接口，與相對穩(wěn)定的內(nèi)容（機制和引擎）分離。形式上可能會是兩個進程并行，或是上下隔離。
舉個例子，一個用于加解密文件的應(yīng)用，用戶可能會選擇不同的加密算法，同時會有不同類型的數(shù)據(jù)需要加密，照片、視頻或者僅僅是文字。對于加密算法就需要單獨設(shè)計成一個引擎，對外的接口可能如此簡單：
byte[] encrypt(int algorithmType, byte[] src);
而上層的GUI，會根據(jù)加密場景延展出豐富的內(nèi)容，比如照片批量加密、聊天實時加密、剪貼板加密等等。
如此一來，不管上層需求如何改變，底層的算法引擎始終不會變化。
（這種設(shè)計方式）大大降低了整體復(fù)雜度，bug有望減少，從而降低程序的壽命周期成本。
5、簡潔原則：設(shè)計要簡潔，復(fù)雜度能低則低
這似乎正是我之前設(shè)計的DATA+++的核心理念：用小而美的應(yīng)用組成工具集，為用戶提供可擴展的加密服務(wù)。
微信似乎正是這種理念的踐行者，雖然有人覺得越來越臃腫。微信勢必要做成一個“操作系統(tǒng)”，導(dǎo)致其涵蓋的面越來越廣。但就其應(yīng)用設(shè)計本身而言，已經(jīng)將簡潔原則發(fā)揮到了極致：
- 訂閱號全部塞進一個對話入口內(nèi)
- 插件式的設(shè)計：依次點擊 我/設(shè)置/通用/功能 才能看到隱藏的功能插件
- “發(fā)現(xiàn)”和“我”中條目少到默認不會出現(xiàn)滾屏
- 一個搜索入口可以搜索所有的內(nèi)容，而非在通訊錄、朋友圈、文章、公眾號等各自設(shè)置一個搜索入口，mac的spotlight也正是如此
6、吝嗇原則：除非確無它法，不要編寫龐大的程序
能拆就拆，不能拆就疊。這似乎是模塊原則和分離原則的最佳實踐。
7、透明性原則：設(shè)計要可見，以便審查和調(diào)試
軟件設(shè)計做到可見是不容易的，不過對于移動開發(fā)，固定的開發(fā)模式使軟件很容易做到設(shè)計透明，這得益于移動開發(fā)框架的良好設(shè)計。
調(diào)試占到了設(shè)計的很大比重，程序的輸出其實是有很大學(xué)問的。如果一個異常輸出隱藏在一堆“aaaaa”、“12345”和“@@@@@”中時，上下反復(fù)的滾動會把時間和耐心都消耗殆盡。如果把這部分單獨拎出來，會是個很有意思的話題。
8、健壯原則：健壯源于透明與簡潔
健壯，健壯，誰都想壯壯的。可是，誰生來就是壯士呢？軟件設(shè)計之初，就對整個架構(gòu)有全面系統(tǒng)的思考，在開發(fā)過程中時時考量設(shè)計的健壯性，在開發(fā)結(jié)束后重新審視軟件的各個層面。在所有的軟件設(shè)計中重復(fù)上述過程，會使你設(shè)計出的軟件不斷趨于健壯。
12、補救原則：出現(xiàn)異常時，馬上退出并給出足夠錯誤信息
現(xiàn)在有越來越多的SDK收集移動應(yīng)用的崩潰信息，并自動傳遞給開發(fā)者。我不建議這種方式來收集用戶信息，一來有悖于對用戶隱私的尊重，二來對于那些不具備聯(lián)網(wǎng)權(quán)限的應(yīng)用來說是很難實現(xiàn)的。一種好的方式是，提供崩潰信息收集引擎，實現(xiàn)信息提示接口，同時提供一鍵發(fā)送和復(fù)制接口，以便具備和不具備聯(lián)網(wǎng)權(quán)限的應(yīng)用選擇使用。當(dāng)然，這似乎與諸多SDK的運營策略有關(guān)，暫且不談。
15、優(yōu)化原則：雕琢前先要有原型，跑之前先學(xué)會走
產(chǎn)品界有個概念叫最小可行性產(chǎn)品(MVP)，是說在產(chǎn)品設(shè)計時，先做出僅包含產(chǎn)品設(shè)計者最想要的功能的產(chǎn)品，投放市場后看用戶反應(yīng)，再來決定接下來的設(shè)計方向。同樣的，軟件開發(fā)實踐中也有敏捷開發(fā)一說。兩者和這里的優(yōu)化原則有異曲同工之妙。
其他原則
9、表示原則：把知識疊入數(shù)據(jù)以求邏輯質(zhì)樸而健壯
10、通俗原則：接口設(shè)計避免標(biāo)新立異
11、緘默原則：如果一個程序沒什么好說的，就沉默
13、經(jīng)濟原則：寧花機器一分，不花程序員一秒
14、生成原則：避免手工hack，盡量編寫程序去生成程序
16、多樣原則：決不相信所謂“不二法門”的斷言
17、擴展原則：設(shè)計著眼未來，未來總比預(yù)想來得快
Unix哲學(xué)之一圖以蔽之
