课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
我们在上文中给大家简单介绍了设计文档的作用和结构等内容,而本文我们就通过案例分析来了解一下,设计文档的生命周期都有哪些阶段。
创建和快速迭代
在这个阶段,你编写文档。有时会和一组作者合作编写。
当文档被分享给了解问题领域的同事(通常属于同一个团队)时,这个阶段会快速演变到快速迭代期,通过他们将问题搞清楚以及提供建议,让文档进入一个相对稳定的版本。
虽然你肯定会发现工程师甚至团队喜欢版本控制和代码评审工具来创建文档,但是谷歌的大部分设计文档是用GoogleDocs创建的,并且大量使用了它的协作功能。
评审
在评审阶段,设计文档会被分享到除初始作者和密切协作者之外的更广泛读者。评审可以带来许多价值,但它们也是危险的开销陷阱,所以要明智地处理评审。
评审有多种形式:比较轻量的方式是将文档发送给(比较广泛的)团队列表中,让人们都有机会看一看。讨论主要发生在文档的评论环节。比较重的评审,是正式的设计评审会议,在会议上,作者将文档(通常是一个专门的演示文稿)展示给级别较高的工程师。谷歌的许多团队都会为此定期召开会议,工程师可以报名参与评审。当然,等待这些会议的召开会明显减慢开发进度。工程师可以通过直接寻求关键性反馈来缓解这种情况,而不是阻碍更广泛的评审流程。
当谷歌是一个比较小的公司时,人们习惯于将设计发送到一个核心邮件列表,高级工程师在他们闲暇时评审这些设计。这可能是一个很好的方式来处理你公司的事情。其中一个好处是,这确实在公司中建立了一种相对非正式的软件设计文化。但是,当公司规模扩大到一个相对大的工程团队时,维持集中化的方式变得不再可行。
评审带来的主要价值是,它们提供了一个机会将组织的综合经验融入到设计中。为一贯的是,评审阶段可以确保将跨领域的关注点,例如观测性、安全性和隐私性考虑在内。评审的主要价值不在于发现问题本身,而是在开发周期的早期就发现问题,此时进行更改的成本仍然相对较小。
实现和迭代
当事情进展到确信进一步评审不再需要对设计进行重大改动时,就可以开始实现了。当计划与现实冲突时,不可避免地会出现一些缺点、解决不了的需求、深思熟虑的猜测结果是错误的等情况,并且需要变更设计。这种情况下,强烈建议更新设计文档。
一般来说:如果设计的系统还没有交付,一定要更新文档。在实践中,我们人类都不擅长更新文档,而且由于其它实际原因,更改通常被独自放到新文档中。这导致终状态有点类似美国宪法附带一堆修正案,而不是一份一致的文件。从原始文档到这些修正文件的链接,对于将来尝试通过设计文档来理解目标系统的可怜的维护程序员是非常有用的。
维护和学习
当谷歌工程师面对一个他们从未接触过的系统时,他们的一个问题通常是“设计文档在哪里?”。虽然设计文档和其它文档一样,会随着时间的推移与现实脱节,但它们仍然常常是了解系统创建思想的容易的入口。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。