代码的价值第二部分 - 代码重用

感谢您对“代码的价值”第一部分的积极响应。接下来的两篇文章将更深入地探讨良好的代码重用如何解决代码折旧问题。代码重用有两个方面。本文讨论代码重用中的问题。第三部分（仍在编写中）讨论如何编写可重用代码。

引言

既然我们已经确定代码的价值会随着时间的推移而下降，那么让我们看看如何利用这些知识。解决这个问题的最佳方法是避免编写新代码，而是重用那些被设计成可重用的代码。在重用代码之前，您需要解决多个问题。

重用代码

购买或重用代码总是优于自己编写。在大多数情况下，考虑到良好代码开发的成本，为产品所需的一切编写代码是不切实际的。

代码重用的障碍

以下是代码重用的一般障碍：

1. 低估开发成本。
2. “非我发明”的心态。
3. 对没有增加价值的不安全感。
4. 组件评估过程、质量或文档方面的问题。

A. 低估开发成本

大多数开发人员在被问及编写特定组件需要多长时间时，会给出远低于最终成本的猜测性估算。

例如，假设您想为 Windows 窗体编写一个好的状态栏组件。成本是多少？大多数开发人员会估计这需要几天时间编写代码。但是组件的成本不仅仅是编码。它还包括需求分析、设计（内部代码 + 外部接口）、实际编码、单元测试覆盖率、错误修复、接口文档和长期维护。而这些仅仅是开发人员的任务，其他人员也参与了开发过程。这个组件将消耗质量保证、文档、产品管理和工程管理资源。所以，两天编码的估算远远不够。

大多数团队最常见的错误是只计算编码成本。了解如何计算代码的真实成本将对帮助您做出更好的决策大有裨益。

B. 和 C. “非我发明”的心态和不安全感

这是两个相关的问题。大多数开发人员认为他们的工作是编写代码，他们编写的代码量构成了他们评估的基础。需要告诉开发人员，他们的存在是为了创新性地解决问题。用更少的代码解决问题比几个月后用更多未经测试的代码解决相同的问题要好。“非我发明”需要作为公司文化的一部分来处理。大多数经理会赞扬那些连续加班三晚编写数千行代码以实现功能的程序员，但很少会认可那些通过购买或重用组件来实现功能的开发人员。毕竟，人们认为组件开发人员做了艰苦的工作。

如果你的公司文化奖励更多的编码工作，你总会有“非我发明”的问题。如果你的面试测试潜在开发人员的低级编码任务（例如，如何反转链表），而不是如何编写或使用可重用代码，那么你正在雇用优秀的编码员。

为了让重用发挥作用，你需要有一种专注于奖励重用的文化，并雇用了解重用价值的开发人员。你不能有一种让开发人员因为使用别人的代码而对没有增加价值感到不安全的文化。

如果您的重用程序失败了，请仔细审视您的文化。重用失败的主要原因在于开发文化，而不是任何技术原因。

D. 组件评估过程、质量或文档方面的问题

质量是大多数可重用组件的严重且真实的问题，不幸的是，没有神奇的门户可以记录各种问题的质量水平。（嘿，这是一个很棒的主意，但我们不要跑题。）唯一的方法是遵循纪律严明且严格的流程，以帮助您评估组件并解决质量和文档问题。

如何选择合适的可重用组件

这看起来更像一门艺术而非科学，但事实并非如此。在上面的例子中，选择将是不在状态栏组件的开发上花费时间。市场上有几十种状态栏组件可供选择，但您需要花费时间进行评估、质量保证和集成这些组件。

在选择合作伙伴之前，请选择您希望作为合作伙伴的公司类型。您需要确保该公司拥有：

• 良好的业绩记录。
• 良好的支持政策。
• 高质量代码的声誉。
• 访问源代码（至少通过托管）。

接下来是实际的组件评估部分。不要犯将此任务分配给初级开发人员的错误。您需要确保选择一个合作伙伴是一个严肃的选择，需要由高级开发人员处理。进行背景调查以了解其他人对该组件的评价总是有帮助的。与组件供应商的支持人员交谈可以让您了解其支持人员的技术专长。试用他们的示例并查看他们的界面设计将告诉您在组件设计过程中投入了多少心思。

一旦您缩小了列表，请让您的质量保证团队中的某人对其运行一些自动化测试。将组件视为未经测试的资源。如果组件对部署策略有影响，请衡量它并确保它可接受。

在集成第三方组件时，请务必使用抽象层来隔离您与任何更改。如果您决定明天使用新的状态栏，那么您应该进行的唯一更改是更改 *MyStatusBar* 类。抽象层可以保护您免受技术、业务需求以及其他不良事件（例如组件存在资源泄漏）引起的更改。

高级重用概念

重用代码不只是指重用组件。它可能意味着重用框架或应用程序。例如，如果您正在编写一个与某个硬件设备接口的基于网络的应用程序，您有三种主要选择：

1. 您可以编写一个 CGI 应用程序来完成所有工作。
2. 使用 PHP 库来处理模板、身份验证等，并专注于领域逻辑和使用所有库功能。
3. 将您的领域逻辑作为模块集成到 DotNetNuke 等网络门户中。

选择 3 具有最佳的重用能力，但您可能需要首先解决一些产品管理问题。选择 1 是一个糟糕的选择，您应该专注于您的业务逻辑和领域优势。选择 2 是一个合理的选择，但需要一些工作来使用库功能来实现模板、身份验证等。

将您的解决方案实现为需要 DotNetNuke、MS Office、Sharepoint 或 J2EE 应用程序服务器的模块，这会为您的应用程序增加一个额外的要求，但在大多数情况下，这可能是值得的。解决别人已经解决过的问题是没有意义的。重造轮子在 DotCom 时代并没有带来多少好处。

结论

避免代码折旧的唯一方法是重用，但您需要严格遵守纪律并遵循严格的流程。重用使您能够 *事半功倍*。