技术设计文件的工具和标准

Question

我想知道我的同事现在使用哪些工具和标准用于技术设计文档。

过去在我公司工作时，我们只提供客户端 - 服务器win-apps，我们为设计文档提供了文字模板。我们的模板总是从数据库图开始，然后是UI模型，字段映射，功能描述等...使用Word和Visio，我们已经足够了。但最近我们正在整合维基，UML图表，原型设计工具等......没有真正强大的标准和工具政策。您是否认为让建筑师自由选择他们认为适合每个项目的特定时刻的工具和标准，或者公司是否应该对此进行执行和标准化？

Answer 1

在我看来，主要开发人员或团队成员之间的深入讨论（可能记录在以后）比任何文档都更有价值。给予他们选择工具的所有自由，并要求他们尽早写出高级技术决策的简短摘要。这可以作为项目后期文档的基础。技术设计文档过早过时，需要花费太多时间来编写。

Answer 2

我认为应该有一套在架构时指定的工具和标准，用于描述如何记录设计。记录这些东西的标准非常重要;否则，他们往往会被抛弃;如果设计文档是异质的，那么真正需要了解设计的人可能无法找到他们真正需要的设计信息。

也就是说，工具和标准的选择完全取决于每个不同的组织;任何为组织工作的东西都适合他们。只要标准（以及工具，在某种程度上）保持一致，为个别组织选择的任何内容都适合他们。它只需要决定并执行。

Answer 3

任何设计文档背后的原因都是与所有参与者的明确沟通。因此，从这个角度来看，无论您作为架构师选择哪种工具，成品都需要现在由所有相关人员阅读，后来由维护人员阅读。因此，选择至少一些相当标准的工具是有意义的，这些工具将在几年后仍然存在。

也就是说，设计文档通常用于启动项目或系统。此后记录良好的代码，一些基本文档应该足够了。我可能会更加关注文档的组织，以便人们可以轻松找到他们将来要查找的内容。它可以帮助强制执行某种标准的存储库结构/系统来存储文档，但不一定要坚持使用各种模板进行文档编制。专注于内容，而不是工具。

Answer 4

除非您的项目是千篇一律，否则只有将最佳工具组合应用于手头的工作才有意义。也就是说，一些松散的（粗略的指导方针）或狭隘的（适用于特定情况）标准可能是必要的。