6．分层测试

　　不可否认，写出好的测试代码的确是个很大的挑战。例如，代码写好后，对它们进行单元测试就很困难，单元测试不可能测试到程序运行的方方面面。功能性（质量保证）测试对程序测试相当有效，不过它通常运行慢，对问题发生的原因给出的信息往往很不够。

　　因此，你不得不对测试进行拆分以克服这种情况。如果简单的基础测试都无法通过，那么运行更大的测试显然是无意义的。分层测试的目的就是让测试从易到难。

　　——第0层：开发人员在自己本地环境中进行的单元测试。

　　——第1层：构建服务器上的单元测试，（几乎每个）代码提交之后开始。

　　——第2.1层：集成测试，在几个模块整合到一起之后进行的测试。（用真正的模块代替掉原先的模拟模块。例如，使用真正的XML解析器换掉原先的那个替代品）

　　——第2.2层：集成测试，通过入口访问系统（接口、磁盘等等，到这儿，你可以测试访问真正的系统）

　　——第3层：功能性测试，测试程序可见的部分。（用户能够看到的实实在在的功能，当然，这一层还不够）

　　——第4层：性能测试。

　　——第5层：客户体验。（OK，这并不是一个测试层，但是这个环节的确会发现不少意料之外的bug）

　　这个方法的理念是同一个bug决不会再次重现。因而，对于每个你发现的bug，你都应该创建测试用例以保证它不会重现。这个测试可能是单元测试（这样最好），也有可能是集成测试。

　　总之，问题发现得越早越好，这意味着我们可以更早修复它。所以如果某个问题能够尽量的在第0层发现，我们就不要让它等到第3层才发现。随着测试代码的增加，代码质量也会越来越健壮。

　　7．严格限制使用编程语言的数目

　　如果你无论完成什么任务都为它选择最好的工具，那么当你的任务越来越多，你采用的工具也越来越多，这可不是什么好事。如果你总是为短期的目标选择最便捷的方 法，系统的复杂性会随之增加。所以，有时候，你不一定要选择最好的工具。在同一个团队里，最好只使用一门语言，尽量不要超过两种语言，否则单单培训开发人 员的成本就不少。例如，Ruby on Rails就是个很好的工具，但是它涉及到不止一门语言和技术。在用它的某种技术开发网站之前，必须要考虑所有的花费。如果你们的主要活动就是开发网站，那么这条规则对你并不适用，因为在这种情况下，Ruby很可能变成你们项目组的主要语言了。

　　我的观点是，选择有限数目的编程语言。当然，你也必须确保这种技术对你们公司有用。例如，有必要用四种网络服务框架吗？没必要，一种足矣。

　　8．紧跟技术的发展和革新，不过这个比较困难

　　我们很容易碰到这种情况，为了实现某个功能你必须付出很大的努力，但是实际上已经有工具可以做到这点，但是我们却不知道。如果我们关注着技术的发展，包括开 发框架的革新，方法的提出等等，就可以避免这种情况的出现。幸亏有这种关注的习惯，我发现了现在我用得几乎所有的工具：Eclipse, Maven, Tomcat, Apache, LDAP, CruiseControl, TestNG, Python,等等。它们中大多数工具都可以为我节省很多工作。有的项目本来需要几个月的开发时间，结果缩短到几周。

　　比较困难的就是如何去选择工具（要花费很多时间去选择工具），而且还得避免你的工作团队同时使用太多的技术。有个建议，当使用某项技术还在实验之中的时候，我们最好不要用，最好等到它已经实现了，有成熟的产品了。

　　另外一个挑战就是评估、选择新的技术。如果要对旗鼓相当、都是很有竞争力的框架进行评估，并从中选择一两个的话，这个难度一般也很大。

　　9．为了保持效率，最好不要被频繁地打断

　　在解决复杂的问题的，开发人员一般需要7到15分钟进入高效的状态。如果从一个活动转到另外一个活动（电话，电子邮件等等）就会打断开发人员的进程。例如，如果一个团队的开发人员每20分钟就有个技术服务的电话骚扰他，哦，这完全是灾难性的。因此，我们不应该允许用户直接打开发人员的电话。

　　取而代之，我们应该建立一个工具收集问题、bug、需求等等来完成这些工作，这样开发人员就可以专心致志地忙他的本职工作。这样的工具很多，包括Mantis 和Jira。

　　另外一点，记住，开发人员并不是机器，他是人。为什么项目经理要求开发人员记住——存储——他们的要求？难道他就不能把他的要求写下来吗？

　　10．定义好构架与编码同等重要

　　在没有构架的基础上进行编码如同在没有灯光的夜晚驾车。你有可能达到你的目的地，但是行程很慢，也很危险。如果有构架师，他就会经常审核原始的产品，预测可能出现的问题。缺少了构架师，系统能难有很好的框架，如果每次加进一个新功能，系统复杂度就会大大增加。

　　即使编码没问题，据我所见到的走捷径的项目，基本上都多多少少存在些问题。这就是产品构架师应该对产品的框架有一个全局的概念的重要原因。

　　11．开发人员和产品使用者考虑的重点不同

　　开发人员总是对“有趣”的任务感兴趣，而产品的使用者总是希望产品的功能对他的客户有用。开发过程中，应该尽量地做到，至少应该使这两个目标比较接近：让开发人员解决比较无趣的问题时也让他很高兴。

　　据我所看到，Scrum就 是个不错的软件管理方法。它主张在一个开发过程里，开发人员准时地提交结果，这时，开发人员的自尊心就会成为一个强大的动力。当然，当项目经理提出某一个 用处并不大的需求时，如果开发人员很难准时提交结果，也就是说，这个功能需求在实现上困难很大，但是又没有很大的用处，这个时候项目经理应该在提需求之前 三思，是否有必要提这个需求。当然，有时间可以研究一下，Scrum方法的确相当不错。

　　12．代码规约很高效，必须强制执行

　　代码规约把开发人员从理解代码的格式上解放出来，让他们有更多的时间去理解代码的核心含义。在我工作的团队里，我们建立了自己的规约，包括代码存放的目录，文件名，还有代码本身（类的名字、方法、变量等等）。

　　某些SVN插件甚至可以禁止不符合代码规约的代码提交。呵呵，不错！

　　● 将影响效率的问题消灭在萌芽状态

　　大多数开发过程和方法的目的就是为了解决效率问题。本文指出了开发过程中的几个我观察到的并牢记在心的问题。希望你能够从我的经验中学到些东西，同时，世上并没有那种解决方案是银弹，我建议看看Scrum，因为它的确提高了开发中各个环节的效率。