5

当项目结束时，很容易看到架构错误。X 给了我们安全问题，或者 Y 给了我们很多额外的工作。这些都在回顾中被抓住了，但如果能早点抓住它们会很好。

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

一种方法是让架构师展示项目，看看我们是否能找到设计中的缺陷。

有没有人有更结构化的方法，可能有“你想过吗”或“你打算怎么做”检查清单。

我在想类似的东西：

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

5 回答 5

2

显然，有大量关于该主题的书籍（例如，建筑师应该知道的 97 件事）。你可以在这里找到一个完整的公理列表，我建议你挑选那些对你的项目有意义的公理作为你的清单。

于 2010-02-03T09:25:43.310 回答
2

要添加到您的列表中的其他项目，没有特定的顺序：

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

变化是不断的，请确保您的架构具有适应性。
用户界面是改善用户体验的东西。
与大家完全分享有关架构的知识。
在实施之前尝试。
不要过度使用设计模式。

于 2010-02-04T13:22:03.740 回答
1

您应该使用众所周知的模式甚至架构框架来减少假设。

项目结束时比较容易看到架构错误，但这取决于我们所做工作的本质。

我相信持续进行架构审查是一种很好的做法。这不是您“完成”的步骤。

于 2010-02-03T09:11:47.863 回答
1

对于重要的项目，我们做的一件事是解决方案选项文档。您进行头脑风暴、收集现有信息、与 SME 交谈、与任何需要的人交谈，并为各种选项创建一个表格，其中包含优点、缺点、粗略成本和估算。是的，这个练习是一个开销，但是如果你这样做，你描述的很多问题都会被知道。

最后推荐一个管理解决方案，说明原因，可能还有一个高级架构图来可视化解决方案。

于 2010-02-03T09:16:47.763 回答