《UNIX编程艺术》已读过半，还是有些感想的。作者Eric S. Raymand同时又是fetchmail的开发和维护者，所以fetchmail可以说是本书所讲述的“编程艺术”的具体实现，实际上作者也正是将fetchmail作为各个思想的示例之一来阐述的。fetchmail本身并不是一个硕大的程序，但是正所谓“麻雀虽小，五脏俱全”，处处皆学问，我们通过阅读此书，能一窥fetchmail的设计思路，也就是ESR所说的“UNIX编程艺术”。
其实ESR在此书的前部分就概括出了UNIX编程艺术 -- Keep It Simple, stupid(K.I.S.S)。其余各个章节主要围绕KISS这个中心，具体讲述它在程序设计各个阶段和方面的具体体现，并借用实例来具体讲解。
前三章，是本书的概述，UNIX的历史介绍和UNIX哲学与其他哲学的比较。印象比较深刻的是作者对Linux和UNIX所做的比较，作者认为现在UNIX哲学的先锋军Linux与UNIX旧学派相比，更具包容性，更开放，更加独立于硬件，当然也更加贴近于大众。从Linux 2.6版本内核的诸多关于桌面应用的更新我们就能发现Linux对桌面市场的“野心”。作者认为商业系统的向后兼容成为了阻碍它进步的羁绊，其实这种事情也同样发生在开源软件上，发生在Linux上，并且非向后兼容的系统的维护代价更高。
第四章，讲述模块设计的概要：专注一件事情，并做到最好。
第五章，讨论协议和配置文件的设计，并比较了文本协议和二进制协议的优劣。作者推崇文本化的协议和配置文件，虽然它大多数时候在处理时间和空间占用上没有优势可言，但是它易读，易改，并且可以用压缩来减少空间占用。当然，二进制协议和配置文件也并非一无是处，在时间和空间要求比较严格的情况下，它还是大有作为的。其实，还是辩证法，因地制宜。章末作者又推荐了应用协议的元格式：广泛应用于C/S架构的HTTP协议;既适应C/S架构又适合P2P架构的BEEP协议;面向消息和调用的XML-RPC，SOAP等。
第六章，透明性，主要为了满足最终用户和开发人员的“窥视”欲，让用户明明白白，开发人员能更快地锁定bug。
第七章，多道程序设计，也就是分工合作了。分工较为容易，作为合作手段的沟通（IPC）就不是那么容易了。作者提倡用进程而不是线程，线程确实比较麻烦！
第八章，微型语言。体会不深，反正不要轻易标新立异就行了。
第九章，中心似乎不太明确，也有可能是我没能理解。“数据比程序逻辑更易驾驭”，所以考虑转移复杂度到数据。“懒人”讨厌重复性劳动，考虑自动生成代码。
目前就这些了，等看完后几章再写！
阅读(2185) | 评论(0) | 转发(0) |
