代码大全2札记：软件架构中的设计

深碍√TFBOYSˉ_ 2021-06-24 14:00 342阅读 0赞

**前言**：软件架构中的设计一章，主要的point有软件的首要技术使命就是管理复杂度、减少在同一时间锁关注的本质性复杂量、设计是一种启发式过程、好的设计要有迭代、信息隐藏。

## 设计中的挑战 ##

1.  设计是一个险恶的问题：设计不可能从一开始就是完美的，人们在设计时会不明所以的忽略掉一些重要的问题，从而导致设计最终面对失败。
2.  设计是个了无章法的过程：设计过程中会发生很多错误，但正是设计所需要的。
3.  设计就是确定取舍和调整顺序的过程：设计者的关键工作就是找出发生冲突的特征，进行平衡。
4.  设计受到诸多限制：在进行设计的时候，需求者会给你提各种要求，比如说时间、金钱、质量，那么必须用把资源利用率达到最大。
5.  设计是不确定的：每一个对同一种需要作出的设计都是不同的。
6.  设计是一个启发式过程：设计的过程中会带来很多启发，比如说从错误的事件中得到另外一个新的设计。
7.  设计是自然形成的：设计需要不断的评估、讨论、试验、修改而成的。

## 关键的设计概念 ##

1.  管理复杂度
    
     *  偶然的难题和本质的难题：我认为是这样的概念，举个例子，NBA的每场得分，从本质上来看，每场最高得分不可能超过200分，那么我们是否可以将每场的最高得分限制为200分呢，显然这样会遇到一个问题，就是说假如出现某种偶然情况，竞争的两支球队，一支不防守，另外一支疯狂进攻，那么得分可能会超过200分，那么我们为了考虑这种偶然的情况，显然我们不可能把分数最高设置为200分。
     *  管理复杂度的重要性：设计软件有两种方式，第一种是设计非常简单，看上去明显没有缺陷；第二种是设计非常复杂，看上去没有明显缺陷。那么能将复杂度管理好，是非常重要的。
     *  如何应对复杂度：
        
         *  把任何人在同一时间需要处理的本质复杂度的量减少。
         *  不要让偶然的复杂度无谓增长。
2.  理想的设计特征：当我解决问题时，从不考虑美感。只想着如何解决问题，然而一旦解决了问题，如果解决方案不够优美，那么我知道做错了。
    
     *  最小的复杂度：设计要简单易于理解。
     *  易于维护：为需要维护的程序员着想。
     *  松散耦合：做设计时让程序的各个组成部分之间关联最小。
     *  可扩展性：能够增强系统的功能而不破坏原有机构。
     *  可重用性：当前系统的组成部分要能够在其他系统中重复使用。
     *  高扇入（让大量的类使用某个既定的类）、低扇出（让一个类少量或者适中的使用其他的类）
     *  可移植：可以方便的移植到其他系统。
     *  精简性：伏尔泰“一本书的完成，不在于不能再加入内容，而在于不能删除内容的时候”。
     *  层次性：尽量保持各个分解层的层次性，例如要在原来旧的代码上进行开发，假如就的代码不够优秀，那么就需要设计一个层次去和旧的代码进行沟通，同时和新的代码进行连接。
     *  标准技术：要能够使用标准化的、常用的方法，避免使用新颖而不成熟的技术。

## 设计的层次 ##

1.  软件系统
2.  分解为子系统：整个软件系统被分解为多个不同的子系统后，子系统之间的相互关联要尽可能的少，不能A-B-C-D-E之间来回的关联。子系统分为以下大的种类：
    
     *  业务规则：该子系统一般会要发生变化，客户的需求在开发过程或者开发完了后都要发生变化。
     *  用户界面
     *  数据库访问
     *  跨平台
3.  分解为类：将子系统适当的分解，其分解出来的类要形成具有特定功能的类。类和对象的关系，就如同模具和实物。
4.  子程序的内部设计：比如说选择不同的算法，比如要使用冒泡还是插入

## 启发式的设计 ##

1.  找出现实中的对象：先别问系统做什么，先问问它模仿什么。
2.  形成一致的抽象：抽象使你关注事物的共有特性，而暂时忽略其具体的细节。
3.  封装实现细节：封装可以让你看到一个返回Boolean的方法，但是却不让你看到怎么得到的true或者false。
4.  合适的继承：马云和马化腾都是人，但是他们领导的公司是不同的，那么他们两个就可以继承人的属性和方法。
5.  隐藏秘密：需要隐藏的秘密有两种，复杂度和变化源。

## 找出容易改变的区域 ##

1.  业务规则、硬件依赖、输入输出、状态变量、数据量的限制，这些因素都是容易发生改变的，就需要把这些从系统中进行分离。
2.  预料不同程度的变化。

## 保持松散耦合 ##

1.  耦合标准：
    
     *  规模：模块之间要尽可能的小
     *  可见性：模块之间要相互可见
     *  灵活性：模块之间的链接要容易。

## 查阅常用的设计模式 ##

1.  抽象工厂
2.  适配器
3.  桥接
4.  组合
5.  装饰器
6.  外观
7.  factory method
8.  迭代器
9.  观察者
10. 单例
11. 策略
12. 模板方法

## 其他的启发方式 ##

1.  高内聚性：类内部的子程序或者子程序所在的代码在支持一个中心的紧密程度。
2.  分层结构：建筑工程师在设计图纸的时候，总是先画起轮廓，然后再填充细节。
3.  契约：有的时候，约定俗成很好。
4.  分配职责：就比如在包名建立时，就需要区分controller和service。
5.  为测试准备
6.  避免失误：充分思考风险。
7.  考虑蛮力：有的时候拿不准注意的时候就用蛮力解决，就像实现消息包发送时，如果没有好的解决方案，就使用轮询解决。
8.  画图：在设计时，画一些粗糙的图来帮助自己理清思路。
9.  如果你被当前的问题难住了，那么就跳出来去思考其他问题，或者干脆睡一觉，因为大脑在休息的时候，依然会尝试寻找答案，那么其可能会得到正确答案。

## 设计实践 ##

1.  迭代：设计是一个过程，等你从头做到尾后，尽量从头再来一遍。
2.  分而治之：把复杂的系统分解。
3.  自上而下和自下而上：一般情况下，我们从顶层开始思考问题往往不错，但是有的时候从已知的底层反推也会祝你的设计一臂之力。
4.  建立试验原形：在你搞完设计后，不能纸上谈兵，要尝试实践测试。
5.  合作设计：寻找你的同伴，或者能给你帮助的人一起做设计。
6.  设计要适当：要懂得舍取
7.  记录设计成果：比如说记录到SVN、总结邮件、代码注释、UML

## 设计所有细节和不做任何设计 ##

极端的设计方案不可取

## 设计实践： ##

1.  设计经过了很多迭代，找出最合适的一种
2.  同时采用自下而上和自上而下的方案
3.  为可能出现的问题进行验证
4.  review方案
5.  记录设计成果