Unix哲学与文化

.TCP/IP编程
.知识和专能差异巨大，凭借知识可以推断出该做什么，而专能让你甚至在无意之间，条件反射似的把事情做好。
.理念于实用大有裨益，有太多设计不良的软件：体积臃肿，难于维护、移植和扩展---这些都是蹩脚设计的症侯。
.构成文化的是人，一直以来，获知文化的方式大约是口口相传、潜移默化。
.禅不是宗教，而一是种心灵鸡汤似的东西，纯净而没有神灵的干扰---此即是禅。
.man手册
 1   程序文档
 2   C的系统调用
 3   C的库函数调用
 5   文件格式与协议
 8   系统管理工具
.不懂Unix的人注定还要重复发明一个蹩脚的Unix.   (Henry Spencer 1987.11)
.资深工程师们在工作中会积累大量的隐性知识，他们用类似禅宗"教外别传"的方式，通过言传身教授给后辈。
.Unix诞生于1969年。
.Unix至今化身为Linux、BSD、Solaris、MacOS X以及好几个其它变种的Unix
.如果将来有什么技术来取代以太网，那么这个取代物的名字还会叫"以太网". (Rebort Metcalf)
.Unix的一个核心技术---C语言---已经在其它系统中植根。
.
.Unixr的g一ww个ssss核心rrr技术---Cyyyy语言---nnn已经d在aaa其它ttt系统k中ssss植根。
.Unix还引入了如今广泛采用的带目录节点的树形文件名字空间以及用于程序间通信的管道机制。
.至今Unix仍在创造价值，仍然能赢得这个星球上无数最优秀、最聪明的软件技术人员的忠诚。
.每过18个月，就有一半的知识会过时。
.外行常把Unix当作是教学用的玩具或黑客的沙盒而不屑一顾。
.对于一个始于1969年的设计来说，在Unix设计中居然很难找到硬伤，这着实令人称奇。
.Unix文件在字节层次以上再无结构而言。
.用错误的方式解决正确的问题总比用正确的方法解决错误的问题好。 (Doug Mcllroy)
.策略相对短寿，而机制才会长存。
.只提供机制不提供方针的哲学能使Unix长久保鲜，而那些被束缚在一套方针或界面风格内的操作系统，也许早就从人们的视线中消失了。
.在某些方面，Unix及其外围文化明显比任何竞争对手都出色。
."开源Open Source"这个术语和定义直到1998年才出现
.Unix源码是永生的，至少，永生在数十年不断维护翻修它们的Unix技术文化之中。
.美国国防部将第一版TCP/IP协议栈的开发合同交给一个Unix研发组就是因为考虑到Unix大部分是开放源码的。
.Unix已成为互联网服务提供商行业不可或缺的核心技术之一。
.统一资源定位符(URL)作为Web的核心概念，也是Unix中无处不在的统一文件名字空间概念的泛化。
.要做一个有效的网络专家，对Unix及其文化的理解绝对是必不可少的。
.程序得以形成严丝合缝的工具套装，而不是应景的解决对策。
.同Unix打交道，搞开发就是好玩，现在是，且一向如是。
.在Unix世界里，操作系统以成就感而不是挫折感来回报人们的努力。
.Unix下的程序通常会把Unix当作一个积极有效的助手，而不是把操作系统当作一个对手还非得用蛮力逼迫它干活。
.趣味性是一个峰值效率的标志，充满痛苦的开发环境只会浪费劳动力和创造力，无形中耗费大量时间、资金，还有机会。
.乐趣是一个符号，意味着效能、效率和高产。
.非Unix程序员也能从Unix积累的经验中获益。
.C语言本身是Unix的一项发明, C++/VC++只是C的延伸。
.那些毫无动力、松松垮垮而且薪水微薄的程序员们，能在短短期限内，如同神灵附体般造出稳定而新颖的软件---不过是经理人永远的梦呓。
.Unix文化鼓励那种分清轻重缓急的感觉，以及怀疑一切的态度，并鼓励你以幽默达观的态度对待这些。
.Unix管道发明人、Unix传统奠基人Doug McIlroy
   让每个程序就做好一件事。如果有新的任务，就重新开始，不要往原程序中加入新功能而搞得复杂。
   假定每个程序的输出都会成为另一个程序的输入，哪怕那个程序还是未知的。输出中不要有无关的信息干扰。避免使用严格的分栏格式和二进制格式输入。不要坚持使用交互式输入。
   尽可能早地将设计和编译的软件投入试用，哪怕操作系统也不例外，理想情况下，应是在几星期内，对拙劣的代码别犹豫，扔掉重写。
   优先使用工具而不是拙劣的帮助来减轻编程任务的负担。工欲善其事，必先利其器。
.Rob Pike最伟大的C语言大师之一
   在没有对代码进行估量，特别是没找到最耗时的那部分之前，别去优化速度。
   花哨的算法比简单算法更容易出bug、更难实现。尽量使用简单的算法配合简单的数据结构。(即拿不准就穷举(Ken Thompson))
   编程的核心是数据结构，而不是算法。
.Unix编程原则
   模块原则: 使用简洁的接口拼合简单的部件。
   清晰原则: 清晰胜于机巧
   组合原则: 设计时考虑拼接组合
   分离原则: 策略同机制分离，接口同引擎分离
   吝啬原则: 除非确无它法，不要编写庞大的程序
   透明性原则: 设计要可见，以便审查和调试
   健壮原则: 健壮源于透明与简洁
   表示原则: 把知识叠入数据以求逻辑质朴而健壮
   通俗原则: 接口设计避免标新立异
   缄默原则: 如果一个程序没什么好说的，就沉默
   补救原则: 出现异常时，马上退出并给出足够的错误信息
   经济原则: 宁花机器一分，不花程序员一秒
   生成原则: 避免手工hack, 尽量编写程序去生成程序
   优化原则: 雕琢之前先要有原型，跑之前先学会走
   多样原则: 决不相信所谓"不二法门"的断言
   扩展原则: 设计着眼未来，未来总比预想来的快
.计算机编程的本质就是控制复杂度。 (Brain Kernighan)
.要编制复杂软件而又不至于一败涂地的唯一方法就是降低其整体复杂度---用清晰的接口把若干简单的模块组合成一复杂软件。
.永远不要去吃力地解读一段晦涩的代码三次。每一次也许侥幸成功，但如果发现必须重新解读一遍---离第一次太久，具体细节无从回想---那么你该注释代码了，这样第三次相对不会那么痛苦了。  (Henry Spencer)
.如果程序彼此之间不能有效通信，那么软件就难免会陷入复杂度的泥淖。
.在输入、输出方面，Unix传统极力提倡采用简单、文本、面向流、设备无关的格式。
.在经典的Unix下，多数程序都尽可能采用简单过滤器的形式，即将一个输入的简单文本流处理为一个简单的文本流输出。
.要想让程序具有组合性，就要使程序彼此独立。在文本流这一端的程序应尽可能不要考虑文本流另一端的程序，将一端的程序替换为另一个截然不同的程序，而完全不惊扰另一端应很容易做到。
.当程序无法自然地使用序列化、协议形式的接口时，正确的Unix设计至少是，把尽可能多的编程元素组织为一套定义良好的API
.接口和引擎分离的经典例是Emacs，它使用内嵌的脚本语言Lisp解释器来控制用C编写的编辑原语操作。
.程序员都很聪明，常常以能玩转复杂东西和耍弄抽象概念的能力为傲。他们的设计能力大超出他们的实现和排错能力，结果便是代价高昂的废品。
.许多优秀的设计被市场推销所需要的大堆大堆"特性清单"扼杀----实际上，这些特性功能几乎从未用过。
.调试通常会占用四分之三甚至更多的开发时间，所以一开始就多做点工作以减少日后调试的工作量。
.一个特别有效的减少调试工作量的方法就是设计时充分考虑透明性(指一眼就能看出软件是在做什么以及怎样做的)和显见性(指程序带有监视和显示内部状态的功能，这样不仅能运行良好，而且还可以看得出它以何种方式运行)
.程序如果要展示其正确性，应使用足够简单的输入输出格式，这样才能保证很容易地检验有效输入和正确输出间的关系是否正确。
.健壮性指软件不仅能在正常情况下运行良好，而且在超出设计者设想的意外条件下也能运行良好。
.就健壮而言，设计时要考虑到能承受极端大量的输入，这一点也很重要。 (Henry Spencer)
.在有异常输入的情况下，保证软件健壮性的一个相当重要的策略就是避免在代码中出现特例。
.程序越简洁、越透明，也就越健壮。
.即使最简单的程序逻辑让人类来验证也很困难，但是就算是很复杂的数据，对人类来说，还是相对容易地就能推导和建模的。
.数据要比编程逻辑更容易驾驭。
.在设计中，应主动将代码的复杂度转移到数据之中去。
.关注目标受众，关注传统惯例。
.宽容地收，谨慎地发。
.90%的功能现在能实现，比100％的功能永远实现不了强。 (Kenighan和Plauger)
.过早优化是万恶之源。 (Donald Knuth)
.我最有成效的一天就是扔掉了1000行代码。 (Ken Thompson)
.设计代码时，要有很好的组织，让将来的开发者增加新功能时无需拆毁或重建整个架构。有义务给之后使用和维护自己编写的代码的人做点好事。
.如果可能，用C编写前，先用解释性语言搭建原型。
.小就是美，在确保完成任务的基础上，程序功能尽可能少。
.如果不明白什么是对的，那么就只做最少量的工作，确保任务完成就行，至少直到明白什么是对的。
.要良好的运用Unix哲学，你就应不断追求卓越。