优秀的设计文档写法指南软件需求设计文档怎么写( 四 ) _文档

当谷歌是一个比较小的公司时，人们习惯于将设计发送到一个核心邮件列表，高级工程师在他们闲暇时评审这些设计。这可能是一个很好的方式来处理你公司的事情。其中一个好处是，这确实在公司中建立了一种相对非正式的软件设计文化。但是，当公司规模扩大到一个相对大的工程团队时，维持集中化的方式变得不再可行。
评审带来的主要价值是，它们提供了一个机会将组织的综合经验融入到设计中。最为一贯的是，评审阶段可以确保将跨领域的关注点，例如观测性、安全性和隐私性考虑在内。评审的主要价值不在于发现问题本身，而是在开发周期的早期就发现问题，此时进行更改的成本仍然相对较小。
实现和迭代当事情进展到确信进一步评审不再需要对设计进行重大改动时，就可以开始实现了。当计划与现实冲突时，不可避免地会出现一些缺点、解决不了的需求、深思熟虑的猜测结果是错误的等情况，并且需要变更设计。这种情况下，强烈建议更新设计文档。
一般来说：如果设计的系统还没有交付，一定要更新文档。在实践中，我们人类都不擅长更新文档，而且由于其它实际原因，更改通常被独自放到新文档中。这导致最终状态有点类似美国宪法附带一堆修正案，而不是一份一致的文件。从原始文档到这些修正文件的链接，对于将来尝试通过设计文档来理解目标系统的可怜的维护程序员是非常有用的。
维护和学习当谷歌工程师面对一个他们从未接触过的系统时，他们的第一个问题通常是“设计文档在哪里？” 。虽然设计文档和其它文档一样，会随着时间的推移与现实脱节，但它们仍然常常是了解系统创建思想的最容易的入口。
作为作者，自我回顾并在 1 年或 2 年以后重新阅读你的设计文档。你做对了什么？你做错了什么？今天你怎么做才会做出不同的决定？回答这些问题是一个很好的方法，来实现工程师进阶和随着时间的推移提高软件设计技能。
结论设计文档是一个很好的方法，用来在解决软件项目中最难的问题方面提高清晰度并达成共识。设计文档节省了资金，因为它们可以通过预先调查，避免编写无法实现项目目的的“兔子洞”（译者注，rabbit holes 源自《爱丽斯漫游仙境》，指通向未知世界的入口）；设计文档也损耗资金，因为创建和评审设计文档需要时间。所以，针对你的项目要明智地选择！
当考虑编写一个设计文档时，想一想以下几点：
你是否不确定正确的软件设计，是否有必要花费前期时间来增加确定性？与此相关的是，因为高级工程师可能无法审核每一次代码变更，因此让他们参与设计是否有帮助？软件设计是否模棱两可甚至是有争议的，而围绕设计文档在组织上达成共识是有价值的？我的团队是否有时会忘记考虑设计中的隐私性、安全性、日志记录或其它交叉问题？是否强烈需要文档来对组织中的遗留系统的设计提供高层次的见解？如果您对这些问题中的 3 个及以上回答为“是”，那么设计文档可能是开始你的下一个软件项目的好方法。

优秀的设计文档写法指南 软件需求设计文档怎么写( 四 )

猜你喜欢

优秀的设计文档写法指南软件需求设计文档怎么写( 四 )