《UNIX编程艺术》是一本由Eric S. Raymond著作，电子工业出版社出版的平装图书，本书定价：59.00元，页数：525，文章吧小编精心整理的一些读者的读后感，希望对大家能有帮助。

　　《UNIX编程艺术》读后感(一)：TAOUP给我们的启示

"Those who don't understand Unix are condemned to reinvent it, poorly." – Henry Spencer 1987.11

《UNIX编程艺术》（简称TAOUP，是对Knuth的TAOCP的致敬）讲解UNIX社区的历史、理念、哲学、原则，及其相关技术和软件。可作为故事书看完，也可作为相关技术参考。很奇怪的是，我基本上认同了该书陈述的所有理念与哲学，仿佛那些只是很自然的事情又似乎每一个人都可以接受一样（其实肯定并非如此），尽管我并非真正意义上的程序员或者黑客。

看完这本书我最大的收获或者想与大家分享的还不是书中的理念、哲学、技术，而是一个事实。通过作者的那番陈述（其实只是他叙述的方式在深深地影响我），我看到在我所在的这个地区（大学）的一个没有被太多人关注或者讨论的事实：目前我和我的同事、学生缺乏的不仅仅是理论、技术，可能更重要的问题是，我们缺乏一个具有统一理念且保持稳定发展的专业社区。

拿程序开发而论，我们往往看到我们讲授程序开发的局限性，也看到提升程序员能力的迫切性，更认识到目前要提高大部分同学编程能力的不可能性。一直在反思，是什么导致了这样的窘迫局面？我们有批评过教学的方法、教育的制度，也批判过社会的各种风气。然而，看完TAOUP之后，我想，如果我们的学生不能有（并且进入）一个可以影响他一生的程序员社区，不能学习生活在某个稳定的程序员社区中，并受一种薪火相传的理念或者称为文化氛围所熏陶与影响，他们在程序员这个路上势必无法走远。

稍微回顾一下我们学院CSer教育之路：大一学C、C++ （Windows 编程），然后Java，然后有数据结构、操作系统，再接着某些TCP/IP编程、做网站等等，学点数据库或者再加上软件工程。似乎学了很多知识，但是只要问一个问题，也许很多问题就暴露出来：我们培养的是具有何种统一技术理念的程序员？

这个问题在TAOUP中频频强调。我们号称培养的是灵活多变的程序员，无论什么操作系统都懂的程序员，反过来，其实是什么操作系统都不懂的程序员。也正因为我们不强调操作系统，那么操作系统所赋予的许多理念就不可能被传授，比如UNIX社区中的开源文化、代码重用、摒弃丑陋的GUI等等。这种不重视操作系统理念的编程教育，不能不说是因为Wintel 的崛起或者我国计算机教育的落后状况造成的极坏后果。

Windows为了满足一般用户桌面应用需求，提出“可见即所得”的理念，被鼓吹了20年。我们培养的程序员大部分是欣然接受这种理念的，尽管我并不能称他们是Windows程序员。我们培养的毕业生的毕业论文经常有很多丑陋的排版，只要你向他们指出，他们都归咎于Windows：没办法，Word就是这样工作的。比如，一张图片挤不进一个版面就会挤压到下一个版面而导致有一页有大量空行这样的错误。我不知道是否“Word就是这样工作的”，但是“可见即所得”绝对值得再写一篇文章批判。

我知道，要扭转这样一种简单的错误看法我们都需要花费上十年的工夫或者干脆是不可能的任务。为什么？因为他们身边大部分人都是这样的一般非技术用户，因为他们的老师、他们的技术主管、他们的领导都是从小就被Windows培养出来的专门人才。但是不要忘记，他们并不是Windows系统的专门人才，而仅仅是被简单而丑陋的系统惯坏了的用户罢了。我举这个例子只是想说明，要改变某些看上去容易改变的现状是非常非常困难的一件事情（注：批评Windows系统并不是一件容易接受的事情，更别提改变使用Windows的陋习是容易的事情。所以，我愿意为以上见解接受所有批评。），重点是没有一个正常的环境，即我一开始就提出的那种所谓的“程序员社区”。

如果我倡议说，把这样的社区建设起来，那也未免过于乐观了。一种文化氛围的建设岂是一人之力、几年的工夫可以完成的呢？那是不是就不可补救呢？也不尽然。当务之急，我想，首先要倡导尽可能多的同学在Linux下学习、编程、娱乐。其次，相关课程逐步跟进，比如，大一的编程、大二的操作系统、计算机网络等课程多强调Linux操作系统。希望星星之火可成为薪火相传之火、可以壮大成燎原之火！

也有人会问，那Windows操作系统这么流行就不讲了？答案是，Windows是流行，但是真没什么可以讲。所谓没什么可以讲是因为Windows本身就缺乏一种传统，而且它还是闭源系统，你讲什么？估摸现在能讲XP的老师都没有，但是XP已经退休了。那该讲Win8？嗨，这可能吗？就算能讲，讲完了估计该出Win10了。哦，不，也许是Win13，谁知道呢？

将IT文化建设的问题推广一步：一个地区的文化如果缺乏统一传承，那么这种文化即呈岌岌可危之势。在这一点上，我中华文化的传承中已经日益凸显其危机啊，就不提也罢了。不过，是该反思反思了。应该看到的是，我们的IT文化尚未成型，IT文化社区尚未建设，足可一叹，。这就是TAOUP给我的启示。分享给大家，应该是给大家的启示！

　　《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. 优化原则
过早优化是万恶之源。先制作原型，再精雕细琢，优化之前先确保能用，不要为蝇头小利投入过量时间。
同步于
http://www.cnblogs.com/coderkian/p/3581468.html

　　《UNIX编程艺术》读后感(三)：每个人都要保持简单、只顾眼前利益

两年前初入百度公司，读了这本书，然后就一直在linux上深入发展，深得unix编程艺术的启发。附上当年的总结的笔记：
1. 做一件事，做好它。
    KISS - Keep it Simple, Stupid！
    让一个程序就做好一件事，不要往原程序加入新功能而搞得复杂。
    要想掌控一个东西，就要把它拆分成一个个容易控制的单元。
    每个单元功能单一、简单、容易和其他单元连接。保持单一、保持轻量级、保持扩展性。
    清晰比聪明好。
    Small is beautiful.
2. 协同工作，形成流程
     假定每个程序的输出都会成为另一个程序的输入，哪怕那个程序是未知的。
     把简单笨拙的方法组合起来也许是最佳解决方案
3. 保持通用的数据结构和接口
    Store data into flat text files.
4. 80%的效果取决于20%的行为。需找满足用户90%需求的解决方案。不要试图解决无法遇见的情况。
5. 更坏就是更好， 便宜有效的系统更容易的到普及。
6. 保持内核轻量级。
最后，对比下linux和windows：
    在linux中，你要把你的任务分解成几个简单的子任务，并且下降一定抽象层次以达到linux本身的原语级别，然后将子任务用linux的工具解决掉。你不单要知道Unix里面的工具的作用，还需要对如何组合工具有一定经验，这样才能真正发挥系统的作用。
     而在Windows里面，是以用户层次的语言来说话的。比如，文档编写就是文档别写，表格编排就是表格编排。那些工具都按照你要做的事情编排好了，只有你用不完的功能，没有不够的特性（这话有点夸张）。因而，要做什么事情，就去找能覆盖你要做的事情的工具。所以，在这里你不需要记住工具要如何组合才能发挥作用。
     灵活需要付出灵活的学习成本，臃肿有臃肿的亲和力。
     linux注重基础设施，ios注重用户体验，windows注重性能和兼容性。

　　《UNIX编程艺术》读后感(四)：时时提醒自己KISS

之前读过《Linux/Unix设计思想》一书，加上这些年使用Linux的经验，对Unix的一些思想有所了解。读这本书就是一个老牌黑客给你讲各种经验和故事，穿插着上古时期的各种大神尊者的趣事。
1.6章的目录总结了Unix的设计哲学：
1.6 Unix哲学基础 11
1.6.1 模块原则：使用简洁的接口拼合简单的部件 14
1.6.2 清晰原则: 清晰胜于机巧 14
1.6.3 组合原则：设计时考虑拼接组合 15
1.6.4 分离原则: 策略同机制分离，接口同引擎分离。 16
1.6.5 简洁原则：设计要简洁，复杂度能低则低 17
1.6.6 吝啬原则: 除非确无它法，不要编写庞大的程序。 18
1.6.7 透明性原则：设计要可见，以便审查和调试 18
1.6.8 健壮原则: 健壮源于透明与简洁。 18
1.6.9 表示原则: 把知识叠入数据以求逻辑质朴而健壮 19
1.6.10 通俗原则：接口设计避免标新立异 20
1.6.11 缄默原则：如果一个程序没什么好说的，就保持沉默 20
1.6.12 补救原则: 出现异常时，马上退出并给出足量错误信息 21
1.6.13 经济原则: 宁花机器一分，不花程序员一秒 22
1.6.14 生成原则: 避免手工hack，尽量编写程序去生成程序 22
1.6.15 优化原则: 雕琢前先得有原型，跑之前先学会走 23
1.6.16 多样原则:决不相信所谓“不二法门”的断言。 24
1.6.17 扩展原则: 设计着眼未来，未来总比预想快。 24
总结成一个词就是： KISS.

　　《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。

　　《UNIX编程艺术》读后感(六)：编程艺术实乃人类行为和心理之理解

本书多处提到“禅宗”，“禅宗”是一种哲学，用于指导人的行为和心理。编程则是人类众多行为中的一种，因此，如果对人类行为和心理有比较深入的理解和认识的话，因势利导，那么我们写出的程序将会更有质量，效率也不会差。

在此之前看过《编程大师访谈录》，多位编程大师都建议：大学时先学习数学、物理等，甚至是历史，在研究生阶段再学习计算机和编程。我的理解是：计算机和编程是对我们生活所在的世界和社会进行抽象和建模，是解决问题的方法和手段，需要我们对周遭的世界和社会有了比较深入的理解和认识。

试举一两个例子说明一下：

【模块化】：背后的逻辑是，人类大脑能够处理的信息是有限的（譬如一次最多只能记住7位数字），如果程序逻辑混杂在一起，那么人类将很难理解。这和我们人类常将各种东西分类是一个道理，譬如将科学分为：物理、化学、生物等；将动物分为爬行动物、哺乳动物等等。分类的一个好处就是将复杂的东西切割，切割成人类大脑能够处理的区块。

【透明性】：背后的逻辑是，人类的大脑总是寻求捷径，而对于复杂的东西，学习是有成本的。让人一看就知道怎么使用的程序自然是人类最喜欢的。

编程规范、程序的可读性等背后的逻辑是，人类的能力和素质总是参差不齐，为了保证软件的质量，通过制定规范，约束人类的行为，从而规避掉参差不齐素质下的不确定性。