程序员修炼之道

DRY原则，不要重复。重复分为强加的重复，无意的重复，无耐性的重复以及开发之间的重复。我觉得其中最容易发生的是无耐性的重复，拷贝一个大致相同的函数，修改一些参数完成类似的功能，看起来似乎合理又省事，但的确会留下隐患。开发者之间的重复就提到一个比较高的层次了，首先是代码的架构和分工需要非常合理，否则必然会造成一定程度的重复以及事倍功半的效果，还有一部分也是需要大家之间的交流，不要因为完成的功能模块不尽相同而各做各的。正交性，即写的程序或是组件具有一定的独立性，不会影响到其他。这样做的好处有很多，一是在你自己写代码的时候可以不用过多考虑之前的代码，这样真的很省事；二是当你在修改一部分代码的时候就完全不用担心会对其他造成影响甚至改动大局，可以实现局部修改；三是代码与代码之间的独立，使得两者组合能带来更大的效益。如何在写代码的时候保持正交性，一方面保持解耦，一方面避免使用全局数据，还有就是避免写相似的函数，其实一些命名的不规范也会导致这个问题。可撤销性，即多给自己的代码留条退路。

不要为错误找借口，当出现一个程序错误的时候，要勇于承认并尽快解决掉它，而不是逃避问题逃避责任。 “破窗户理论”：一扇破窗户如果不能得到及时的修理，就会给人一种放弃感，从而产生越来越多的破窗户。 写程序也是一样，一些不规范的命名，有逻辑问题的代码，甚至是一些错误的决定和有问题的设计都是一扇破窗户，只有及时改掉这些小毛病，才能避免更大的错误出现，至少是减小了几率产生吧。 煮石头：当你想做一件事的时候，不要什么也不做就向别人伸手，而是自己先努力去做，让别人看到一些成果或是希望，这样才能吸引大家，使大家心甘情愿地也参与进来。 足够好的软件，就是让客户参与进来，尊重客户的意见，给客户机会让他们参与决定你制作的东西是否足够好。明天做的软件并不一定比今天做的软件好，或许有一些功能得到了提升，甚至是开辟了新的功能，但是许多用户可能不愿意升级，包括我自己也是，除非出了非常吸引我的功能，我都不愿意升级，基本上是习惯问题，用户的习惯决定了他们对产品的满意度。 知识资产：要想提高自己的知识资产，我认为有两点，一个是广度，一个是深度。在广度上拓宽，可以学习一些新的技术，如果能摸清前沿方向，及时抓住新技术的潮流，那带来的收益就像股市买了一支低价股一样丰厚。在深度上挖深，一些东西只停留在表面的话可能永远也掌握不到它的真谛，我始终相信，一件事你不停的往下做一点，可能暂时不会有什么成效，但当你的深度达到一个点的时候，可能会有质的突破。

第三节：等你准备好1.当面对一件任务时，如果你反复感觉到疑虑，或是体验到某种勉强，要注意它，并给它时间，你的疑虑可能结晶成为某种更坚实的东西，某种你可以处理的东西。ps：这种感觉就相当于到了自己能力的边界，你没有十足的把握，当最后消除这种疑虑的时候，你也是进步了。第四节：规范陷阱2.健康的开发过程鼓励把来自实现和测试的意见反馈到规范中。而不是用规范来限制实现和测试。第五节：圆圈与箭头3.不要做形式方法的奴隶。ps：我们喜欢有些技术和方法，但我们相信，盲目地采用任何技术，而不把它放进你的开发实践和能力环境中，这样的处理方法肯定会让你失望。

在所有的弱点中，最大的弱点就是暴露弱点不要容忍破窗户不要留着破窗户（低劣的设计，错误决策，糟糕的代码）不修，发现一个就修一个，如果没有时间修理，就将代码放入注释，显示“未实现”字样。管理知识资产 我们喜欢把程序员所知道的关于计算技术和他们所工作的应用领域的全部事实，以及他们的所有经验视为他们的知识资产（knowledge portfolios） 定期投资。就像金融投资一样，你必须定期为你的知识资产投资，即使投资量很小，习惯自身也和总量一样重要。 多元化。你知道的不同的事情越多，你就越有价值。作为底线，你需要知道你目前所有的特定技术的各种特性。但不要就此止步，计算技术的面貌变化很快，你掌握的技术越多，你就越能更好的进行调整，赶上变化 管理风险。从高风险、可能有高回报，到低风险、低回报，技术存在于这样一条谱带上，把你所有的金钱都投入可能突然崩盘的高风险股票并不是一个好主意；你也不应太保守，错过可能的机会。不要把你所有的技术鸡蛋放在一个篮子里。 低买高卖。在新兴的技术流行之前学习它可能就和找到被低估的股票一样困难，但所得到的就和那样的股票带来的收益一样。 重新评估和平衡。这是一个非常动荡的行业，你上个月开始研究的热门技术现在也许已像石头一样冰冷。也许你需要重温你有一阵子没有使用的数据库技术，又或许，如果你之前试用过另一种语言，你就会更有可能获得那个新职位。。。总之，定期为你的知识资产投资。什么是获得智力资本，从而为你的资产提供资金的最佳方式呢？有一些建议： 每年至少学习一种新语言。不同语言以不同方式解决相同的问题。通过学习若干不同的方法，可以帮助你扩宽你的思维，并避免墨守成规。此外，现在学习许多语言已容易了很多。 每季度阅读一本技术书籍。讨论与你当前的项目有关的话题。一旦你养成读书习惯，就一个月读一本书。在你掌握了你正在使用的技术之后，扩宽范围，阅读一些与你的项目无关的书籍。 也要阅读非技术书籍。记住计算机是由人使用的，不要忘了等式中人这一边。 上课。在本地的学院或大学，或是将要来临的下一次会展上寻找有趣的课程。 参加本地用户组织。不要只是去听讲，而要主动参与，于是隔绝对你的职业生涯来说可能是致命的；打听一下你们公司以外的人都在做什么。 实验不同的环境。如果你在Windows上工作，就在家玩一玩Unix，如果你只用过makefile和编辑器，就试一试IDE。 跟上潮流。订阅商务杂志和其他期刊，选择所涵盖的技术与你当前的项目不同的刊物。 上网。信息来源。最后，批判的思考你所读到的和听到的。警惕声称他们的信条提供了唯一答案的狂热者。交流知道你想要说什么了解你的听众选择时机选择风格 调整你的交流风格，让其适应你的听众。让文档美观让听众参与 我们常常发现，与制作文档的过程相比，我们制作出的文档最后并没有那么重要，如果可能，让你的读者参与文档的早期草稿的制作。获取他们的反馈，并汲取他们的智慧，你将建立良好的工作关系，并很可能在此过程中制作更好的文档。做倾听者回复他人你说什么和你怎么说同样重要注重实效的途径不要重复你自己让复用变得容易消除无关失误之间的影响（正交性）不存在最终决策（可变因素很多） 灵活的架构曳光弹 用曳光弹找到目标，曳光弹优点： 用户能够及早看到能工作的东西 开发者构架了一个他们能在其中工作的结构 你有了一个集成平台 你有了可用于演示的东西 你将更能够感觉到工作进展曳光弹告诉你击中的是什么，那不一定总是目标，于是你调整准星，知道完全击中目标为止，这正是要点所在。制作架构原型 为了学习而制作原型。许多原型被构造出来，是要为在考虑之下的整个系统建模，与曳光弹不同，在原型系统中，单个模块不需要能行驶特定的功能。事实上，要制作架构原型，你甚至不一定需要进行编码，你可以用便签或索引卡片，在白板上制作原型，你寻求的是了解系统怎样结合成为一个整体，并推迟考虑细节，下面是一些你可以在架构原型中寻求解答的具体问题： 主要组件的责任是否得到了良好定义？是否适当？ 主要组件间的协作是否得到良好定义？ 耦合是否得以最小化？ 你能否确定重复的潜在来源？ 借口定义和各项约定是否可接受？ 每个模块在执行过程中是否能访问到其所需的数据？是否能在需要时进行访问？根据我们制作原型的经验，最后一项往往会产生最让人惊讶和最有价值的结果领域语言 语言的界限就是一个人的世界的界限靠近问题领域编程 考虑到大多数应用都会超过预期的使用期限，你可能最好咬紧牙关，先就采用更复杂、可读性更好的语言，最初的努力将在降低支持与维护费用方面得到许多倍的回报。估算 估算，以避免发生意外。我们发现，为项目确定进度的唯一途径常常是在相同的项目上获取经验。增量开发是步骤：检查需求、分析风险、设计，实现，集成、想用户确认。 于是你完成了初始功能的编码与测试。并将此标记为第一轮增量开发的结束，基于这样的经验，你可以提炼你原来对迭代次数，以及在每次迭代中可以包含的内容的猜想，提炼会变得一次比一次好，对进度表的信心也将随之增长。 通过代码对进度表进行迭代。基本工具 花时间学习使用这些工具，有一天你将会惊奇的发现，你的手指在键盘上移动，操纵文本，却不用进行有意识的思考，工具将变成你的双手的延伸。纯文本的威力 我们搜集需求，将其变为知识，随后又在我们的设计，实现，测试、以及文档中表达这些知识，而且我们相信，持久的存储知识的最佳格式是纯文本。Shell的优势 每个木匠都需要好用、坚固、可靠的工作台，用以在加工工件时把工件放置在方便的高度上，工作台成为木工房的中心，随着工件的成型，木匠会一次次回到工作台的近旁。 对于操纵文本文件的程序员，工作台就是命令shell。在shell提示下，你可以调用你的全套工具，并使用管道，以这些工具原来的开发者从未想过的方式把它们组合在一起。 Shell命令可以被组合进脚本文件中，你可以构建命令序列，是你常做的事情自动化。强力编辑 我们认为你最好是精通一种编辑器，并将其用于所有的编辑任务。重要的是精通。源码控制 可撤销（undo）与重做（redo）的源码控制系统可提高你的效率。 把整个项目置于源码控制系统的保护之下具有一项很大的、隐蔽的好处：你可以进行自动的和可重复的产品构建。（rcs）调试 要修正问题，而不是发出指责。Bug是你的过错还是别人的过错，并不是真的很有关系。它仍然是你的问题。调试第一准则：不要恐慌 一个脑细胞都不要浪费在”但那不可能发生“的思路上。使数据可视化 直截了当的”variable name=data value“（看变量的值）坏变量？检查它们的邻居 先快速的查看一下这个坏变量周围的内存。但是，如果没有显而易见的地方让你着手查看，你总是可以依靠好用的老式二分查找。看症状是否出现在代码中的两个远端之一，然后看中间，如果问题出现了，则bug位于起点与中点之间；否则，它就在中点与终点之间。以这种方式，你可以让范围越来越小，直到确定问题所在。不要假定，要证明 当你遇到让人吃惊的bug时，除了只是修正它以外，你还需要确定先前为什么没有找出这个故障。考虑你是否需要改进单元测试或其他测试，以让它们有能力找出这个故障。 还有，如果bug是一些坏数据的结果，这些数据在造成爆发之前传播通过了若干层面，看一看在这些例程中进行更好的参数检查是否能更早的隔离它。 如果一个bug花了很长时间修正，你是否可以做点什么，让下一次修改这个bug更容易。学习一种文本操纵语言 如Perl。 我们几乎每天都使用文本操纵语言，与我们注意到的其他任何语言相比，本书中的许多想法都可以用这些语言更简单地实现，这些语言使我们能够轻松的编写代码生成器。代码生成器 编写能编写代码的代码。 被动代码生成器减少敲键次数。它们本质上是参数化模板，根据一组输入生成给定的输出形式。被动代码生成器用途： 创建新的源文件 在编程语言之间进行一次性转换 生成查找表及其他在运行时计算很昂贵的资源 主动代码生成器只是一种便利手段。通过其你可以取某项只是的一种表示形式，将其转换为你的应用需要的所有形式，这不是重复，因为衍生出的形式可以用过就扔，并且是由代码生成器按需生成的。 让输入格式保持简单，代码生成器就会变得简单。你可以用代码生成器生成几乎任何输出：HTML、XML、纯文本（不一定要生成代码）断言式编程 如果它不可能发生，用断言确保它不会发生 原型：void assert( int expression ) assert的作用是现计算表达式 expression ，如果其值为假（即为0），那么它先向stderr打印一条出错信息，然后通过调用 abort 来终止程序运行。#include <stdio.h>#include <assert.h>#include <stdlib.h>int main( void ){ FILE *fp; fp = fopen( "test.txt", "w" );//以可写的方式打开一个文件，如果不存在就创建一个同名文件 assert( fp ); //所以这里不会出错 fclose( fp ); fp = fopen( "noexitfile.txt", "r" );//以只读的方式打开一个文件，如果不存在就打开文件失败 assert( fp ); //所以这里出错 fclose( fp ); //程序永远都执行不到这里来 return 0;} 已放弃使用assert()的原因是，频繁的调用会极大的影响程序的性能，增加额外的开销。在调试结束后，可以通过在包含 #include <assert.h>的语句之前插入 #define NDEBUG 来禁用assert调用，示例代码如下：#include <stdio.h>#define NDEBUG#include <assert.h>按合约设计 按合约规定编写软件。 使用DBC的最大好处也许是它迫使需求与保证的问题走到前台来。何时使用异常 我们相信，异常很少应作为程序的正常流程的一部分使用；异常应保留给意外事件，假定某个未被抓住的异常会终止你的程序，问问你自己：“如果我移走所有的异常处理器，这些代码是否仍然能运行？”如果答案是“否”，那么异常也许就正在被用在非异常的情形中。错误处理器是另外一种选择 错误处理器是检测到错误时调用的例程，你可以登记一个例程处理特定范畴的错误，处理器会在其中一种错误发生时被调用。怎样配平资源 要有始有终。分配资源的例程也应该释放它。 对于一次需要一只一个资源的例程，可以对资源分配的基本模式进行扩展，有两个另外的建议： 以与资源分配的次序相反的次序解除资源的分配，这样，如果一个资源含有对另一个资源的引用，你就不会造成资源被遗弃。 在代码的不同地方分配同一组资源时，总是以相同的次序分配它们，这将降低发生死锁的可能性（如果进程A申请了resource1，并正要申请resource2.而进程B申请了resource2，并试图获得resource1.这两个进程就会永远等待下去）。无论是谁分配的资源，它都应该负责解除该资源的分配。元程序设计 再多的天才也无法胜过对细节的专注。动态配置 要配置，不要集成。 元数据到底是什么？严格的说，元数据是关于数据的数据，最为常见的例子可能是数据库schema或数据词典。元数据是任何对应于应用进行描述的数据——应用该怎样运行，它应该使用什么资源等等。在典型情况下，元数据在运行时，而不是编译时被访问和使用。你每时每刻都在使用元数据——至少你的程序是这样。假定你点击某个选项，隐藏你的web浏览器上的工具栏，浏览器将把该偏好作为元数据存储在某种内部数据库中。元数据的应用 我们想要尽可能多的通过元数据配置和驱动应用。我们的目标是以声明方式思考（规定要做什么，而不是怎么做），并创建高度灵活和可适应的程序。商业逻辑 于是你让数据库引擎的选择变成了配置选项，并提供了元数据来确定用户界面风格。 对于不那么复杂的逻辑，可以使用小型语言加以表达，从而消除在环境变化时重新编译和重新部署的需要。协作式配置 操作系统在启动时已经针对硬件进行了配置，而web浏览器会自动用新组件更新自己。 没有元数据，你的代码就不可能获得它应用的适应性与灵活性。黑板 没看懂。 用黑板协调工作流。 黑板系统让我们完全解除了我们的对象之间的耦合，并提供了一个“论坛”，知识消费者和生产者可以在那里匿名、异步的交换数据。如你可能会猜想的那样，它还减少了我们必须编写的代码的数量 基于计算机的黑板系统最初是在人工智能中应用而发明的。在那样的应用中，要解决的问题大而复杂——语音识别、基于知识的推理系统，等等。 现代的分布式类黑板（blackboard-like）系统，比如javaspaces和t spaces，以一种键值对模型为基础；这种模型首先在Linda中得到推广，在其中被称为元祖空间（tuple space）第六章 当你编码时 While you are coding 注重实效的程序员批判的思考所有的代码，包括我们自己的。我们不断的在我们的程序和设计中看到改进的余地。在“重构”中，我们将讨论一些即使我们还处在项目中期，也能帮助我们修正现有代码的技术。 只要你在制作代码，你就应当记住，有一天你必须对其进行测试，要让代码易于测试，这样你将增加它实际通过测试的可能性。不要靠巧合编程 对于你调用的例程，要只依靠记入了文档的行为，如果出于任何原因你无法做到这一点，那就充分的把你的各种假定记入文档。 怎样深思熟虑的编程： 总是意识到你在做什么。 不要盲目的编程，试图构建你不完全理解的应用，或是使用你不熟悉的技术，就是希望自己被巧合误导。 按照计划行事。 依靠可靠的事物。 为你的假定建立文档（“按合约编程”）有助于澄清你头脑中的假定，并且有助于把它们传达给别人。 不要只是测试你的代码，还要测试你的假定。不要猜测，要实际尝试它。 为你的工作划分优先级。把时间花在重要的方面；很有可能，它们是最难得部分。如果你的基本原则或基础设施不正确，再花哨的铃声和口哨也是没有用的。 不要做历史的奴隶，不要让已有的代码支配将来的代码。如果不再适用，所有的代码都可被替换，即使是在一个程序中，也不要让你已经做完的事情约束你下一步要做的事情——准备好进行重构，这一决策可能会影响项目的进度，我们的假定是其影响将小于不进行改动造成的影响。所以下次有什么东西看起来能工作，而你却不知道为什么，要确定它不是巧合。算法速率 注重实效的程序员几乎每天都要使用：估计算法使用的资源——时间、处理器、内存。等等 一般输入越多，运行时间就越长，或者使用的内存就越多。O()表示法 就是时间复杂度。 各种算法运行时间：一些常见的O()算法： O(1) 常量型（访问数组元素，简单语句） O(lg(n)) 对数型（二分查找），lg(n)表示法是log2(n)de 简写。 O(n) 线性型（顺序查找） O(nlg(n)) 比线性差，但不会差很多（快速排序、堆排序的平均运行时间） O(㎡) 平方律型(选择和插入排序) O(㎥) 平方型（2m*m矩阵相乘） 指数型（旅行商问题，集合划分）常识估算： 简单循环。如果某个简单循环从1运行到n，那么算法很可能就是O(n) 嵌套循环。如果你需要在循环中嵌套另外的循环，那么你的算法就变成了O(m*n),这里的m和n是两个循环的界限，这通常发生在简单的排序算法中。如冒泡排序。 二分法。如果你的算法在每次循环时把事物集合一分为二，那么它很可能是对数型O(lg(n))算法，对有序列表的二分查找、遍历二叉树、以及查找机器字中的第一个置位了的位，都可能是O(nln(n)). 分而治之。划分其输入，并独立的在两个部分上进行处理，然后再把结果组合起来的算法可能是O(nln(n)),经典例子是快速排序。 组合。只要算法考虑事物的排列，其运行时间就有可能失去控制。这是因为排列涉及到阶乘n!，得出5个元素的组合算法所需时间是1,6个元素需要6倍的时间，7个元素需要42倍的时间。估算你的算法的阶你可以通过一些途径处理潜在的问题。如果你有一个O(㎥)算法，设法找到能使其将至O(nln(n))的分而治之的途径。考虑你在代码自身中所做的事情。对于较小的n值，简单的O(n^2)循环的性能可能会比复杂的O(nln(n))算法更好，特别是当O(nlg(n))算法有昂贵的内循环时。如果要获得准确的计时很棘手，就用代码剖析器（code profiler）获得你的算法中的不同步骤的执行次数。并针对输入的规模绘制这些数字。最好的算法对于你的工作并非总是最好的。如果你选择的算法有高昂的设置开销，你也需要注意，对于小输入集，这些设置时间可能会使运行时间相型见拙，并使得算法变得不再适用。易于测试的代码 我们需要从一开始就把可测试件（testability）构建进软件中，并且在把各个部分连接在一起之前对每个部分进行彻底的测试。单元测试 在隔离状态下对每个模块进行测试，目的是检验其行为，一旦我们在受控的（甚至是人为的）条件下对模块进行了彻底的测试、我们就能够更好的了解模块在广阔的世界上将怎样反应。针对合约进行测试 我们喜欢把单元测试视为针对合约的测试，我们想要编写测试用例，确保给定的单元遵守其合约。这将告诉我们两件事：代码是否符合合约，以及合约的含义是否与我那么所认为的儿一样。我们想要通过广泛的测试用例与边界条件，测试模块是否实现了它允诺的功能。 为测试而设计 当你设计模块，甚或是单个例程时，你应该既设计其合约，也设计测试该合约的代码。通过设计能够通过测试，并履行其合约的代码，你可以仔细的考虑边界条件和其他非如此便不会发现的问题。构建测试窗口 我们可以提供模块的内部状态的各种视图，而又不使用调试器。 含有跟踪消息的日志文件就是这样一种机制，日志消息的格式应该正规，一致，你也许想要自动解析它们，以推断程序所用的处理时间或逻辑路径，格式糟糕或不一致的诊断信息就像是一堆呕吐物——它们既难以阅读，也无法解析。 了解运行中的代码的内部状况的另一种机制是“热键”序列，按下特定的键组合，就会弹出一个诊断控制窗口，显示状态消息等信息，你通常不会想把这样的热键透露给最终用户，但这对于客户服务人员却非常方便。测试文化 尽管有着黑客的名声，Perl社群对单元测试和回归测试非常认真。Perl的标准模块安装过程支持回归测试： %make test 在这方面Perl自身并无任何神奇之处，Perl使得比较和分析测试结果变得更为容易，以确保顺应性（compliance）——测试被放在特定的地方，并且有着某种预期的输出。测试时技术，但更是文化；不管所用语言是什么，我们都可以让这样的测试文化慢慢浸入项目中。测试你的软件，否则你的用户就得测试。邪恶的向导 如果你真的使用向导，却不理解它制作出的所有代码，你就无法理解你自己的应用。你没有能力维护它，而且在调试时会遇到很大的困难。 不要使用你不理解的向导代码。 他们说，开发者每天都在依赖他们不完全理解的事物——集成电路的量子力学、处理器的中断结构，用于调度进程的算法，系统提供的库里的代码，等等。我们同意。而且如果向导只是开发者可以依赖的一组库调用火标准的操作系统服务，我们队向导的感觉也是一样的。但它们不是，向导生成的代码变成了应用的完整组成部分。向导代码并没有被分解出来，放在整洁的接口后面——它一行一行的与joe编写的功能交织在一起。最后，它不再是向导的代码，而是开始变成joe的代码。没有人应该制作他们不完全理解的代码。解开不可能解开的谜题自由度 问题并不在于你是在盒子里面思考，还是在盒子外面思考，而在于找到盒子——确定真正的约束。 如果问题是“不可能解决的”这正是你退回一步，问问自己以下问题的时候： 有更容易的方法吗？ 你是在设法解决真正的问题，还是被外围的技术问题转移了注意力？ 这件事情为什么是一个问题？ 是什么使它如此难以解决？ 它必须以这种方式完成吗？ 它真的必须完成吗？等你准备好 有时犹豫的人会得以保全 了不起的表演者有一个共同的特征：他们知道何时开始，何时等待。跳水运动员站在高台上，等待完美的时刻起跳。指挥站在乐队前面，手臂举起，直到她感觉到某个瞬间适于开始演奏。 倾听反复出现的疑惑——等你准备好再开始 当你面对一件任务时，如果你反复感觉到疑虑，或是体验到某种勉强，要注意它。你可能无法准确的指出问题所在，但给它时间，你的疑惑很可能就会结晶成某种更坚实的东西，某种你可以处理的东西。软件开发仍然不是科学，让你的直觉为你的表演做出贡献。是良好的判断，还是拖延 当你做出决定，把构建原型当做调查你的不适的一种方法时，一定要记住你为何这样做，你最不想看到的事情就是，你花了几个星期认真的进行开发，然后才想起你一开始知识要写一个原型。规范陷阱 编写规范是一项重要职责 有些事情“做”胜于“描述” 随着规范越来越详细，你得到的回报会递减，甚至会是负回报。 你越是把规范当做安乐毯，不让开发者进入可怕的编码世界，进入编码阶段就越困难。不要掉进这样的规范螺旋中：在某个时刻，你需要开始编码！如果你发现你的团队全部包裹在暖和、舒适的规范中，把他们赶出来，考虑构建原型，或是考虑曳光弹开发。圆圈与箭头 计算技术从不缺少意图使程序设计更像工程的方法。 有一些开发者盲目的追求新方法会一无所获。 不要做形式方法的奴隶是否使用形式方法 绝对应该。但始终要记住，形式开发方法只是工具箱里的有一种工具。如果在仔细分析之后，你觉得需要使用形式方法，那就采用它——但要记住谁是主人，不要变成方法学的奴隶。 注重实效的程序员批判的看待方法学，并从各种方法学中提取精华，融合成每个月都在变得更好的一套工作习惯。这至关重要。你应该不断努力提炼和改善你的开发过程，绝不要把方法学的呆板限制当做你的世界的边界。 昂贵的工具比一定能制作出更好的设计 形式方法在开发中肯定有其位置。但是，如果你遇到一个项目，其哲学是：“类图就是应用，其余的只是机械的编码”，你知道，你看到的是一个浸满水的项目团队和一个路途遥远的家。第八章 注重实效的项目注重实效的团队不要留破窗户团队作为一个整体，不应该容忍破窗户，团队必须为产品的质量负责。在有些团队方法学中有质量官员——团队会把保证产品质量的责任委派给他。这显然是荒谬的：责任只可能源于全体团队成员都做出自己的贡献。煮青蛙 确保每个人都主动的监视环境的变化。对新需求进行持续的度量，团队无需拒绝无法控制的变化——你只需注意到它们正在发生。否则，你就会置身于热水中。交流 显然，团队中的开发者必须相互交谈。人们很容易忘记，团队本身也存在于更大的组织中，团队作为实体需要同外界明晰的交流。 对外界而言，看上去沉闷寡言的项目团队是最糟糕的团队，它们文档混乱：没有统一的术语。 有一个简单的营销诀窍，能帮助团队作为整体与外界交流：创立品牌。当你启动项目是，给它取一个名字，最好是不寻常的名字。它能给你的团队一个用于建设的身份标识，并给外界某种难忘的、可以与你们的工作相关联的东西。不要重复你自己 有些团队指定某个成员的担任项目资料管理员，负责协调文档和代码仓库。其他团队成员在查找资料时，可以首先找这个人。通过阅读正在处理的材料，好的资料管理员还能发现正在迫近的重复。当项目太大时，可以指定多人负责各个方面。正交性 这里有一个隐含的层级关系——按照对你的授权，你越接近用户，级别就越高。 认为项目的各种活动——分析、设计、编码、测试——会孤立地发生，这是一个错误。它们不会孤立地发生。它们是看待同一问题的不同方式，人为的分隔它们会带来许多麻烦。离代码的用户有两、三层远的程序员不大可能注意到他们的工作的应用语境。他们将无法做出有见识的决策。 围绕功能，而不是工作职务进行组织 我们喜欢按照功能划分团队。把你的人划分成小团队。分别负责最终系统的特定方面的功能。让各团队按照各人的能力，在内部自行进行组织。每个团队都按照他们约定的承诺，对项目中的其他团队负责。承诺的确切内容随项目而变化，团队间的人员分配也是如此。这种分组方式能够极大的减少各个开发者的工作之间的相互影响、缩短时间标度、提高质量、并减少缺陷的数目。但是，只有在项目拥有负责的开发者、以及强有力的项目管理时，这种途径才有效。一个项目至少需要两个“头”——一个主管技术，一个主管行政。自动化 自动化是每个项目团队的必要组成部分。为了确保事情得以自动化，指定一个或多个团队成员担任工具构建员，构造和部署项目中的苦差事自动化的工具，让它们制作makefile、shell脚本、编辑器模板，使用程序，等等。知道何时停止绘画 要记住，团队是由个体组成的，让每个成员都能以他们自己的方式闪亮。给他们足够的空间、以支持他们，并确保项目的交付能够符合需求。然后，要像“足够好的软件”中画家一样，抵抗不断画下去的诱惑。无处不在的自动化 文明通过增加我们不假思索就能完成的重要操作的数目而取得进步 无论是构建和发布流程、是书面的代码复查工作、还是其他任何在项目中反复出现的任务，都必须是自动的。我们也许必须在一开始就构建启动器和喷油器，但它们一旦完成、我们从此只需转动钥匙就可以了。一切都要自动化 Shell脚本或批处理文件能以相同的次序、反复执行同样的指令。它们能被置于源码的控制之下，你因而也可以检查流程的修改历史。 另一个特别受欢迎的自动化工具是cron（或Windows NT上的at）。它允许我们安排无人照管的任务周期性的运行——通常是在午夜。使用cron，我们可以自动安排备份、夜间构建、网站维护、以及其他任何可以无人照管的完成的事情。项目编译 我们通常通过makefile编译项目、即使是在使用IDE环境时。使用makefile有若干好处。它是校本化，自动化的流程。我们可以增加挂钩，让其为我们生成代码，并自动运行回归测试。回归测试 你还可以让makefile为你运行回归测试，或是针对单个模块，或是针对整个子系统。构建自动化 构建是这样一个过程：取一个空目录（和一个已知的编译环境），从头开始构建项目，产生所有你希望产生的，最终交付的东西。在典型情况下，项目构建将包括以下几个步骤： 从仓库中签出源码 从头开始构建项目，在典型情况下是从顶层的makefile开始，每次构建都会标注某种形式的发布或版本号，或是日期戳。 创建可分发映像。这个过程可能需要确定文件所有权和权限，并严格按照发运时所需的格式，产生所有的例子、文档、README文件，以及将随同产品发运的任何东西。 运行规定的测试（make test）。如果你没有定期运行测试，你可能会发现，应用因为3个月前做出的代码改动而失败，但愿你有足够的好运气找到它。最终构建 我们喜欢使用一个单独的make目标（比如make final）,一次完成所有这些参数设置。 要记住，如果产品的编译方式与先前的版本不同，你必须针对这个版本再次进行所有测试。鞋匠的孩子 我们有制作更好的工具所需的所有原材料，我们有cron，在Windows和Unix平台上，我们都有make，我们还有Perl和其他一些高级脚本语言，可用于快速开发自制的工具、网页生成器、代码生成器、测试装备、等等。 让计算机去做重复，庸常的事情——它会做得比我们更好，我们有更重要、更困难的事情要做。无情的测试 注重实效的程序员知道，现在就要找到我们的bug，以免以后经受由别人找到我们的bug所带来的羞耻。 早测试，常测试，自动测试。 bug被发现得越早，进行修补的成本就越低。事实上，好的项目拥有的测试代码可能比产品代码还要多。编写这些测试代码所花的时间是值得的。长远来看，它最后会便宜得多，而你实际上有希望制作出接近零缺陷的产品。 此外，你通过了测试将给你高度的自信：一段代码已经“完成”了 要到通过全部测试，编码才算完成。单元测试 单元测试是对某个模块进行演练的代码。集成测试 集成测试说明组成项目的主要子系统能工作，并且能很好的协同。验证和校验 一旦你有了可执行的用户界面或原型，你需要回答一个最重要的问题：用户告诉了你他们需要什么，但那是他们需要的吗？ 没有bug、但回答的问题本身是错误的，这样的系统不会太有用，要注意用户的访问模式、以及这些模式与开发者所用的测试数据的不同。性能测试 软件是否能满足现实世界的条件下的性能需求——预期的用户数、连接数、或每秒事物数，它可以伸缩吗？可用性测试 它是由真正的用户、在真实的环境条件下进行的。回归测试 回归测试把当前测试的输出与先前的值进行对比。我们可以确定我们今天对bug的修正没有破坏昨天可以工作的代码。 我们到目前为止提到过的所有测试都可作为回归测试进行，确保我们在开发新代码时没有损失任何领地。对测试进行测试 通过“蓄意破坏”测试你的测试 测试状态覆盖，而不是代码覆盖。何时进行测试 许多项目往往会把测试留到最后一分钟——最后期限马上就要来临时，我们需要比这早得多的开始测试，任何产品代码一旦存在，就需要进行测试。把网收紧 一个bug只抓一次 一旦测试人员找到了某个bug，这应该是测试人员最后一次发现这个bug。我们必须把时间花在编写新的代码——以及新的bug——上全部都是写 注重实效的程序员会把文档当作整个开发过程的完整组成部分加以接受。不进行重复劳动，不浪费时间，并且把文档放在手边——如果可能，就放在代码本身当中，文档的撰写就可以变得更容易。 把英语当作有一种编程语言 为项目制作的文档基本上有两种；内部文档和外部文档。内部文档包括源码注释、设计与测试文档，等等。外部文档是发布到外界的任何东西，比如用户手册。 把文档建在里面，不要拴在外面。代码中的注释 代码应该有注释，但太多的注释可能和太少一样糟。 注释源码给你了完美的机会，让你去把项目的那些难以描述、容易忘记，却又不能记载在别的任何地方的东西记载下载：工程上的权衡、为何要做出某些决策、放弃了哪些替代方案，等等。 下面是不应爱出现在源码注释中的一些内容： 文件中的代码导出的函数的列表。有些程序可以为你分析源码，使用它们，列表就保证是最新的。 修订历史。就是源码控制系统的用途所在，但是，在注释中包括最后更改日期和更改人的信息可能是有用的。 该文件使用的其他文件的列表。使用自动工具可以更准确的确定这些信息。 文件名。在源文件里应该出现的最重要的信息之一是作者的姓名——不一定是最后编辑文件的人、而是文件的所有者。使责任和义务与源码联系起来，能够奇迹般的使人保持诚实。可执行文档 如果你的文档是作为带有标记（makeup）命令（例如，使用HTML、LaTeX或troff）的纯文档存储的，那么你可以使用像Perl这样的工具自动提取schema，并重新对其进行格式化。标记语言 现在许多技术作者使用了DocBook来定义他们的文档，DocBook是一种基于SGML的标记语言，它仔细的标识了文档中的每一个组成成分，通过DSSSL处理器，文档可绘制成任意多种不同格式、Linux文档项目使用了DocBook来以RTF、TEX、info、PostScript和HTML格式发布信息。 文档和代码是同一底层模型的不同视图，但视图是唯一应该不同的东西。不要让文档编程二等公民，被排除在项目主要工作流之外。对待文档要像代码一样用心，用户（还有后来的维护者）会为你唱赞歌的。极大的期望 在现实中，项目的成功是由它在多大程度上满足了用户的期望来衡量的。 温和的超出用户的期望。交流期望 用户在一开始就带着想要的东西来到你面前，那可能不完整，不一致，或是在技术上不可能做到。你的部分角色就是要就此进行交流：与你的用户一同工作，以使他们正确的理解你将要交付的产品，并且要在整个开发过程中进行这样的交流。绝不要忘了你的应用要解决的商业问题。额外的一英里 给用户的东西要比用户的期望多一点。给系统增加某种面向用户的特性所需的一点额外努力将一次又一次在商誉上带来回报。 随着项目的进展，听取你的用户的意见，了解什么特性会使他们真的高兴。你可以相对容易的增加、并让一般用户觉得很好的特性包括： 气球式帮助或工具提示帮助 快捷键 作为用户手册的补充材料的快速参考指南 彩色化 日志文件分析器 自动化安装 用于检查系统完整性的工具 运行系统的多个版本、以进行培训的能力 为他们的机构定制的splash屏幕（交互式软件显示的初始画面——译注）每一项特性都告诉你的用户，开发团队想要开发出了不起的系统，要用于实际的系统。只是要记住，不要因为增加这些新特性而破坏系统。傲慢与偏见 注重实效的程序员不会逃避责任。相反，我们乐于接受挑战，乐于使我们的专业知识广为人知。如果我们在负责一项设计，或是一段代码，我们是在做可以引以自豪的工作。 在你的作品上签名匿名（尤其是在大型项目中）可能会为邋遢、错误、懒惰和糟糕的代码提供繁殖地。你的签名应该被视为质量的保证。附录 两个世界级的程序员专业协会：Association for Computing Machinery(ACM)和IEEE Computer Society，我们建议所有的程序员都加入其中一个，或是两个都加入。期刊 IEEE Computer IEEE Software Communications of the ACM SIGPLAN Dr.Dobbs Journal The Perl Journal Software Development Magazine书籍分析与设计： Object_Oriented Software Construction,2nd Edition Design Patterns Analysis Patterns团队与项目： The Mythical Man Month Dynamics of Software Development Surviving Object-Oriented Project：A Manager’s GuideWeb： Slashdot。宣称是“痴迷者的新闻、重要的资料”。Slashdot是Linux社群的网络之家中的一个。除了定期更新Linux新闻之外，该网站还提供关于各种很棒的技术和影响开发者的问题的信息。 Cetus Links。关于面向对象话题的数千链接。 WiWiWikiWeb。Portland Pattern Repository和模式讨论，这不仅是一个很好的网站，其“对各种想法进行集体编辑”的做法也是一项有趣的试验。