作为Linux的忠粉，《UNIX编程艺术》这本书自然不可放过。书中第一章哲学部分，从多个方面阐述了Unix哲学。对于Unix哲学的普适性，作者认为，
“在其他操作系统下，要做到良好实践通常要相对困难一些，但是尽管如此，Unix文化中的有益经验仍然可以借鉴”
近来对移动应用开发有所涉猎，故尝试从Unix哲学角度谈谈对APP开发的一些认知。
1、模块原则：使用简洁的接口拼合简单的部件
模块化自始至终都是软件设计要遵循的重要原则之一，移动开发自然也不例外。在日常开发时，尝试把可能单独剥离出来的模块分离出来，形成自己的“轮子”仓库，无论从开发效率的提高，还是对于降低无端的BUG出现概率，都是极好的。这些可能独立出来的模块有：
- 日志记录
- 文件读写
- 本地参数读写（Android中为SharedPreferences）
- 配置文件读写（如xml、ini等）
- 数据加解密（AES、DES、MD5等）
- http协议类（POST/GET）
- 图片操作
- 二维码生成
- 其他等等
这些模块，不管是自己沉淀下来的，还是借鉴他人的（阮一峰：如何选择开源许可证？），关键在于可复用性。当然你还可以开源出来，造福更多的猿儿们。
2、清晰原则：清晰胜于机巧
程序员重读自己代码的可能性非常之高，而自己的代码被他人阅读应视为一种荣幸（毕竟没有死在自己手里）。每天在指尖流淌出来的应该是优雅而清晰的代码，日久天长方能汇成一股清溪；倘若浊且颜色不正，最终毁的是自己的时间，甚至得到他人画的圈圈。
对于注释，如若架构设计清晰，文件及变量命名易懂，是可以不写的。但也正如书中所言：
永远不要去吃力地解读一段晦涩的代码三次。第一次也许侥幸成功，但如果发现必须重新解读一遍——离第一次太久了，具体细节无从回想——那么你该注释代码了，这样第三次就相对不会那么痛苦了。
3、组合原则：设计时考虑拼接组合
如果程序彼此之间不能有效通信，那么软件就难免会陷入复杂度的泥淖。
的确如此。在Unix中，提倡用简单、面向流、设备无关的文本来实现多个程序间的通讯。而在Android中，也有类似的机制，那就是URI。URI将大部分的Android资源都以字符串的形式表示出来，其他应用通过简单的接口调用即可与之通讯（调用）。
同样的，你的应用也可以自定义URI，并开放给第三方应用。这样的机制确实给应用间的通信带来了极大的便利。
4、分离原则：策略同机制分离，接口同引擎分离
调侃点说，分离原则实际上就是把活泼的和安静的两位同学分开。那些容易发生变化的，如书中所举例的策略和接口，与相对稳定的内容（机制和引擎）分离。形式上可能会是两个进程并行，或是上下隔离。
举个例子，一个用于加解密文件的应用，用户可能会选择不同的加密算法，同时会有不同类型的数据需要加密，照片、视频或者仅仅是文字。对于加密算法就需要单独设计成一个引擎，对外的接口可能如此简单：
byte[] encrypt(int algorithmType, byte[] src);
而上层的GUI，会根据加密场景延展出丰富的内容，比如照片批量加密、聊天实时加密、剪贴板加密等等。
如此一来，不管上层需求如何改变，底层的算法引擎始终不会变化。
（这种设计方式）大大降低了整体复杂度，bug有望减少，从而降低程序的寿命周期成本。
5、简洁原则：设计要简洁，复杂度能低则低
这似乎正是我之前设计的DATA+++的核心理念：用小而美的应用组成工具集，为用户提供可扩展的加密服务。
微信似乎正是这种理念的践行者，虽然有人觉得越来越臃肿。微信势必要做成一个“操作系统”，导致其涵盖的面越来越广。但就其应用设计本身而言，已经将简洁原则发挥到了极致：
- 订阅号全部塞进一个对话入口内
- 插件式的设计：依次点击 我/设置/通用/功能 才能看到隐藏的功能插件
- “发现”和“我”中条目少到默认不会出现滚屏
- 一个搜索入口可以搜索所有的内容，而非在通讯录、朋友圈、文章、公众号等各自设置一个搜索入口，mac的spotlight也正是如此
6、吝啬原则：除非确无它法，不要编写庞大的程序
能拆就拆，不能拆就叠。这似乎是模块原则和分离原则的最佳实践。
7、透明性原则：设计要可见，以便审查和调试
软件设计做到可见是不容易的，不过对于移动开发，固定的开发模式使软件很容易做到设计透明，这得益于移动开发框架的良好设计。
调试占到了设计的很大比重，程序的输出其实是有很大学问的。如果一个异常输出隐藏在一堆“aaaaa”、“12345”和“@@@@@”中时，上下反复的滚动会把时间和耐心都消耗殆尽。如果把这部分单独拎出来，会是个很有意思的话题。
8、健壮原则：健壮源于透明与简洁
健壮，健壮，谁都想壮壮的。可是，谁生来就是壮士呢？软件设计之初，就对整个架构有全面系统的思考，在开发过程中时时考量设计的健壮性，在开发结束后重新审视软件的各个层面。在所有的软件设计中重复上述过程，会使你设计出的软件不断趋于健壮。
12、补救原则：出现异常时，马上退出并给出足够错误信息
现在有越来越多的SDK收集移动应用的崩溃信息，并自动传递给开发者。我不建议这种方式来收集用户信息，一来有悖于对用户隐私的尊重，二来对于那些不具备联网权限的应用来说是很难实现的。一种好的方式是，提供崩溃信息收集引擎，实现信息提示接口，同时提供一键发送和复制接口，以便具备和不具备联网权限的应用选择使用。当然，这似乎与诸多SDK的运营策略有关，暂且不谈。
15、优化原则：雕琢前先要有原型，跑之前先学会走
产品界有个概念叫最小可行性产品(MVP)，是说在产品设计时，先做出仅包含产品设计者最想要的功能的产品，投放市场后看用户反应，再来决定接下来的设计方向。同样的，软件开发实践中也有敏捷开发一说。两者和这里的优化原则有异曲同工之妙。
其他原则
9、表示原则：把知识叠入数据以求逻辑质朴而健壮
10、通俗原则：接口设计避免标新立异
11、缄默原则：如果一个程序没什么好说的，就沉默
13、经济原则：宁花机器一分，不花程序员一秒
14、生成原则：避免手工hack，尽量编写程序去生成程序
16、多样原则：决不相信所谓“不二法门”的断言
17、扩展原则：设计着眼未来，未来总比预想来得快
Unix哲学之一图以蔽之
