以生产力为导向的决策：原因，影响和局限

软件项目中有许多决策是出于生产力方面的考虑而决定的，尤其是在项目比较成功的情况下，市场发展了，与此同时领域知识和客户需求也变得愈发复杂。产品的目标范围很可能会发生无法预料的改变，而且需要更进一步按照用户的需求来定制。就像 Lispy 所特别指出的那样，很多团队通过“使出丑陋的招数”来快速适应新需求，“哄着客户高兴了，钱就滚滚而来”。他把这种对软件的质量的影响称为“成功之痛”。

Bob Martin 描述了这些影响，并且认为这种“快速而拙劣”的做法不可能长时间维持下去，因为它最终会不可避免地使项目进展速度变慢。

我最近刚见过一个客户，他们是一家成功的初创企业，一开始可以说是突飞猛进。他们的软件发展得飞快，不过从头到尾都是不择手段拼凑出来的。现在这个一团乱麻的软件让他们寸步难行。任务失败率很高，修改引起的非预期副作用很多，生产效率很低。

[……]“快速而拙劣”这个词是自相矛盾的，拙劣总是意味着慢。

常有人觉得不管怎样业务软件都会是一团糟，并以此来作为不择手段的正当理由，Bob Martin 非常不同意。他认为虽然业务规则有着“复杂、武断、不通用”的趋向，但代码与之相反，必须尽可能整洁：

要是再把业务规则的烂摊子丢进另一个烂摊子，你就更没办法理清它们了。要想从规则的乱麻中理出一个头绪，唯一的方法就是用最最清晰的代码来表达它们。

Roland Kaufmann 在 Martin 的文章后评论说，把生产力摆到首位的想法，其解释可以归结到“一个荒唐的内部收益率（IRR），令短期的节省比长期的收益更有利”。尤其有许多经理总是假定任何项目只要存续的时间够长，肯定免不了周期性地完全推倒，再重新设计和实现。其中一条评论还认为这种短视的、以生产力为导向的合理性，正是计算机科学专业的毕业生被责怪不会写软件的原因。

David Chisnell 说得没错，“计算机科学和软件工程是非常不同的两种训练”。后者“从工具和过程两个方面教授开发软件的方法”，而计算机科学课程只“简要地接触这些主题”，且计算机科学并不是“职业训练”。毕业生对许多语言走马观花，而得不到这些语言及相关工具的任何深入的知识。因此，他们很可能没法高效率地编码并遵守紧迫的期限。但正如一位博客作者所说的，“毕业生们的不称职谁都看得到”，但有些人“没什么大规模设计 / 架构的智慧”却大干快上，反倒并不会“因糟糕的设计决策令整个系统慢慢变得不可维护而遭受责难”，因为“他们初期的成功让管理层觉得最后的失败是非人力所能避免的。”

不过，Lispy 认为，生产力低下的计算机科学毕业生却具备一些技能，会随着项目的大小和复杂性的增长，而成为开发成功的关键。“增加数之不尽的特性，或者每张单子都要进行昂贵的定制工作”，这些都是“规模增长之大敌”，Lispy 认为，就算很努力而且运气很好，“没受过训练的野路子程序员”也只能把项目扛到某个程度，超过之后他们就会需要“帮助他们编写他们的工具的工具”。Lispy 相信计算机科学是提供这样的工具所必需的，因为那需要更深一个层面的理解才行。爱因斯坦曾说，“我们面对的重大问题无法在我们创造出这些问题的同一个思维层面上解决。”要解决现实的开发工作中所面对的问题，我们可能需要计算机科学的毕业生，虽然他们显然没法在现实世界中以生产力为导向的要求下编写代码。

查看英文原文： Decisions driven by productivity concerns: Reasons, implications and limitations