最近在阅读代码大全，感觉这本书很经典，把我认为重要的写了下来。

   维护设计的缘由与维护设计本身一样重要。

   在软件中，链条的强度不是取决于最薄弱的一环，而是等于所有薄弱环节的乘机。

   你不应该担忧架构的任何部分，架构应该不包含任何仅仅为了取悦老板的东西，它不应该包含任何对你而言很难理解的东西，你就是那个设计架构的人，如果你自己都不懂，你怎么实现它？

   架构应该定义程序的主要模块。

       1）主要的类：架构设计之初应该详细定义所用的主要的类，包括：类的责任，与其他类的交互，类的继承体系、状态转换、对象持久化等描述。

80：20%：对那些构成系统80%的行为的20%的类进行上述详细的描述。

       2）数据设计：架构应该描述系统所用到的主要文件以及数据表的设计。他应该描述曾经考虑过的方案，并说明做出选择的理由。

       3）业务规则：如果架构依赖于特定的业务规则，那么他就应该详细描述这些规则，并描述这些规则对系统设计的影响。

       4）用户界面设计：架构应该详细定义Web界面格式、GUI、命令行接口等主要元素，架构设计应该能让我们很容易做到：砍掉交互式界面的类，插入命令行的类，便于子系统和单元级别的软件测试。

       5）资源管理：架构应该描述一份管理稀缺资源的计划。稀缺资源包括数据库连接、线程、句柄等，架构应该估算出正常情况下和极端情况下资源的使用量。

       6）安全性：架构应该描述实现设计层面和代码层面的安全性的方法，包括处理缓冲区的方法，处理非受信的数据（用户输入的数据、cookies、配置数据文件、其他外部接口输入的数据）的规则、加密、错误消息的细致程度，保存内存中的秘密数据。

       7）性能：架构应该详细的定义资源（速度、成本、内存）之间的优先顺序。

       8）可伸缩性：架构应该描述如何应对用户数量、服务器数量、网络节点数量、数据库记录数量、交易量的增长。

       9）互用性：如果预计这个软件会与其他软件共用数据或资源，架构应该描述如何完成这一任务。

      10）国际化和本地化：考虑所使用的字符集，如何无需更改，使用这些字符串，是将字符串封装进入某一个类，透过接口来使用他，还是将这些字符串存入到资源文件中，架构应该说明是选用的哪种方案。

      11）输入输出：架构应该详细的定义读取策略，是先做、后做、即时做，而且应该描述我们在哪一层做I/O错误检测。

      12）错误处理：架构应该制定详细的错误处理策略。应该明确：是检测还是纠正，是主动检测还是被动检测，什么时候抛出异常、在什么地方捕获异常、如何记录这些异常，以及如何在文档中描述异常等等。

      13）容错性：当错误发生时，进行错误截断，重新尝试，或转入部分运转状态或功能退化状态，系统可以自动关闭或重启。

      14）买造决策：定制组件之前，探索是否存在相应的应用非常好的组件，以及这些组件是否能够很好的融入到设计的系统中。

      15）变更策略：架构设计之初考虑有可能会增加的功能，架构应该说明这些变更已经被预料到了。