Bert Hubert · 2025-01-22

长期软件开发的思考与建议

摘要

本文基于作者为荷兰选举委员会开发开源投票统计软件 Abacus 的实践经验，系统性地总结了长期软件开发的核心理念与方法。作者指出，与现今通过 CI/CD 持续迭代的软件服务不同，核电站、选举系统、心脏起搏器等领域的软件需要在未来数十年内保持稳定运行。文章从 Mastodon 社区收集了大量反馈，提炼出关于依赖管理、复杂性控制、测试策略、文档规范、团队建设等15个方面的实用建议，为需要长期维护的软件项目提供了全面的指导框架。

内容框架与概述

文章以作者受荷兰选举委员会邀请反思其开源投票统计软件为切入点，指出了长期软件开发与现代敏捷开发模式的本质差异。现今大多数软件作为服务提供，可以通过持续部署和持续集成来修复问题，但某些关键领域如核电站控制系统、选举软件、医疗设备等，要求软件在几十年内保持稳定运行，任何变更都需要提前规划和公告。

作者在 Mastodon 社区征求意见后，收集了大量来自实践者的反馈，将这些经验整理成系统性的建议。文章的核心论点是：长期软件开发需要与传统开发模式完全不同的思维方式和技术选择。作者特别强调了依赖管理的重要性，将软件依赖分为四个层次——基础编程语言、紧密耦合的框架、数据库和可替换的辅助库，并指出越底层的依赖选择越关键。

在复杂性管理方面，作者提出"复杂性是软件开发的最终敌人"这一核心观点，通过图表展示了代码复杂性与代码量之间的关系，强调必须在早期主动进行重构和简化。文章还详细讨论了测试的价值、文档的重要性、团队管理的策略以及开源的优势，并推荐了《编程实践》《人月神话》《软件设计哲学》等经典著作，最后引用了莱曼的软件进化法则来支持其观点。

核心概念及解读

依赖层次结构：软件依赖可分为四个层级——基础编程语言（最底层，最难更换）、紧密耦合的框架（深度集成，更换成本高）、数据库（数据存储核心，迁移复杂）和可替换的辅助库（最上层，相对容易替换）。长期软件开发必须格外关注底层依赖的选择，因为技术质量、使用者基数、维护状况、资金来源等因素都会影响依赖的长期稳定性。依赖可能随时间出现版本漂移、被废弃、甚至遭到劫持，因此建立定期健康检查机制至关重要。

复杂性管理：复杂性会随着代码量的增加而自然增长，如果缺乏主动管理，系统最终会变得无法维护。作者强调必须在开发早期就持续进行重构和简化，而不是推迟到"以后"。简单的代码虽然可能不够"聪明"或不够高效，但更容易理解、调试和维护。在长期项目中，为了避免过早优化是万恶之源，应该优先选择编写无趣但简单的代码，而不是追求高性能但复杂的解决方案。

Lindy 效应与技术选择：Lindy 效应指出，技术的预期寿命与其当前年龄成正比——一项技术已经存在的时间越长，它可能继续存在的时间也越长。这意味着在长期软件开发中，应该优先选择经过时间考验的技术，而不是被 LinkedIn 或社交媒体炒作的新技术。新技术的风险在于其长期价值尚未得到验证，可能在关键时刻失去支持或出现无法预见的问题。

测试的战略价值：测试不仅是质量保证手段，更是长期维护的安全网。当依赖频繁变化时，完善的测试套件可以确保系统仍能正常工作；当项目暂停后重新启动时，测试可以帮助新开发者快速理解系统行为；当需要重构或移除依赖时，测试提供了变更的信心。测试的价值在长期项目中会呈指数级增长。

文档与知识传承：长期软件开发必须重视特定文档的需求，包括架构设计文档、API 文档、运维手册等。代码注释应该解释"为什么"而不是"做什么"，提交信息应该记录变更的原因。团队还需要建立内部 wiki 或知识库，记录决策过程、架构演进和故障经验。这些文档在原始开发者离开后，成为知识传承的关键载体。