作為Linux的忠粉枚粘，《UNIX編程藝術》這本書自然不可放過茄袖。書中第一章哲學部分，從多個方面闡述了Unix哲學。對于Unix哲學的普適性丑瞧，作者認為，
“在其他操作系統(tǒng)下叛薯，要做到良好實踐通常要相對困難一些矮慕，但是盡管如此，Unix文化中的有益經(jīng)驗仍然可以借鑒”
近來對移動應用開發(fā)有所涉獵，故嘗試從Unix哲學角度談談對APP開發(fā)的一些認知宵蛀。
1昆著、模塊原則：使用簡潔的接口拼合簡單的部件
模塊化自始至終都是軟件設計要遵循的重要原則之一，移動開發(fā)自然也不例外术陶。在日常開發(fā)時凑懂，嘗試把可能單獨剝離出來的模塊分離出來，形成自己的“輪子”倉庫梧宫，無論從開發(fā)效率的提高接谨，還是對于降低無端的BUG出現(xiàn)概率，都是極好的塘匣。這些可能獨立出來的模塊有：
- 日志記錄
- 文件讀寫
- 本地參數(shù)讀寫（Android中為SharedPreferences）
- 配置文件讀寫（如xml脓豪、ini等）
- 數(shù)據(jù)加解密（AES、DES忌卤、MD5等）
- http協(xié)議類（POST/GET）
- 圖片操作
- 二維碼生成
- 其他等等
這些模塊扫夜，不管是自己沉淀下來的，還是借鑒他人的（阮一峰：如何選擇開源許可證驰徊？）笤闯，關鍵在于可復用性。當然你還可以開源出來辣垒，造福更多的猿兒們望侈。
2、清晰原則：清晰勝于機巧
程序員重讀自己代碼的可能性非常之高勋桶，而自己的代碼被他人閱讀應視為一種榮幸（畢竟沒有死在自己手里）脱衙。每天在指尖流淌出來的應該是優(yōu)雅而清晰的代碼，日久天長方能匯成一股清溪例驹；倘若濁且顏色不正捐韩，最終毀的是自己的時間，甚至得到他人畫的圈圈鹃锈。
對于注釋荤胁，如若架構(gòu)設計清晰，文件及變量命名易懂屎债，是可以不寫的仅政。但也正如書中所言：
永遠不要去吃力地解讀一段晦澀的代碼三次。第一次也許僥幸成功盆驹，但如果發(fā)現(xiàn)必須重新解讀一遍——離第一次太久了圆丹，具體細節(jié)無從回想——那么你該注釋代碼了，這樣第三次就相對不會那么痛苦了躯喇。
3辫封、組合原則：設計時考慮拼接組合
如果程序彼此之間不能有效通信硝枉，那么軟件就難免會陷入復雜度的泥淖。
的確如此倦微。在Unix中妻味，提倡用簡單、面向流欣福、設備無關的文本來實現(xiàn)多個程序間的通訊责球。而在Android中，也有類似的機制拓劝，那就是URI棕诵。URI將大部分的Android資源都以字符串的形式表示出來，其他應用通過簡單的接口調(diào)用即可與之通訊（調(diào)用）凿将。
同樣的校套，你的應用也可以自定義URI，并開放給第三方應用牧抵。這樣的機制確實給應用間的通信帶來了極大的便利笛匙。
4、分離原則：策略同機制分離犀变，接口同引擎分離
調(diào)侃點說妹孙，分離原則實際上就是把活潑的和安靜的兩位同學分開。那些容易發(fā)生變化的获枝，如書中所舉例的策略和接口蠢正，與相對穩(wěn)定的內(nèi)容（機制和引擎）分離。形式上可能會是兩個進程并行省店，或是上下隔離嚣崭。
舉個例子，一個用于加解密文件的應用懦傍，用戶可能會選擇不同的加密算法雹舀，同時會有不同類型的數(shù)據(jù)需要加密，照片粗俱、視頻或者僅僅是文字说榆。對于加密算法就需要單獨設計成一個引擎，對外的接口可能如此簡單：
byte[] encrypt(int algorithmType, byte[] src);
而上層的GUI寸认，會根據(jù)加密場景延展出豐富的內(nèi)容签财，比如照片批量加密、聊天實時加密偏塞、剪貼板加密等等唱蒸。
如此一來，不管上層需求如何改變烛愧，底層的算法引擎始終不會變化油宜。
（這種設計方式）大大降低了整體復雜度，bug有望減少怜姿，從而降低程序的壽命周期成本慎冤。
5、簡潔原則：設計要簡潔沧卢，復雜度能低則低
這似乎正是我之前設計的DATA+++的核心理念：用小而美的應用組成工具集蚁堤，為用戶提供可擴展的加密服務。
微信似乎正是這種理念的踐行者但狭，雖然有人覺得越來越臃腫披诗。微信勢必要做成一個“操作系統(tǒng)”，導致其涵蓋的面越來越廣立磁。但就其應用設計本身而言呈队，已經(jīng)將簡潔原則發(fā)揮到了極致：
- 訂閱號全部塞進一個對話入口內(nèi)
- 插件式的設計：依次點擊 我/設置/通用/功能 才能看到隱藏的功能插件
- “發(fā)現(xiàn)”和“我”中條目少到默認不會出現(xiàn)滾屏
- 一個搜索入口可以搜索所有的內(nèi)容，而非在通訊錄唱歧、朋友圈宪摧、文章、公眾號等各自設置一個搜索入口颅崩，mac的spotlight也正是如此
6几于、吝嗇原則：除非確無它法，不要編寫龐大的程序
能拆就拆沿后，不能拆就疊沿彭。這似乎是模塊原則和分離原則的最佳實踐。
7尖滚、透明性原則：設計要可見喉刘，以便審查和調(diào)試
軟件設計做到可見是不容易的，不過對于移動開發(fā)漆弄，固定的開發(fā)模式使軟件很容易做到設計透明饱搏，這得益于移動開發(fā)框架的良好設計。
調(diào)試占到了設計的很大比重置逻，程序的輸出其實是有很大學問的推沸。如果一個異常輸出隱藏在一堆“aaaaa”、“12345”和“@@@@@”中時券坞，上下反復的滾動會把時間和耐心都消耗殆盡鬓催。如果把這部分單獨拎出來，會是個很有意思的話題恨锚。
8宇驾、健壯原則：健壯源于透明與簡潔
健壯，健壯猴伶，誰都想壯壯的课舍∷鳎可是，誰生來就是壯士呢筝尾？軟件設計之初捡需，就對整個架構(gòu)有全面系統(tǒng)的思考，在開發(fā)過程中時時考量設計的健壯性筹淫，在開發(fā)結(jié)束后重新審視軟件的各個層面站辉。在所有的軟件設計中重復上述過程，會使你設計出的軟件不斷趨于健壯损姜。
12饰剥、補救原則：出現(xiàn)異常時，馬上退出并給出足夠錯誤信息
現(xiàn)在有越來越多的SDK收集移動應用的崩潰信息摧阅，并自動傳遞給開發(fā)者汰蓉。我不建議這種方式來收集用戶信息，一來有悖于對用戶隱私的尊重棒卷，二來對于那些不具備聯(lián)網(wǎng)權限的應用來說是很難實現(xiàn)的古沥。一種好的方式是，提供崩潰信息收集引擎娇跟，實現(xiàn)信息提示接口岩齿，同時提供一鍵發(fā)送和復制接口，以便具備和不具備聯(lián)網(wǎng)權限的應用選擇使用苞俘。當然盹沈，這似乎與諸多SDK的運營策略有關，暫且不談吃谣。
15乞封、優(yōu)化原則：雕琢前先要有原型，跑之前先學會走
產(chǎn)品界有個概念叫最小可行性產(chǎn)品(MVP)岗憋，是說在產(chǎn)品設計時肃晚，先做出僅包含產(chǎn)品設計者最想要的功能的產(chǎn)品，投放市場后看用戶反應仔戈，再來決定接下來的設計方向关串。同樣的，軟件開發(fā)實踐中也有敏捷開發(fā)一說监徘。兩者和這里的優(yōu)化原則有異曲同工之妙晋修。
其他原則
9、表示原則：把知識疊入數(shù)據(jù)以求邏輯質(zhì)樸而健壯
10凰盔、通俗原則：接口設計避免標新立異
11墓卦、緘默原則：如果一個程序沒什么好說的，就沉默
13户敬、經(jīng)濟原則：寧花機器一分落剪，不花程序員一秒
14睁本、生成原則：避免手工hack，盡量編寫程序去生成程序
16忠怖、多樣原則：決不相信所謂“不二法門”的斷言
17呢堰、擴展原則：設計著眼未來，未來總比預想來得快
Unix哲學之一圖以蔽之
