本文共 2075 字,大约阅读时间需要 6 分钟。
ThoughtWorks 首席科学家 Martin Fowler 指出,软件开发项目中存在一种常见争论,即“花时间提高软件质量,还是专注于发布更有价值的功能?”他认为“提供功能的压力常常主导着讨论,导致许多开发人员抱怨他们没有时间研究架构和代码质量”。于是,Martin 近日在个人博客发布了一篇名为的文章,就此展开讨论。
通常,这样的反问句答案显然是否定的。不过,Martin 接下来的阐述进一步颠覆了问题本身,这个问题假定了质量和成本之间的共同权衡,可在他看来,这种权衡并不适用于软件——“高质量的软件实际上生产成本更低”。
这种说法是否颠覆了你的认知?人们习惯于在质量和成本之间进行权衡,“一分钱一分货”不无道理。当然,Martin 承认该假设在大多数情况下是正确的,更高的质量会花费更多。但他强调这并非一个绝对规则。
软件质量意味诸多
Martin 首先对“软件质量”做出了界定。有很多方面可以囊括在内:用户界面清晰吗?软件足够可靠吗?架构合理、明确吗?
用户可以判断用户界面是否良好;高管可以判断软件是否使工作更高效;消费者会注意到系统缺陷,特别是当软件出故障时。但用户可能无法体会软件架构——这对开发者来说是软件质量的判定标准之一。
所以,这篇文章将软件质量属性划分为外部(例如 UI 和缺陷)和内部(架构)。区别在于,用户和消费者可以看到软件产品具有高外部质量的原因,却难以分辨出内部质量的高低。
内部质量看似对用户无关紧要
用户可以判断他们是否想要支付更多费用以获取更好的用户界面,但对于内部模块化结构难以做出判断。试想一下,如果有两个近乎完全相同的应用程序,一个卖 6 美元,另一个售价 10 美元,区别仅仅在于后者的源码整齐有序而前者较为混乱。这并不影响程序正常运行,客户为何要多花 4 美元购买后者?既然如此,为什么软件开发人员还要花时间和精力来提高工作的内部质量?
Martin 在此引出了“技术债务”()的概念。由于代码混乱而造成的难以清理的残余项(cruft)便是积累技术债务的罪魁祸首,为增加新功能所付出的额外努力则是债务利息。
如果模块结构足够清晰,假设添加一个新功能需要四天时间,但由于逻辑混乱或数据难以理解等代码规范问题,这一工作可能将会被延长至六天。
这些繁琐的部分不仅会更加耗费开发人员的时间和精力,也加大了出错的可能性,那么以后将需要花费更多成本来进行修补。
由此看来,内部质量实际上对用户来说也至关重要。因为更好的内部质量使得添加新功能更快、更容易,成本也更低。
内部质量的影响
Martin 表示,“内部质量的基本作用是降低未来变革的成本。但是编写好的软件需要额外的努力,这在短期内会产生一些成本”。为此,他提供了两张图表,以可视化的方式来呈现将内部质量的影响。
上图是软件内部质量较差的情况。可以看到,在最初一段时间,工作进展很快,但随着时间的推移,添加新功能变得愈发困难。这也是大多数软件工作的境况。
专注于高内部质量很可能造成生产力下降,但开发人员可以通过利用先前的工作轻松构建新功能。这一目标需要一支技术精湛,训练有素的团队来实现。
加上高内部质量的曲线之后,一些微妙之处显现出来:前期低内部质量比高内部质量的软件更具有生产力,在此期间,质量和成本之间存在某种权衡关系。问题是,它能持续多久?
Martin 综合参考了一些熟练开发者的意见,发现质量差的代码会在几周内显著降低生产速度,拥有高内部质量的软件随后远远反超。因此,从长远看来,不必太费心思在质量与成本之间权衡。
即便最好的团队也会产生垃圾
即使是最优秀的团队也会在工作时不可避免地产生一些无用且琐碎的东西(cruft)。
许多人将构建软件比作建造摩天大楼,想想为什么高级程序员被称为“架构师”?但软件构建于物理世界未知的不确定世界中,软件开发的构建模块——语言、库和平台——每隔几年就会发生重大变化。鉴于这种程度的变化,软件项目总是创造出新颖的东西。Martin 说他常常听到团队只有在花了一年左右的时间构建它之后,才能真正理解软件的架构。即使是最好的团队也会在他们的软件中肆意妄为。
不同的是,好的团队即使创造了垃圾,也能及时清理掉它们,他们可以继续快速添加功能。此外,他们还会花时间创建自动化测试,也经常进行重构,以便快速解决问题、清理残余。
Martin 用清理厨房来比喻这项工作:做饭时如果不快速清理台面污渍,之后更难去除,所有肮脏的东西会妨碍烹饪下一道菜。
高质量的软件生产成本更低
总结一下:
一些开发团队向 Martin 诉苦:“管理层阻碍我们写出质量好的代码,因为它需要花费太长时间”。对此 Martin 再次呼吁,高内部质量实际上降低了未来成本,了解内部质量与成本之间的关系对于以最高效率开发软件来说至关重要。
原文地址:
转载地址:http://vizhj.baihongyu.com/