最近看完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的鄙视往往又缺少缘由,一些方面书中所反对的,反而是更为正确的,私货兜售的有点过多。