良好设计的商业案例

引言

在我看来，就成本而言，有 5 个主要的软件设计原则。我们作为软件开发人员和顾问都非常清楚，软件开发成本非常高昂。然而，考察已部署代码的成本是有益的。在这种背景下，编写糟糕的代码就是昂贵的代码。

五项设计原则

1. 可读性。难以阅读的代码维护成本很高。如果您雇佣了 5 名 Accenture 的开发人员，每小时 200 美元，他们需要花费两个月的时间来理解您的意大利面条式代码，这将花费您 336,000 美元。另一方面，如果您的代码直观，使用了易于识别的范例等，并且他们只花了一周时间来理解您的代码，那么成本将仅为 80,000 美元。更重要的是，不可读的代码随着时间的推移会变得越来越不可读。由于开发人员的流动率很高，这种成本是经常性的，并且会随着时间的推移而增长。
2. 可维护性/可扩展性。如果代码缺乏模块化，应用错误修复和修改现有功能将很困难，并可能引入新的错误。对于缺乏模块化功能而编写的代码，测试成本会显著提高，因为您必须格外小心，以确保在修改现有功能后没有破坏其他任何东西。作为框架编写的代码允许程序员轻松添加新功能，而无需修改生产中的代码。另一方面，如果不存在这种模块化，添加新功能就意味着必须在现有的代码库中找到一个可以添加新功能的地方，可能需要修改其他基本不相关的函数和类，当然，还可能冒着破坏不相关功能的风险。这种风险转化为显著增加的测试成本和潜在生产中断的成本。
3. 可重用性。如果侧重于解耦可重用代码并将其放入可在其他应用程序中使用的库中，那么未来新开发的成本将大大降低。
4. 性能。性能不佳的代码可能会导致生产停滞，从而导致利润损失。内部应用程序性能不佳会导致员工生产力下降。
5. 安全性。安全漏洞可能**非常**昂贵。诉讼、罚款和知识产权损失只是可能产生的成本中的一部分。

请注意，我并不是要在这方面做出哲学上的论证，认为这些是唯一的设b计原则。相反，我认为这些原则在考虑开发成本时至关重要。

细则

可读性、可维护性/可扩展性和可重用性是相辅相成的。然而，性能、安全性和前三个原则之间常常发生冲突。换句话说，使代码更具可读性、可维护性、可扩展性和可重用性通常会导致性能和/或安全性受到影响。使代码更安全通常会导致性能和前三个原则受到影响。这就是为什么良好设计很困难；开发人员必须考虑所有因素，并决定要在多大程度上牺牲安全性来换取一定程度的可维护性，或者要在多大程度上牺牲可维护性来换取性能。必须达成平衡。

太多人过度关注其中一个原则。例如，您见过多少应用程序安全性极高但运行速度极为缓慢？当然，它们无法被黑客攻击。但是，安全团队已经考虑了最不可能发生的情况，这导致用户（比如员工）损失了许多生产力工作时间。在成本效益分析中，这样做值得吗？

另一个例子是那些过度关注性能的人。使用具有出色范例的框架，或者构建具有良好模块化功能的应用程序可以大大降低成本——但这通常会以牺牲性能为代价。在我看来，性能与前三个原则同等重要。然而，在这里必须达成平衡，并且在需要程序员牺牲性能来换取可读性、可维护性和可重用性的每种情况下都必须进行成本效益分析。这要求程序员熟悉计算机的所有方面：从处理器、控制器和硬件架构到操作系统、编译器、中间语言编译和高级过程，包括第三方框架的使用。外部传输/接收、消息传递以及第三方依赖项如何处理数据（例如 SQL Server）也很重要。诚然，性能可能是良好设计中最难的部分（安全性不相上下或紧随其后），因为它需要开发人员最多的知识。即便如此，一个在选择性能和其他四个原则之间一贯做出不明智决定的开发人员，显然未能创造出最具成本效益的代码。

SOLID

在这个时代，当您提到“设计原则”时，许多人会想到 SOLID，所以我不得不添加一个相关部分。在我看来，SOLID 是一套用于实现目标的次要原则。它们不是主要原则，因为没有人会以任何一个为主要目标。例如，没有人说过“我写这个代码的唯一目的是依赖抽象而不是具体实现”。另一方面，许多人说过“我想让这段代码更具可读性，以降低未来的入职成本”。SOLID 也可以被描述为一个框架，可以帮助实现前面描述的前三个原则（可读性、可维护性/可扩展性、可重用性）。

历史

• 2018 年 11 月 21 日：V1