ThoughtWorks chief scientist Martin Fowler pointed out that there is a common argument of software development projects, namely "take the time to improve software quality, or focus on publishing more valuable function?" He said, "provide the functionality of pressure often dominated the discussion, leading to many developers complain that they do not have time to study architecture and code quality. " So, Martin recently in his blog published an article entitled "High-quality software worth so much it cost? " The article, to discuss this.
Typically, such a rhetorical question the answer is clearly no. However, Martin explained further subvert the next question itself, the problem assumes a common trade-off between quality and cost, in his view, this trade-off does not apply to software - "in fact produce high-quality software lower cost. "
This statement is to subvert your cognitive? People are used to trade-off between quality and cost, "what you pay for" is not unreasonable. Of course, Martin admitted that in most cases, this assumption is correct, higher quality will cost more. But he stressed that this is not an absolute rule.
Software Quality means a lot
Martin First "software quality" made the definition. There are many ways you can cover included: a clear user interface? Software reliable enough? Reasonable structure, clear it?
Users can determine whether the user interface good; executives can determine whether the software work more efficiently; consumers will notice defects in the system, especially when the software fails. But the user may not understand the software architecture - this is one of the quality criteria for software developers.
Therefore, this article will software quality attributes divided into external (such as UI and defects) and internal (architecture). The difference is that users and consumers can see the reason for external software products with high quality, but it is difficult to distinguish the level of interior quality.
Internal quality seemingly irrelevant to the user
Users can determine whether they want to pay more for a better user interface, but for internal modular structure difficult to judge. Imagine, if there are two nearly identical applications sell a $ 600, another for $ 10, the only difference is that the latter source neat and orderly while the former is more confusing. This does not affect the normal operation of the program, customers why spend $ 400 to buy the latter? So why software developers to spend time and effort to improve the internal quality of the work?
This leads to Martin in "Technical debt" ( Technical Debt Total concept) of. Residual item (cruft) difficult to clean up because the code is the culprit of the chaos caused by the accumulation of technical debt, additional efforts to increase the pay of the new features is the interest on the debt.
If the module structure clear enough, assuming add a new function requires four days, but because of confused logic or code data difficult to understand regulatory issues and so on, this work may be extended to six days.
These not only tedious part will be more time-consuming and energy developers, but also increased the likelihood of errors, then the future will need to cost more to repair.
Seen in this light, in fact, critical to the quality of internal users. Because better internal quality makes adding new features faster, easier, and less costly.
Affect the internal quality of
Martin said, "The basic role of internal quality is to reduce the cost of future change. But to write good software requires extra effort, which will have some costs in the short term." To this end, he provided two charts to visualize the way to present the effects of internal quality.
The figure is a case where poor quality of the internal software. It can be seen in the initial period of time, work progressed very quickly, but over time, become increasingly difficult to add new features. This is the plight of most of the software work.
Focus on high-quality interior is likely to cause a decline in productivity, developers can easily build new features take advantage of the previous work. This goal requires a skilled, well-trained team to achieve.
After coupled with high internal quality of the curve, some of the subtleties emerged: early low internal quality than the high internal quality software more productive, in the meantime, there is some trade-off between quality and cost. The question is, how long it can last?
Martin 综合参考了一些熟练开发者的意见，发现质量差的代码会在几周内显著降低生产速度，拥有高内部质量的软件随后远远反超。因此，从长远看来，不必太费心思在质量与成本之间权衡。
即便最好的团队也会产生垃圾
即使是最优秀的团队也会在工作时不可避免地产生一些无用且琐碎的东西（cruft）。
许多人将构建软件比作建造摩天大楼，想想为什么高级程序员被称为“架构师”？但软件构建于物理世界未知的不确定世界中，软件开发的构建模块——语言、库和平台——每隔几年就会发生重大变化。鉴于这种程度的变化，软件项目总是创造出新颖的东西。Martin 说他常常听到团队只有在花了一年左右的时间构建它之后，才能真正理解软件的架构。即使是最好的团队也会在他们的软件中肆意妄为。
不同的是，好的团队即使创造了垃圾，也能及时清理掉它们，他们可以继续快速添加功能。此外，他们还会花时间创建自动化测试，也经常进行重构，以便快速解决问题、清理残余。
Martin 用清理厨房来比喻这项工作：做饭时如果不快速清理台面污渍，之后更难去除，所有肮脏的东西会妨碍烹饪下一道菜。
高质量的软件生产成本更低
总结一下：
- 忽视内部质量会导致 cruft 快速产生
- 这将进一步延缓功能开发
- 即使是一个伟大的团队也会产生这样的问题，但通过保持内部质量，可以控制它
- 高内部质量使团队能够以更少的工作量、时间和成本开发新功能
一些开发团队向 Martin 诉苦：“管理层阻碍我们写出质量好的代码，因为它需要花费太长时间”。对此 Martin 再次呼吁，高内部质量实际上降低了未来成本，了解内部质量与成本之间的关系对于以最高效率开发软件来说至关重要。