所以如果某个问题能够尽 量的在第 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 就 是个不错的软件管理方法。它主张在一个开发过程里,开发人 员准时地提交