cwa*_*ash 40 architecture review
我正在尝试提出一个清单或一组问题/标准来评估和评估建议或紧急架构(执行架构评审).在尝试规划,评估或审查架构时,您提出了哪些最重要的问题？
我知道这是一个很大的主题,所以我想将它限制在一个端到端的系统而不是整个组织的架构.
Code Complete提供了一个不错的起点:
建筑
- 该计划的整体组织是否清晰,包括良好的架构概述和理由？
- 模块是否定义良好,包括其功能和与其他模块的接口？
- 是否合理地列出了要求中列出的所有功能,既没有太多也没有太少的模块？
- 该架构是否旨在适应可能的变化？
- 是否包含必要的购买与构建决策？
- 该体系结构是否描述了如何使用重用代码以符合其他体系结构目标？
- 是否所有主要数据结构都隐藏在访问例程之后？
- 数据库组织和内容是否合理？
- 所有关键算法都是描述和证明的吗？
- 所有主要对象都是描述和证明的吗？
- 是否描述了处理用户输入的策略？
- 描述和证明处理I/O的策略是什么？
- 是否定义了用户界面的关键方面？
- 用户界面是否模块化,以便其中的更改不会影响程序的其余部分？
- 内存使用估计和内存管理策略是否被描述和证明是合理的？
- 架构是否为每个模块设置了空间和速度预算？
- 是否描述了处理字符串的策略,是否提供了字符串存储估计？
- 是否提供了一致的错误处理策略？
- 是否将错误消息作为一组来管理以呈现干净的用户界面？
- 是否指定了稳健程度？
- 是否有任何部分过度或不足？该领域的期望是否明确规定？
- 是否明确说明了主要的系统目标？
- 整个架构是否在概念上挂在一起？
- 顶级设计是否独立于将用于实现它的机器和语言？
- 是否提供了所有重大决策的动机？
- 作为实施系统的程序员,您是否对架构感到满意？
我正在寻找具有实例的实践知识,例如,您创建的建筑中最痛苦的点是什么？
cwa*_*ash 34
根据我的研究,这里有一些建筑评论清单,我发现这个问题更加公正,并提供了一些建筑评论的背景知识.(这里似乎有点混乱.)
这些潜在候选人中的每一个都包括许多不同的类别.这些类别的总体重要性将根据业务需求而有所不同.恕我直言,没关系.在通过检查清单进行审核并排除问题时,提出另一个问题的成本要低得多,而不是完全错过问题或类别,因为它似乎不足以在最初列入清单.
似乎还有一篇关于这个主题的白皮书,尽管我还没有读过.它试图在大约11页的过程中回答这个问题.
另外,一位同事推荐了Springer的一套书,虽然我自己也没有检查过这些书: