什么应该包含在应用程序架构清单中？

时间：2009-05-30 06:07:43

标签： architecture review

我正在尝试提出一份清单或一组问题/标准来评估和评估建议或新兴架构（执行架构审查）。在尝试规划，评估或审查架构时，您提出了哪些最重要的问题？

我知道这是一个很大的主题，所以我想将它限制在一个端到端的系统而不是整个组织的架构。

代码完成提供了一个不错的起点：

  

架构

     
      
  • 该计划的整体组织是否清晰，包括一个好的   建筑概述和   理由？
    •   
  • 模块是否定义良好，包括其功能和   他们与其他模块的接口？
    •   
  • 是否明确涵盖了要求中列出的所有功能   既没有太多也没有太少的模块？
    •   
  • 该架构是否旨在适应可能的变化？
    •   
  • 是否包含必要的购买与构建决策？
    •   
  • 架构是否描述了如何使重用代码符合   其他建筑目标？
    •   
  • 是否所有主要数据结构都隐藏在访问例程后面？
    •   
  • 数据库组织和内容是否合理？
    •   
  • 是否描述并证明了所有关键算法的合理性？
    •   
  • 是否描述并证明了所有主要对象？
    •   
  • 是否描述了处理用户输入的策略？
    •   
  • 是否描述了处理I / O的策略并证明其合理性？
    •   
  • 是否定义了用户界面的关键方面？
    •   
  • 用户界面是否模块化，以便其中的更改不会影响   其余的计划？
    •   
  • 内存使用估算和内存管理策略   描述和证明？
    •   
  • 架构是否为每个模块设置了空间和速度预算？
    •   
  • 是一种处理字符串的策略，是字符串   是否提供了存储估算？
    •   
  • 是否提供了一致的错误处理策略？
    •   
  • 是否将错误消息作为一个集来管理以提供干净的用户界面？
    •   
  • 是否指定了稳健程度？
    •   
  • 是否有任何部分过度或不足？是期望的   这个区域明确列出了什么？
    •   
  • 主要系统目标是否明确规定？
    •   
  • 整个架构是否在概念上挂在一起？
    •   
  • 顶级设计是否独立于机器和   将用于的语言   实施它？
    •   
  • 是否提供了所有重大决策的动机？
    •   
  • 作为一名将实施该系统的程序员，您是否适应   建筑？
    •   

我正在寻找具有实例的实践知识，例如，您创建的架构中最痛苦的点是什么？

6 个答案:

答案 0 :(得分：32)

根据我的研究，这里有一些建筑评论清单，我发现这个问题更加公正，并提供了一些建筑评论的背景知识。 （这里似乎有点混乱。）

这些潜在候选人中的每一个都包括许多不同的类别。这些类别的总体重要性将根据业务需求而有所不同。恕我直言，没关系。在通过检查清单进行审核并排除问题时，提出另一个问题要比完全错过问题或类别要少得多，因为它似乎不足以在最初列入清单。

似乎还有一篇关于这个主题的白皮书，尽管我还没有读过。它试图在大约11页的过程中回答这个问题。

此外，一位同事推荐了一套Springer的书籍，虽然我自己没有检查过这些书籍：

答案 1 :(得分：3)

其他一些要考虑的要点：

  • 是否确定了所有利益相关者？ （示例：客户，最终用户，业务分析师，用户界面设计人员，开发人员，测试人员，维护人员。）架构是否与利益相关方进行了验证？
  • 架构如何解决安全问题？
  • 是否规定了可用性和可靠性要求？架构如何解决这些问题？ （例子：平均故障间隔时间，平均修复时间。）
  • 如何处理灾难恢复？

两本关于更多想法的好书：

答案 2 :(得分：2)

你打算如何测试

答案 3 :(得分：2)

它是否使用SOLID原则？

答案 4 :(得分：2)

该架构是否符合技术供应商的指导和路线图？

您希望从所选平台获得支持，而不是与之抗衡。

e.g。对于以Microsoft为中心的解决方案，这意味着要记录您的选择偏离Microsoft Architecture guidance的位置和原因。

答案 5 :(得分：0)

是否有一个人可以对架构负责 （1）拟议架构的技术知识， （2）管理事物的经验， （3）站在公司，以便他的决定不会被不了解事物的管理层所推翻。

由于（2）和（3）并不真正依赖于架构，我会找到那个人并问他想做什么。

现在假设你是那个人（而且你的问题并不明显 - 仅当你认为你仍然会成为这件事的首席架构师时才适用），我会采取{{ 3}}并编写设计规范，包括计划，目标，客户，解释设计选择，一切。这应该清楚这一观点。

后来的想法

我试着想一想你在编写规范后可能会问自己的问题，例如“更新你的项目是否容易”，“它是否允许最终目标的灵活性”，“它会不会让事情变得容易支持'，'有任何安全问题'等等，但是，虽然值得提出这样的问题，但我认为没有任何方法可以用于任何'评估'，因为除了过滤明确的错误我不认为任何具体的问题对“评估架构”有很大帮助。也许你的问题会从改写中受益？

相关问题
最新问题