如何进行预制项目架构审核

Question

当项目结束时,很容易看到体系结构错误的相对性.X给了我们安全问题,或者Y给了我们很多额外的工作.这些都是在回顾中发现的,但是很早就能抓住它们.

我们计划在编码开始之前进行架构审查.

一种方法是让建筑师展示项目,看看我们是否能找到设计中的缺陷.

有没有人有更结构化的方法,可能有"你有没有想过"或"你打算怎么做"的检查清单.

我想的是:

• 安全
• 记录
• 数据访问
• 部署
• 升级

Answer 1

要添加到列表中的其他项目（排名不分先后）：

• 性能 - 延迟、带宽、扩展或与您的交付成果相关的其他因素
• 可支持性 - 您已经有了日志记录，但是其他诊断测量中的管道怎么样（Java-JMX、Windows-WMI/性能计数器或自定义的东西）
• 灵活性 - 稍后更改架构的困难（这通常是过度完成并导致不必要的问题的事情之一，但在评估设计时应该进行讨论）
• 线程模型/锁定模型 - 是否清楚如何保护数据？如何处理资源争用？
• 资源需求 - 不同使用级别的内存消耗。它符合您的限制吗？
• 错误处理 - 当产品中的某些内容出现故障时，架构是否支持干净的处理和问题通知？
• 可以理解 - 过于复杂的架构在实现过程中往往会被遗忘。如果团队的大多数成员，特别是领导者，无法在他们的头脑中保留架构、哲学和规则，那么架构就不重要了。
• 一致性。它是尝试使用所有可能的模式还是专注于常规、重复的模式。并不是说为每个问题选择正确的模式不是一件好事，但拥有大量模式会影响可理解性并导致实施错误。架构师应该尝试在每个项目中展示他们所知道的一切（或最新的很酷的东西）。
• 可测试 - 设计是否有助于或损害测试（系统和集成）工作。测试可以自动化吗？或者您是否需要依靠大量测试人员来不断重复回归测试，以便您知道您的团队没有破坏产品？
• 该架构是否真正解决了您正在尝试解决的问题并在问题的范围内？当复式就足够的时候，不要建造摩天大楼。