首先我们来听一个令人恶心的例子。
你看到问题 F00-123 被解决了。这是关于一个你自己很熟悉的子系统的Bug，所以直觉告诉你造成这个Bug最可能的原因。为了证实你的怀疑，你决定看看这个bug是怎么被解决的。你花了很长时间搜索了整个版本历史，直到把这个bugfix的范围缩小到了4个连续的提交，它们分别的提交信息是：dao小调整(dao tweaks)、moar、Fixes， 还有删除一些调试信息(remove debug stuff)。每个提交的修改集看起来都很大，多达十几个文件的几百处修改。“我艹尼@#$%%^&”，你准备骂娘但还是停住了，没有骂出你脑中那句最难听的粗口。”这个bugfix不应该超过三行代码!”。
最早的C是没有声明的，只有定义，声明主要是提供给连接器(link)用的，现在好像C编译器也用到声明。（这句话我不太确定，你当作耳旁风好了）
定义就是给出一个函数的明确功能，比如：
DRY 是一个最简单的法则，也是最容易被理解的。但它也可能是最难被应用的（因为要做到这样，我们需要在泛型设计上做相当的努力，这并不是一件容易的事）。它意味着，当我们在两个或多个地方的时候发现一些相似的代码的时候，我们需要把他们的共性抽象出来形一个唯一的新方法，并且改变现有的地方的代码让他们以一些合适的参数调用这个新的方法。
下面这些原则，不单单只是软件开发，可以推广到其它生产活动中，甚至我们的生活中。
DRY是一个最简单的法则，也是最容易被理解的。但它也可能是最难被应用的（因为要做到这样，我们需要在泛型设计上做相当的努力，这并不是一件容易 的事）。它意味着，当我们在两个或多个地方的时候发现一些相似的代码的时候，我们需要把他们的共性抽象出来形一个唯一的新方法，并且改变现有的地方的代码 让他们以一些合适的参数调用这个新的方法。
研究人员在研究了计算机编程心理学后，得出了一个程序员们在解决一个困难的bug时的心路里程。这些不同的境界，很像为大众所知的Kübler-Ross Stages of Grief（这个模型描述了人对待哀伤与灾难过程中的5个独立阶段（否认，愤怒，耍赖，抑郁，接受）。绝症患者被认为会经历这些阶段），而且原因都很相似。就好像死亡所伴随的悲伤一样，fix一个bug是一个过程其初始化了一个事件，一开始是拒绝相信，其造就了你苦闷的情绪并开始逐步影响你的心智。这种苦闷的情结果会让你纠结要努力忍受，最终会你会找到一个满意的结果。
十年前，有四个年轻人改变了这个世界的运作方式。他们使用的并不是法律或是武器或是金钱，而是使用软件来改变世界。他们当时有着激进和极具破坏性的想法，并把这些想法付诸于代码，在Internet上以免费自由方式发布。这四个人，没有一个完成了大学学业，却奠定了今天我们习惯的数字媒体环境的基础。然后，因为各种原因，他们也迅速地消失在公众视野中。
首先，是 Windows API 和 DLL Hell。（译注：DLL Hell——DLL灾难，就是微软的DLL升级时因为不同版本可能造成应用程序无法运行的灾难，首当其冲的是COM编程，相信大家都知道某些木马或是病毒更改了一些系统的DLL可以导致整个Windows不举，这就是DLL Hell） 于是，第一次革命是DDE——我们可以创建一个状态条在上面显示Microsoft的股票价格（译注：Dynamic Data Exchange，工作原理是： 甲方申请一块全局内存，然后把内存指针postmessage到乙方，乙方根据收到的指针访问那块全局内存）。
语句保持通顺，标点无错。不只是邮件，所有类型的写作都有这一条。偶尔犯个小错大家也会宽容。
公务环境请使用环境中通行的语言。不要在中文邮件中突然冒出个说英文的，非常不礼貌。
定义电子邮件的「好」是很难的。
若你写了一封「加薪申请」给老板，哪怕对方只回复俩字「OK」，那也算是好得令人动容。但如果邮件来自令你头疼的追求者，哪怕对方把邮件写成了一幅《兰亭集序》，可能也逃不过「Report as spam」的厄运。
从打开电源到开始操作，计算机的启动是一个非常复杂的过程。那么计算机到底是如何启动的？
先问一个问题，”启动”用英语怎么说？
回答是boot。可是，boot原来的意思是靴子，”启动”与靴子有什么关系呢？ 原来，这里的boot是bootstrap（鞋带）的缩写，它来自一句谚语：