最近看完The Art Of UNIX Programming，自己对这书的评价是，这是本好书，但还不足够好。
UNIX核心原则
全书的精华为其第一章提及的UNIX各项哲学，后面的篇幅则是对其一项项进行更详细的阐述。作者总结的UNIX原则有，
- 模块原则，使用简洁的接口拼合简单的部件
- 清晰原则，清晰胜于机巧
- 组合原则，设计时考虑拼接组合
- 分离原则，策略同机制分离，接口同引擎分离
- 简洁原则，设计要简洁，复杂度能低则低
- 吝啬原则，除非确无它法，不要编写庞大的程序
- 透明性原则，设计要可见，以便审查和调试
- 健壮原则，健壮源于透明和简洁
- 表示原则，把知识叠入数据以求逻辑质朴而健壮
- 通俗原则，接口设计避免标新立异
- 缄默原则，如果一个程序没什么好说的，就保持沉默
- 补救原则，出现异常时，马上退出并给出足量错误信息
- 经济原则，宁花机器一分，不花程序一秒
- 生成原则，避免手工hack，尽量编写程序去生成程序
- 优化原则，雕琢前得有原型，跑之前先学会走
- 多样原则，决不相信所谓“不二法门”的断言
- 扩展原则，设计着眼未来，未来总比与预想快
这些原则的核心即为，KISS（Keep It Simple, Stupid）。
个人对这些原则的理解
上述这些原则都是UNIX多年历史以及各项成功失败项目之上总结出来的，大方向上都正确，但如何在现实开发中应用这些原则却不像罗列这些原则这么简单。很多人都能说上这么几条，但往往又难做到。为什么知道却做不到，这才是问题所在。更严重的则是明明做的事情不符合上述原则，但却依然认为是符合的，陷入有理无理不明的境地。
“多样原则”的描述其实是与其余略有矛盾的，UNIX原则也不过是种“不二法门”的断言，实际开发遇到的情况多种多样，“择其善者而从之，其不善者而改之”，才是在阅读学习这类偏“虚”的内容时应该持有的态度。
在过去几年的工作学习中，对部分罗列的原则也多少有些体会与实践，
- 模块原则、清晰原则、组合原则、简洁原则、吝啬原则、透明原则、健壮原则、通俗原则
这几条在个人看来说的基本都是一回事情。在项目开发中需要持有模块化思维，模块之间通过定义良好的接口进行通信。模块与模块可以方便的进行难过组合，以应对多变的复杂需求。
- 分离原则
机制与策略进行分离。在最近的开发中深有体会，游戏开发中，程序主要负责各种机制实现，具体策略则是策划通过数据表或编辑工具去进行控制。这个最大的好处是让程序从多变的策略中解放出来，专注于更本质的内容。
- 透明性原则
透明性的目的是为了维护与调试。调试工具、数据可视化都是实现透明性原则的利器。这也是很多现金移动应用通信数据格式选用JSON的原因。
- 生成原则
当项目开发中遇到形式相同，内容不同的代码结构时，就是可以考虑实现代码生成器的时候。越是复杂系统，越是能进行类似的工作。
- 补救原则
在开发期，这条原则是正确的。但当产品发布后，产品的容错性也很重要。
- 优化原则
优化代码之前必须先进行度量，如果没有找到瓶颈所在，再多的优化也都无用。
- 经济原则
这一条是相当认同的，不仅仅在代码实现层面。在开发流程上也是如此，给程序员提供优越的开发环境是能极大提升效率的，但有些老板并不是这么认为的..
在实际开发中，我们可以依靠这些原则来指引开发，但也要注意到现实中最大的问题并非对这些原则的理解或误解，更多来自如下两个方面，
- 开发时间不足
敏捷开发、精益开发等方法论被越来越多项目产品所采用。可惜这些方法论的出发点往往都是产品，而非技术。在多个开发周期中，产品得到了迭代改进，代码却容易在不断变更的需求中腐化。好的设计需要时间，当时间不允许时，完成任务是第一位的。在技术债务积攒到一定程度之后再想消减，成本就会变高，以至于无法再行修改。
- 产品生命周期有限
有多少产品能像UNIX生命周期那么漫长呢？在过去几年移动互联网的热潮中，多少应用发布，多少应用死亡。产品是否能够活下来不是它们是否符合上述原则，而是它们是否解决了实际问题获取到用户。这些产品在开发方式中往往是从一个原型系统开始的，原型系统代码设计上通常不够精细，在产品迭代过程中实际都是在这些不够精细的原型上不断改进的。如果产品能够生存到一定时候，那么它也许能引来重构，但更多时候就倒下了。
个人不赞同的一些内容
文本化、配置
书中提及的文本化，在表达能力上太弱，在复杂应用场景上并不适用。在配置上，UNIX的配置方式其实很落后，与其倡导的原则并不相符。配置文件的所在、格式等等，不同应用、不同系统大都又不统一。在实际使用中，称之为灾难都不过份。在这几个方面，自己赞同王垠的谈Linux，Windows 和 Mac一文。
工具
书中对IDE与编辑器之争也给出了自己的选择，只是自己又站在了反面。也许在10多年前，IDE并不像今天这么完善。但在2015年的当下来看，不论使用任何程序语言，我都会推荐使用者去选择最合适的IDE工具。程序员的关心的重点在于数据、算法、设计，以及选用合适的工具。在今天，IDE是一个比通过编辑器自建开发环境好的多的工具，这已经是完成时了。
不要重新发明轮子
在做产品的时候，使用立等可取的好轮子；在学习的时候，尝试多造轮子才是。现成的轮子并不一定好用，总是使用现成的轮子，只能成为一个蹩脚的装配工。
其实能否使用现成的轮子更多时候是和项目复杂度相关的，开源的轮子又有多少是符合项目需求？又或者现有的轮子在满足需求的同时又引入了不必要的复杂度。记得Beautiful Code中介绍Excel项目的信条，“找到依赖，消除依赖”。像Excel那样复杂的项目毕竟是极少数，但这个例子有助于对是否使用轮子的思考。
总结
这本书总结提出了很多有益的指导性原则，仅从这点来看，这就足以成其为好书。可惜书中对UNIX过于推崇，一些观点概念在现今看来有些陈旧。而书中对Windows的鄙视往往又缺少缘由，一些方面书中所反对的，反而是更为正确的，私货兜售的有点过多。