Part 3 第十五章 软件系统弃用 Deprecation

概述

本章探讨了软件系统弃用（Deprecation）的必要性、挑战和最佳实践。弃用是指有计划地迁移并最终移除过时的系统。尽管软件本身不会像物理资产那样老化，但技术环境的变化（如新技术、新库、新语言等）会使现有系统逐渐变得过时。过时的系统需要持续维护，且随着与周边生态系统的脱节，维护成本会越来越高。因此，有计划地弃用过时系统可以减少资源浪费，提高开发效率。然而，实际操作中，弃用并非易事，需要克服技术、情感和组织上的多重障碍。

主要内容

1. 为什么需要弃用？

代码是负债而非资产：代码本身具有成本，包括开发和维护成本。随着时间推移，维护过时系统的成本会显著增加。
过时系统的定义：系统是否过时取决于其是否被替代系统取代，而非仅仅因为其老旧。如果存在功能相当或更好的替代方案，那么保留过时系统将增加不必要的复杂性和维护成本。

2. 为什么弃用如此困难？

用户依赖：根据 Hyrum’s Law，用户可能以意想不到的方式依赖系统，这使得弃用变得复杂。
情感因素：工程师可能对旧系统有情感依赖，尤其是他们参与创建的系统。
政治和资源问题：弃用需要投入资源，而这些资源可能被优先分配给新功能开发，导致弃用工作难以推进。

3. 弃用的类型

建议性弃用（Advisory Deprecation）：没有明确的时间表，依赖用户自行迁移到新系统。这种方式适合鼓励早期用户尝试新系统，但通常不足以推动大规模迁移。
强制性弃用（Compulsory Deprecation）：有明确的移除时间表，通常需要专门的团队负责推动用户迁移，并可能涉及强制措施以确保按时完成。

4. 弃用过程中的设计考虑

设计时考虑弃用：在系统设计阶段就考虑未来如何弃用，可以简化后续的移除过程。例如，选择易于替换的编程语言或架构。
增量弃用：通过逐步替换系统的一部分，而不是完全替换整个系统，可以降低风险并提供即时收益。

5. 弃用警告

标记过时系统：通过代码注释或文档标记系统为过时，以警告用户并鼓励他们迁移到新系统。
避免“警告疲劳”：过多的弃用警告可能导致用户忽视它们，因此需要谨慎使用。

总结

弃用是软件工程中的一个重要环节，有助于减少系统的复杂性和维护成本。尽管弃用过程充满挑战，但通过有计划的设计和执行，可以显著降低其难度。Google 正在不断学习如何更有效地弃用和移除过时的系统。

精彩语录

1.“代码是负债，而不是资产。”
“Code is a liability, not an asset.”
解释：代码本身具有成本，包括开发和维护成本。因此，减少不必要的代码可以降低系统的总体负担。
2.“过时系统的存在并不总是因为它们老旧，而是因为它们被替代系统取代。”
“Deprecation is best suited for systems that are demonstrably obsolete and a replacement exists that provides comparable functionality.”
解释：系统的过时性取决于其是否被更好的替代方案取代，而非仅仅因为其使用时间长。
3.“用户可能以意想不到的方式依赖系统，这使得弃用变得复杂。”
“The more users of a system, the higher the probability that users are using it in unexpected and unforeseen ways.”
解释：Hyrum’s Law 指出，用户可能以开发者未曾预料的方式使用系统，这增加了弃用的难度。
4.“增量弃用可以将复杂问题分解为更小、更易管理的部分。”
“Incremental deprecation efforts accomplished by in-place refactoring can keep existing systems running while making it easier to deliver value to users.”
解释：通过逐步替换系统的一部分，而不是完全替换整个系统，可以降低弃用的复杂性和风险。
5.“强制性弃用需要明确的时间表和执行机制。”
“For compulsory deprecation to actually work, its schedule needs to have an enforcement mechanism.”
解释：强制性弃用需要明确的移除时间表，并且需要有机制确保用户按时迁移到新系统。