设计软件最重要的目标是可理解性？
内容提要
软件设计时最重要的是可理解性，被误解的软件会产生缺陷。要提高可理解性，可以使代码易于理解，添加注释和支持文档。这些方法可以帮助理解软件。
延伸解读
可理解性优先的实践意义
文章将可理解性置于安全性、性能和正确性之上，这并非否定后者的重要性，而是指出理解是达成这些目标的基础。如果开发者对代码存在误解，那么任何改动——无论是添加功能、修复缺陷还是优化性能——都可能引入新的问题。因此，在软件设计时优先考虑可理解性，实际上是一种风险控制策略，能减少因误解导致的缺陷和安全漏洞。
测试的局限与理解的必要性
文章强调测试无法弥补对软件理解的不足，原因有二：测试只能覆盖有限的代码路径；若开发者自身不理解软件，也很难设计出有效的测试。这意味着，即使测试全部通过，也可能存在未被覆盖的误解区域。因此，提升可理解性不是测试的替代，而是测试有效性的前提，两者应相辅相成。
提升可理解性的具体方法
文章提供了两类方法：一是让代码本身易于理解，包括考虑读者背景、隔离复杂逻辑、以新视角重读代码、将代码审查中的解释转化为代码注释或结构改进；二是添加支持文档，如系统架构文档、架构决策记录、产品需求文件和代码注释。这些方法各有局限，但结合使用能显著降低后续维护和修改的认知成本。
文档的时效性与维护
文章指出支持文档容易过时，但过期一个月的文档仍比没有好。建议通过定期日历任务更新文档，并利用新成员入职等时机确保其最新。架构决策记录还能带来额外好处：迫使决策者更清晰地思考，并在设计评审早期获得反馈。这提示我们，文档的价值不仅在于记录，更在于促进理解和沟通。
Q&A
为什么说软件设计时最重要的目标是可理解性？
因为被误解的软件会产生缺陷，尤其是正确性问题。如果实施者和维护者不理解软件，就无法保证安全性、性能，任何改动都可能失败。
测试能弥补对软件理解的不足吗？
不能。测试只能覆盖有限的表面区域，而且如果不理解软件，也很难设计出好的测试。
如何让代码本身更容易理解？
记住观众，为非共识内容添加注释；隔离最高复杂性，将复杂代码提取到独立模块；用新的眼光阅读代码；集成代码审查评论，直接更新代码而非仅解释。
有哪些支持文档可以帮助理解代码库？
系统架构文档、架构决策记录和设计评审、产品需求文件、代码注释。
架构决策记录有什么作用？
它提供决策记录，帮助了解后来做出了什么决定或为什么做出；通过写下决定迫使自己更清晰；并可在设计评审过程中获得早期反馈。
为什么代码注释很重要？
代码注释有助于解释特定代码单元的作用及其存在的原因，特别适用于令人惊讶的情况，并可以指向相关文档。
