基本工具
纯文本的威力
1.工具是你双手的延伸。
2.纯文本格式，就是没有任何文本修饰（粗体，下划线，斜体，图形等），也没有影音、图像、样式、超链接、表格等的文本。
3.提供“锋利”的小工具，其中每一样都意在把一件事情做好——Unix因围绕这样的哲学进行设计而著称。
4.纯文本的好处：保证不过时；杠杆作用；更易于测试。
5.使用你喜欢的语言，用直接的二进制表示设计一个小地址簿数据库。
6.XML是纯文本的好例子。
shell游戏
1.GUI的好处是WYSIWYG，所见即所得；缺点是WYSIAYG，所见即全部所得。通常，任何一样工具的适用范围都局限于该工具预期要完成的任务。
2.你是否曾将一些说明发给同事，其中涉及许多“点这个按钮”，“选哪一项”之类的步骤？他们能自动化吗？
3.每当你迁往新环境，要找出可以使用的shell，并且调查各种可用于替换你现在shell的选择。
强力编辑
1.语法突显非常有用；能够在编辑器环境中进行编译，并直接转到出错处非常方便；自动缩进是另一种有用的特性，编辑器在比如敲入左花括号时为你进行缩进。
源码控制
1.源码控制系统（sccs）能做的远比撤销错误要多。好的sccs让你追踪变动，回答这样的问题：谁改动了这一行代码？在当前版本与上周的版本之间有什么区别？在这次发布的版本中我们改了多少行代码？哪个文件改动最频繁?
调试
1.人很容易恐慌，但非常重要的事情是，要后退一步，实际思考什么可能造成你认为表征了bug的那些症状。
2.编译器只能帮你找出部分bug。
3.bug报告的准确性在经过第三方之手时会进一步降低——实际上你可能需要观察报告bug的用户的操作，以获取足够程度的细节。
4.我们想要的不是能够通过长长的步骤再现的bug；我们要的是能够通过一条命令再现的bug。
5.找到问题的原因的一种非常简单却又特别有用的技术是向别人解释它。
6.当你遇到让人吃惊的bug时，除了知识修正它以外，你还需要确定先前为什么没有找出这个故障。考虑你是否需要改进单元测试或其他测试，以让他们有能力找出这个故障。还要考虑造成这个bug的条件是否存在于系统中的其他任何地方？
文本操纵
1.学习一种文本操纵语言，比如说perl。
代码生成器
1.当木匠面临一再地重复制作同一样东西的任务时，他们会取巧。他们给自己建造夹具或模板。一旦他们做好了夹具，他们就可以反复制作某样工件。夹具带走了复杂性，降低了出错的机会，从而让工匠能够自由地专注于质量问题。
2.主动代码生成器和被动代码生成器。
3.你可以用代码生成器生成几乎任何输出：html,xml,纯文本——可能成为你项目中别处输入的任何文本。
注重实效的偏执
按合约设计
1.注重实效的程序员连自己也不信任，知道没有人能编写完美的代码，包括自己，所以注重实效的程序员针对自己的错误进行防卫性的编码。
2.什么是正确的程序？不多不少，做它声明要做的事情的程序。
3.如果任何一方没有履行合约的条款，某种补偿措施就会启用，例如引发异常或是终止程序。
4.继承和多态是面向对象语言的基石，是合约可以真正闪耀的领域。
5.在设计时简单的列举输入域的范围是什么，边界条件是什么，例程允诺交付什么——或者，更重要的，它不允诺交付什么——是向着编写更好的软件的一次飞跃。
6.不变项也是一种合约。
7.一定不要把固定的需求，不可违反的法则与那些仅仅是政策的东西混为一谈，后者可能会随着新的管理制度的出台而改变。
死程序不说谎
1.尽早检测问题的好处之一是你可以更早崩溃。而有许多时候，让你的程序崩溃是你的最佳选择。
2.为什么要设计抛出异常？因为在遇到异常的时候我们一般会终止程序，但是在终止程序之前我们还要做很多其它的事情，比如说记录log啊释放变量啊什么的。
断言式编程
1.在自责中有一种满足感，当我们责备自己时，会觉得再没人有权责备我们。
2.不要用断言代替真正的错误处理，因为断言检查的是绝不应该发生的事情。
何时使用异常
1.即使用异常编程可能会更简洁，但是不要把异常用作正常处理的一部分程序，因为他们破坏了封装：通过异常处理，例程和它们的调用者被更紧密地耦合在一起。
2.不支持异常的语言常常拥有一些其他的非局部控制转移机制。
怎样配平资源
1.为什么有栈？因为以与资源分配的次序相反的次序解除资源的分配的话，如果一个资源含有对另一个资源的引用，你就不会造成资源被遗弃。
2.死锁：如果进程A申请了resource1，并正要申请resource2，而进程B申请了resource2，并试图获得resource1，这两个进程就会永远等待下去。解决办法之一是在代码不同的地方分配同一组资源时，总是以相同的次序分配他们。