《UNIX编程艺术》读后感10篇
《UNIX编程艺术》是一本由Eric S. Raymond著作，电子工业出版社出版的平装图书，本书定价：59.00元，页数：525，文章吧小编精心整理的一些读者的读后感，希望对大家能有帮助。
《UNIX编程艺术》读后感(一)：简单就是美
最近这段时间比较忙，利用业余时间看完了这本书。虽然书中讲到的很多例子都是上古文物，我没有用过，不过原理都是相通的，对我的启发很大。比如无所不在的KISS原则，实践中慢慢体会到的SPOT原则，无不产生共鸣。下面是这些原则的一些笔记和个人理解。
1. 模块原则
为什么要模块化？计算机编程的本质就是控制复杂度。而模块化可以降低整体复杂度，即使出现问题也只是局限于局部，方便维护。
紧凑性和正交性是模块化的两个重要特性。对于现代项目来说，跨度一般都很大，完全达到紧凑性是非常困难的，只能尽量采用。
正交性是指程序中每个动作有且只有一个方法，正交性的程序不但会减少程序中的副作用，而且从另一个方面达到紧凑性。SPOT（single point of truth）是指任何知识点在系统内应当只有一个唯一明确权威的表述。不要重复自身。重复会导致前后矛盾。重构的原则性目标就是提高正交性。
2. 清晰原则
所谓大巧不工，重剑无锋。程序的清晰性比奇技淫巧更重要。选择算法和实现时应考虑可扩展性和可维护性，复杂的bug容易产生bug，难以阅读维护。同时在项目中养成注释代码的良好习惯。
3. 分离原则：
策略同机制分离，接口同引擎分离。策略是易变的，灵活的；机制是稳定的。策略与机制混在一起会有两个负面作用：1.使策略死板，难以适应用户需求变化。2.任何策略的改变都极有可能动摇机制。而分离开来可以在探索新策略时不去改变已有机制。
实现策略与机制分离的常用方法就是用脚本语言驱动的c语言实现机制，打包成库。整个应用程序的控制流程则有脚本语言来控制，这就是策略。比如我们公司的产品就是策略机制分离的典型应用。底层引擎由c和c++实现，lua做接口，上层流程用lua脚本实现，用户可以在一定范围内自己设计流程。
不过上层策略和下层机制分离并没有那么容易，不管是从上到下还是从下到上的设计方向都有弊端。当上层的策略与下层的机制产生冲突时就可能需要中间胶合层来匹配。胶合层应该尽可能薄，薄胶合层是分离原则的升华。C语言是薄胶合层的典型范例，而面向对象语言则属于厚胶合层，特别是继承层数太多时，会严重增加复杂度。
4. 简洁原则
出现越复杂，产生bug的概率就越高，排错也越困难。以简洁为美，拒绝花哨臃肿的程序。Keep it simple, stupid!
5. 透明性原则
透明性是针对程序的行为而言的，如果程序行为在一定程度上可以预测，那么程序就是透明的。可显性指的是程序的功能很清楚，容易明白做了什么，怎么做的。比如Linux内核具有透明性，我们知道具有什么行为，但是不具有可显性，因为源码太复杂难懂了。
6. 健壮原则
健壮性指程序不仅在正常情况下运行良好，而且在超出设计者设想的意外条件下也能运行良好。尽量让程序的内部逻辑更易于理解，使其透明化和简洁化，最好避免程序出现过多特例和边界条件。
7. 表示原则
数据比代码逻辑更清楚明了，设计时主动将代码的复杂度转移到数据中去，选择偏于维护和操作的数据。数据驱动编程是unix编程的重要组成部分。
8. 通俗原则
接口设计避免标新立异。最易用的程序就是用户需要学习东西最少的程序，一定避免表面相似但内部却不同的情况，比如重载函数内部行为变化太大。
9. 缄默原则
设计良好的程序将用户的注意力视为有限的宝贵资源。信息内容应该符合最大惊奇原则，只对确实是异常的情况加以说明。如果调试需要，可以添加多级开关，发布时启用最高级别开关。
10. 补救原则
出现异常时，马上退出并给出足量错误信息。软件在发生错误时如果没有及时发现，将会埋下严重的隐患。软件应该能够从容应付各种错误，如果做不到，就应该明确终止。有些时候程序不应该去容错，比如输入为空时最好直接退出并保留恢复机制和错误信息，处理输入后再重启，而不是检查输入是否为空，当数据出现问题却恰好不为空时将会产生非常隐晦的错误。
11. 优化原则
过早优化是万恶之源。先制作原型，再精雕细琢，优化之前先确保能用，不要为蝇头小利投入过量时间。
同步于
《UNIX编程艺术》读后感(二)：一本简单的书
500来页的书以五个晚上的时间飙完，本身就说明了其简单。
是最近以来看得最爽利的两本软件书之一（另一本是云风的《我的编程感悟》），全书是对“主流”软件工程的反动，但每每契合吾意，往往有醍醐灌顶之感。
ESR属于优点和缺点都很明显的作者，还好这次有心理准备，才没有被其喋喋不休的口水吓跑。但就个人感受而言，似乎还是前半本有更多的灵光闪现。
基本可以说，读完此书，可以对UNIX文化有一个整体上的认识。对软件设计也会有一些值得回味的心得。
打算打4星半，如果可以的话。
向译者学习，我也来一个东施效颦式的结尾：
KISS。
《UNIX编程艺术》读后感(三)：无所不在的K.I.S.S
这本书我已经买了三个星期，一直在看。以前看它的英文版，仅仅走马观花般看了一遍。现在这个中文版，目前为止我已经看了三遍，而每次都会有新的体会。我得到的关于《Unix编程艺术》最深的感想就是：Unix中无所不在的K.I.S.S(Keep It Simple, Stupid)原则。
显然，Unix的设计中贯彻了这个原则，而且连Unix下的软件也深刻地受到这个原则的影响。比如ed,head这些
小程序。《注重实效的程序员》中也提到过著名的Unix哲学:“提供锋利的小工具，其中每一样都意在吧每一件事情做好。Unix因围绕这样的哲学进行设计而著称。”
另外，Eric还另外阐述了Linux开发原则(这个原则他在《大教堂与市集》一文中说过)，”如果有足够的眼睛关注，那么所有的bug将无处藏身。”
还有，该书附录D中的《无根的根:无名师的Unix心传》很有意思啊，该附录模仿中国的禅宗故事，写下了关于Unix的传说。这些故事与Jargon File中提到的相映成趣，原来Hacker们也很搞笑有趣的。
摘录一个故事如下：
《无名师与方法论》
无名师和学生Nubi在圣地行走，无名师习惯在晚间为城市和乡村的Unix新门徒布道。
一次，聆听者中混入了一名方法论者。
“优化程序时不对热点进行反复衡量，就像渔夫把网撒入空湖中。”无名师说。
“那么，”方法论者说，”管理资源时不持续地衡量你的产能，不也像渔夫将网撒入空湖中么？”
“我一次碰到一个渔夫时，他正将网撒入船下的湖中，”无名师说，”他摸了好一会儿船底，像在寻找他的船。”
“但是，”方法论者说，”如果他把网撒入湖中，为什么他还要找船呢？”
“因为他不会游泳.”无名师答道。
听到这，方法论者眼中一亮。
怎么样，你能否猜出是模仿自哪个禅宗故事吗？
《UNIX编程艺术》读后感(四)：编程艺术实乃人类行为和心理之理解
本书多处提到“禅宗”，“禅宗”是一种哲学，用于指导人的行为和心理。编程则是人类众多行为中的一种，因此，如果对人类行为和心理有比较深入的理解和认识的话，因势利导，那么我们写出的程序将会更有质量，效率也不会差。
在此之前看过《编程大师访谈录》，多位编程大师都建议：大学时先学习数学、物理等，甚至是历史，在研究生阶段再学习计算机和编程。我的理解是：计算机和编程是对我们生活所在的世界和社会进行抽象和建模，是解决问题的方法和手段，需要我们对周遭的世界和社会有了比较深入的理解和认识。
试举一两个例子说明一下：
【模块化】：背后的逻辑是，人类大脑能够处理的信息是有限的（譬如一次最多只能记住7位数字），如果程序逻辑混杂在一起，那么人类将很难理解。这和我们人类常将各种东西分类是一个道理，譬如将科学分为：物理、化学、生物等；将动物分为爬行动物、哺乳动物等等。分类的一个好处就是将复杂的东西切割，切割成人类大脑能够处理的区块。
【透明性】：背后的逻辑是，人类的大脑总是寻求捷径，而对于复杂的东西，学习是有成本的。让人一看就知道怎么使用的程序自然是人类最喜欢的。
编程规范、程序的可读性等背后的逻辑是，人类的能力和素质总是参差不齐，为了保证软件的质量，通过制定规范，约束人类的行为，从而规避掉参差不齐素质下的不确定性。
《UNIX编程艺术》读后感(五)：向前辈致敬
作为WindowsAPI或者javaEE熏陶起来的程序员，也许已经习惯于用复杂晦涩的语法去处理进程间交互，习惯于看到COM/SOA那恐怖的规格，习惯于通过许多许多的专有工具去解析二进制格式的天书，习惯于用你趁手的开发语言码很多很多行的代码来折腾数据。
在这本书中你会发现一个迥异于绝大多数中国程序员认知的世界——一个属于字符，管道，以及脚本语言的世界。在这里，一切都是字符流，程序间的合作就如同呼吸一般自然，只需要几段短小的脚本，不用动用任何一种工业级编程语言,就可以组合出一个趁手的工具来简化你的生活。欢迎来到UNIX的世界，这是程序员的天堂。
我们会看到，许许多多的脚本语言（呃，我也不喜欢这个隐含贬义的名词，但是，有更好的名字么？）是如何优雅的协同以完成他们的工作。我们会看到，拜UNIX下那批强力字符处理工具所赐，一个字符格式的文件会带来怎样的方便。工具间的组合会碰撞出不可思议的火花。
书中有些部分不妨叫做”最佳编程实践“，这包括对配置文件格式，数据文件格式，交互协议，软件控制接口的设计指导思想的介绍，所有这些原则，都贯彻了UNIX的一贯指导方针，因此，也能带来UNIX环境的所有好处。这些设计，是否能放之四海，见仁见智，不过，至少，在UNIX世界中，这多半是个最优解。下次如果你需要设计一个文件格式或者配置模式，你就会发现它的价值所在
而书中另一部分，则为我们展示了一个广阔的多的空间，就是那诸多的微型语言。从不可或缺的Bash到声名赫赫的Postｓｃｒｉｐｔ，UNIX中充满了类似的，简单的，或者是复杂的，乃至是图灵完备的编程脚本。
在动态语言复兴的今天，以Ruby为代表的新一代编程语言让创立自己的微型语言变得不那么高高在上。对于某些复杂系统来说，这很可能这会是一个救命的奇招。也许，这是本书的最大价值所在。
《UNIX编程艺术》读后感(六)：形而上者谓之道
这本书是一种智者的言论，作者的经验学识让他所见所想都不同于我们，当一切成为历史，留下的沉淀下来的是这些闪光的思想。
但对于性能应该放到最后才进行考虑，有见仁见智的观点，对于性能应该视之为等同于风险来评估预测和管理控制，特别是对于大型软件，开发周期长，人员多，成本高，用户要求成熟度高的软件产品更应该重视性能所带来的设计风险和最终交付成本。
作者果然不负我的期望，写出了UNIX的思想和文化出来。我以前是对UNIX没什么了解，只是LINUX安装过几次，SOLARIS也只是摸过而已。作者从历史讲到文化，再从文化来评价各个操作系统以及技术，他的观点比较客观，能让我信服，也让我对UNIX有了一个大局观。将一个事物以对比的方式指点江山地评论，让人看起来却实很过瘾。我觉得国人从古到今都喜欢评论，不管是对什么都希望拿来评论一把，受众更是乐此不疲。
作者所讲UNIX的核心思想是：模块化，透明性和机制与策略的分离。模块化是从运行的角度来看的，一个程序就是一个模块，它靠OS的MMU 来独立化，但可以有效地通过各种手段来通讯。透明性是指通信协议都尽量的文本化，通过文本输入和输出，通过TCP/IP来通信也尽量以HTTP等的模式来进行，仅在为性能作优化时使用二进制数据;这使得程序的动作很透明，可以知道程序在做些什么。机制与策略的分离就是把算法实现尽量做成库，而与交互有关的都进行程序封装或脚本来驱动，更高的就是GUI的整合形成解决方案。另外有一个很重要的思想是程序编程要以数据来驱动，数据可以帮助查看程序状态，可以方便调试，可以方便理解。
作者还强调，UNIX下编程文化是一种轻松编程。
《UNIX编程艺术》读后感(七)：看完以后建议看看Rob Pike对Unix的总结
The Good, the Bad, and the Ugly: The Unix! Legacy
high-level programming language
hierarchical file system
uniform, unformatted files (text)
eparable shell
distinct tools
ipes
regular expressions
ortability
ecurity
虽然很短但是感觉超过了本书。
《UNIX编程艺术》读后感(八)：unix的哲学
这是一本关于unix开发哲学的书籍。也是一本历史书籍。你既可以从中了解unix/linux一路走来的历史，也可以了解到她背后的哲学，以及那些来龙去脉。
在作者看来，基于同行评审的代码检查与查看是unix兴起的基本要素，尤其在unix与TCP/IP融合后，unix的文化也发生了变化。直到开源运动的兴起，新unix，即linux，的出现，标示这场运动的一大成就并意味着一个巨大的里程碑。任何闭源的unix都走向失败，而开源的则走向成功。
对于个os的历史和基因属性也给的比较明确，最典型的如Mac OS/X，当代OSX有着高度的BSD UNIX混血，但也有Mac OS的特性。 NT倒是自成一家，从其他体系上发展而来。但现在都往POSIX上面靠了。
脚本和code故事也是一种纠结，基于文本比基于二进制要好，进程协作比一个大块头要好，Break是其中的关键，微型语言如reg、js是重要的，少吃多干还是多次多干并没有定论。
工具是重要的，文档则在全面HTML化和标记化，许可证MIT和BSD是善良的，GPL那是很凶的，命名规范是要注意的，_和数字是不能随便瞎用的。foobar-1.1.2.i386.bin.tar.gz要比foo_bar1.1.2.i386.tar.gz好。
configure / make / make install是一个咒语。configure的目的是生成make文件，当然是根据机器的情况生成。
UNIX的GUI是不行的,CLI是很行的，结构更是很好的，所以再优秀的os也有需求和UNIX融合的。
更重要的，在产品背后的是开发产品的人。
《UNIX编程艺术》读后感(九)：《UNIX编程艺术》读后感
作为一个多年的开源（Open Source）拥趸，像《UNIX编程艺术》（The Art of Unix Programming）这样的好书自然不能错过。大约一周前我无意中在公司书柜中发现了它，立刻开始投入阅读。现在，我已经开始边读第二遍边作读书笔记了。
开篇的译序很有趣，第一句话就写道：
“大多数译序是给作者说好话，顺便带动以下译本销量的，本篇是一个例外。”
这是我见过的最棒的序言开头之一，在表明了自己独特的观点和立场的同时，译者还有效地激起了读者的好奇心。我记得看到这儿当场就笑了。
中间还有一段是这样的：
“本书翻译历经一年多的时间，之前我曾经约略翻过纸版，偶尔见到一些合我胃口的言论，于是心有灵犀认为这书不错；然而等到译到中途，便发现ESR实在是美国愤青，这便是课外读物合工本教程给读者的不同感受了。翻译的过程对译者是精读的过程，但希望读者能用它来打发堵车、候机、等人时的无聊时间，这书适合从任何一篇翻起。”
ESR指的是原作者Eric S. Raymond。“美国愤青”这词难为译者如何想来，让人忍俊不禁！最后一句话让人深切地感受到三位译者（姜宏、何源和蔡晓俊）的谦逊和诙谐。
说完了译者序，再看看作者序。其中前两段话是我感同身受、极为赞赏的：
“知识和专能差异巨大，凭借知识可以推断出该做什么，而专能让你甚至在无意之间，条件反射似的把事情做好。
这本书确实有关‘知识’，但更着眼于‘专能’。你将学到那些Unix专家们都不自知的Unix开发知识。少一点技术，多一些共享文化：显见和隐微的，直观和潜流的－这是本书和大多数Unix书籍不同的地方－不止于方法，更重乎理念。”
“工程和设计的每个分支都有自己的技术文化。在大多数工程领域重，就一个专业人员的素养组成来说，有些不成文的行业素养具有与标准手册及教科书同等重要的地位（并且随着专业人员经验的日积月累，这些经验常常会比书本更重要）。资深工程师们在工作中会积累大量的隐形知识，他们用类似禅宗‘教外别传’的方式，通过言传身教传授给后辈。”
《UNIX编程艺术》读后感(十)：do one thing，and do it well -- 《UNIX编程艺术》书评 --luikimfai
断断续续的把《UNIX编程艺术》看完了， 实话说还记得的也就do one thing，and do it weill 和 保持程序模块化 这两点， 作者是一个UNIX大师， 全书并不讲解UNIX是怎么搞出来， 而注重于UNIX的编程思想。 程序总是会过时的，代码必须随时代不断演化， UNIX漫长的进化过程中， 正是这些编程思想保证了其长盛不衰的生命力。
自己最近才转行做邮件底层相关开发的， 对介绍smtp协议部分能看懂， 但在读其他的例子的时候就只能不求甚解，只抓编程思想，领悟编程艺术 ， 也正如译者序言所说的："翻译的过程对译者是精读，但希望读者能用它打发堵车，候机，等人的无聊时间， 这书适合从任何一篇翻起。"
鉴于自己在类UNIX下开发的经验尚浅， 计划2-3年后再重读一遍此书， 而阅读此书也确实需要一定的UNIX经验才能有更进一步的领悟。
do one thing，and do it well。