最近在阅读代码大全,感觉这本书很经典,把我认为重要的写了下来。
维护设计的缘由与维护设计本身一样重要。
在软件中,链条的强度不是取决于最薄弱的一环,而是等于所有薄弱环节的乘机。
你不应该担忧架构的任何部分,架构应该不包含任何仅仅为了取悦老板的东西,它不应该包含任何对你而言很难理解的东西,你就是那个设计架构的人,如果你自己都不懂,你怎么实现它?
架构应该定义程序的主要模块。
1)主要的类:架构设计之初应该详细定义所用的主要的类,包括:类的责任,与其他类的交互,类的继承体系、状态转换、对象持久化等描述。
80:20%:对那些构成系统80%的行为的20%的类进行上述详细的描述。
2)数据设计:架构应该描述系统所用到的主要文件以及数据表的设计。他应该描述曾经考虑过的方案,并说明做出选择的理由。
3)业务规则:如果架构依赖于特定的业务规则,那么他就应该详细描述这些规则,并描述这些规则对系统设计的影响。
4)用户界面设计:架构应该详细定义Web界面格式、GUI、命令行接口等主要元素,架构设计应该能让我们很容易做到:砍掉交互式界面的类,插入命令行的类,便于子系统和单元级别的软件测试。
5)资源管理:架构应该描述一份管理稀缺资源的计划。稀缺资源包括数据库连接、线程、句柄等,架构应该估算出正常情况下和极端情况下资源的使用量。
6)安全性:架构应该描述实现设计层面和代码层面的安全性的方法,包括处理缓冲区的方法,处理非受信的数据(用户输入的数据、cookies、配置数据文件、其他外部接口输入的数据)的规则、加密、错误消息的细致程度,保存内存中的秘密数据。
7)性能:架构应该详细的定义资源(速度、成本、内存)之间的优先顺序。
8)可伸缩性:架构应该描述如何应对用户数量、服务器数量、网络节点数量、数据库记录数量、交易量的增长。
9)互用性:如果预计这个软件会与其他软件共用数据或资源,架构应该描述如何完成这一任务。
10)国际化和本地化:考虑所使用的字符集,如何无需更改,使用这些字符串,是将字符串封装进入某一个类,透过接口来使用他,还是将这些字符串存入到资源文件中,架构应该说明是选用的哪种方案。
11)输入输出:架构应该详细的定义读取策略,是先做、后做、即时做,而且应该描述我们在哪一层做I/O错误检测。
12)错误处理:架构应该制定详细的错误处理策略。应该明确:是检测还是纠正,是主动检测还是被动检测,什么时候抛出异常、在什么地方捕获异常、如何记录这些异常,以及如何在文档中描述异常等等。
13)容错性:当错误发生时,进行错误截断,重新尝试,或转入部分运转状态或功能退化状态,系统可以自动关闭或重启。
14)买造决策:定制组件之前,探索是否存在相应的应用非常好的组件,以及这些组件是否能够很好的融入到设计的系统中。
15)变更策略:架构设计之初考虑有可能会增加的功能,架构应该说明这些变更已经被预料到了。