本篇文章是学习《代码大全2》中3.5章节后的复习整理详细内容大家可以直接阅读原本书籍。程序组织架构首先要对有关系统做一个综述包括曾经考虑过的方案、最终的方案和采用最终方案的原因。同时架构不仅要定义程序的主要构造块还要定义各个构造块的职责。单个构造块可能是一个类也可能是几个类构成并且各个构造块之间要尽量解耦尽量不了解彼此这样才能将设计的信息局限在各个块之内。最后是要描述清楚各个构造块之间的通信情况即某个构造块直接使用谁、间接使用谁不使用谁。主要的类根据80/20法则架构应该详细描述支撑系统80%功能的20%的类包括这些类的职责类与类之间的交互等例如类的继承体系、状态转换、对象持久化等的描述。数据设计架构当然要包括数据的设计这里主要是指文件和数据库表的设计。不仅要给出现在的设计还要记录曾经的其他方案并给出说明理由这样做的目的是为了便于软件开发人员能够在构建阶段理解架构师的思想在维护阶段同样能明白当初选择现在的数据设计方案的理由。业务规则如果架构依赖特定的业务规则则应该在架构设计文档中详细描述这些规则例如数据的保存时效要求等这是架构设计的来源之一。用户界面设计正常在需求阶段就应该详细描述用户界面如果没有则在架构设计阶段进行详细描述。架构应该模块化这样当替换用户界面时不会影响业务规则和程序的输出。资源管理这里的资源管理主要是对稀缺资源的管理如数据库连接、线程、句柄等。对内存的管理通常是在内存受限的领域才需要如嵌入式系统。架构需要估算正常和极端情况下的资源使用量。安全性架构应该描述实现设计层面和代码层面的安全性的方法。首先是制定编码规范的时候就应该考虑到安全性如加密、错误消息的细致程度、处理非受信信息的规则等。性能这部分比较好理解如果客户有性能要求则应该在需求中详细定义性能指标。而架构则应该提供估计的数据说明这样的设计能够满足性能指标。如果存在达不到指标的风险经常会有这种情况架构文档中也应该明确说明该风险。当然性能也可以包括架构设计中类和对象的空间、时间预算。可扩展性可扩展性即系统满足未来需求的能力架构需要描述如何应对未来可能得需求增长如数据库记录数的增加用户数量的增加网络连接的增加等需求。如果没有可扩展性的需求则也应该在架构中明确说明。互用性预计系统可能会与其他软件或硬件共享资源如数据、硬件等则也应该在架构中描述清楚。国际化/本地化对交互系统国际化问题是需要在架构中关注的问题架构应该考虑过典型的字符串和字符集问题并描述如何无需更改代码就能维护这些字符串以及如何将这些字符串翻译为另一种语言而又尽量不影响代码和用户界面。描述的颗粒度类似于是在代码中直接嵌入字符串还是将字符串封装进某个类通过类的接口来使用它亦或者将这些字符串存入资源文件。架构需要说明最终方案以及选择这个方案的理由。输入/输出架构对于输入输出的设计包括两个方面一个是详细的读取策略一个是对错误处理的位置层级如是在字段、流或者文件的层级。错误处理错误处理是非常重要的一个部分它牵连到了整个系统因此在架构层面设计好错误处理是比较好的时机。错误处理的设计需要考虑如下问题错误处理是纠错还是仅仅检测错误检测是主动还是被动所谓主动即主动检测用户输入被动即当输入数值超过限定时被动指出。错误如何在程序中传播是丢弃还是立即处理是进入错误状态还是在所有动作执行完成后再对错误进行处理错误消息的处理有什么约定架构应该建立一套有关错误消息的约定。如何处理异常在程序的什么层次上处理错误是在发现错误的地方处理还是将错误传递到专门处理错误的类进行处理或者沿着调用链向上传递错误具体到每个类在输入数据的有效性方面承担什么责任。每个类负责检查自己数据的有效性还是设计一个其他的类统一负责验证系统数据的有效性?利用运行环境内建的错误处理方法如windows的API会定义自己的异常等信息还是自己创建一套错误处理机制容错性架构应该详细定义所期望的容错种类容错方法等。架构的可行性架构应该运用验证概念的原型、研究或者其他手段来验证系统的技术可行性并在构建即编程开始之前解决掉这些风险。过度工程架构的详细程度通常要超过需求的详细程度目的是为了确保系统的健壮性。因为如果组成系统的各个部分只能在最低限度上满足健壮性要求那么系统整体上无法达到所有要求的健壮程度。软件中比木桶理论更严重的是系统的强度不取决于最薄弱的一个环节而是链条上所有薄弱环节的乘积。因此架构需要定义过度工程的方法明确设立期望目标避免小儿麻痹的情况。“买”还是“造”软件开发人员都知道如果有现成的标准库肯定是用经过检验的标准库或者其他开源、商业库是最有效率的。但某些时候出于功能的缺失、成本等原因必须自行定制软件组件则架构中也应该说明并给出自己定制的理由。关于复用的决策如果存在可以复服用的材料如已经存在的软件、测试用例、数据格式等则架构应该说明如何复用。变更策略变更策略是非常重要的因为对于用户和软件开发人员来说整个构建过程都是一个学习和深入理解项目的过程变更是必然发生的事情。这些变更可能来自数据类型、文件格式、功能需求的变更。因此架构师必须考虑到如何设计结构才能保证足够的灵活度来适应可能出现的变化。因此架构需要清楚地描述处理变更的策略。架构要列出考虑过的可能的变更并说明如果出现该变更会对哪几个类有影响。架构的总体质量一个比较清晰的架构质量的评判标准是该架构是否讨论了系统中类、每个类的隐藏信息以及采纳或排斥可能的设计方案的原因。好的架构设计应该始终与待解决的问题和谐一致且能够保持概念的完整性而不是看起来像是把架构和待解决的问题生硬地绑在一起。优秀的架构设计应该尽量独立于运行环境和编程语言不过度描述也不欠描述明确指出存在的风险以及为了应对可能的风险而采取的措施提供多个视角帮助程序员更好地理解系统。