架构师训练营第 1 期第二周总结

编程的实质是通过计算机语言来抽象现实世界的问题，而抽象出的成果就是模型，抽象过程的挑战，一是模型能否正确的反应现实世界的实物，二是模型之间的关系能否正确反应现实世界的问题，能否反应实物之间的关系，我们通过计算机语言让计算机理解模型和模型之间的关系。



经过几十年的发展，面对对象编程是我们目前的主流编程思想：

1.面对对象编程吧万物都能看作对象。

2.程序是对象的合集，对象相互发送消息表达他们之间的关系。

3.对象有自己的，状态（数据），行为（方法），标示（唯一地址）



面对对象编程有三个要素：

1.封装性：封装使得代码的物理组织可以结构化拆分，管理，打包，还可以选择隐藏一些特性，或者控制访问的权限。

2.继承性：继承也是对现实世界实物的一种抽象，不同的类型通过继承获得同样的数据和方法，也将我们的模型归类，避免重复的实现同样的状态和行为。

3.多态性：多态是最重要的一个特性，多态实现了对象之间的互换，子类实现父类或接口之后，通过注入不同的子类，程序表现出不通的形态，面向对象编程就是使用多态的特性进行编程，很多设计模式就是使用多态的特性，满足程序的设计原则。



面对对象设计的目是高内聚，低耦合，从而让系统，易于扩展，更加健壮，容易移植，维护简单，要想做到这一点，需要满足下面的设计原则：

1.开放封闭原则OCP：对扩展开放，对修改封闭，正确的抽象可以降低后期对类的修改，使用合适的设计模式可以帮助开发容易扩展，封闭修改。

2.依赖倒置原则DIP：高层不依赖低层，而都依赖抽象，抽象不依赖现实，而现实依赖抽象，面对接口编程，减少耦合。

3.里氏代换原则LSP：子类行必须能够替换掉他的父类型。里氏代换的关键不是静态的分析对象之间是否有继承关系，而是在应用场景中看子类能不能替换父类，替换之后程序能够正常工作，正阳就正确的约束了继承关系，保证继承抽象的正确使用。

4.单一职责原则SRP：一个职责意味着着一个变化的原因，高内聚就意味着，一个模块的设计，应该遵循组成元素之间功能的相关性是强力相关的，以至于应该只能有一个能引起它变化的原因。

5.接口分离原则ISP : 不应该强迫客户程序依赖它们不需要的方法，这个原则针对的是接口的高内聚设计原则。



不遵循设计原则的软件会导致一系列问题

1.僵化性：系统很难改动，牵一发而动全身，模块之间依赖太紧密耦合严重。

2.脆弱性：修改旧问题产生新的问题，一修改代码就有BUG产生。

3.牢固性：组件之间互相引用，互相纠缠，很难分离，修改的风险也大。

4.粘滞性：做正确的事情比做错误的事情困难，改动有可能破坏现有的设计，当能破坏原有设计的解决方案比不破坏原有设计的方案更容易实施的时候，就表明现在有高粘滞性的问题。

5.不必要的复杂性： 设计中包含不具有任何直接好处的基础结构。造成不必要的复杂，过度设计，不能简化问题，就会造成这样的问题。

6.不必要的重复： 设计冲包含重复的结构，造成修改一个问题，要修改很多处地方。

7.晦涩性：代码难以阅读，难以解，造成维护的困难。



对比遵守设计原则和不遵守设计原则对程序带来的影响，答案很明显，但是如何能保证程序的开发过程中都遵守这些原则而不违背呢。这不光是普通程序员要思考的问题，更是架构师需要思考的问题。程序员最多能做到在编写自己模块的时候遵照这些原则去做，但是一个系统由不同技术能力，不同特点的人协作完成的时候，仅仅依靠程序员对业务，原则的理解是不可能达到整个系统的统一，如何将设计原则变成必须遵守的规范，让大家都在一定的规范下协作，而让违背原则反而变得不容易是架构师应该思考的事情。



手段1: 整个团队制定编码规范，简单到容易落地的规范，之后根据团队实际问题，逐步增加条目。

好处是容易执行，能够明显改善一些简单的坏代码，缺点是约束力不强，不能阻止坏代码的产生。



手段2: 自动化和人工代码审查结合，找出代码中已有的问题。

好处是效率高，可以应用更加复杂的代码规范，组织定期的代码审查会议，对组织内成员共同的技术能力，和理解能力都有提升，也可以预防坏代码被推入正式的分支。挑战是整个团队能否做到一旦发现坏代码，就去进行改进，团队能否做到一直坚持有质量的代码评审会议，否则即使再好的自动化审查工具都没用。



手段3: 优秀的框架设计，合理的设计模式的使用，核心业务的封装，根据成员水平的不同，安排成员开发不同层级的模块。

优点是技术能力匹配模块的重要程度，能力越大责任就越大。挑战是能否将合适的人放在合适的位置，架构是能否设计出优良的架构，进行合理的业务隔离或者封装，并且配合成员的能力层级，以及与项目经理合作，安排合适的人做合适的模块。也就是说架构师的能力决定了这种手段执行效果的好坏。



手段4: 团队整体技术能力的提高，一起学习，培养同样的开发理念。

再好的审查工具都是代码写出来之后才能发现问题，都不能完全阻止坏代码的产生，再精巧的规范设计都不能保证规范被严格执行，正如极限编程中所追求的，整个系统的代码都如同出自一个人之手的境界一样，架构师如何能让整个系统的代码都如同出自他一人之手，必须要通过主动和被动的手段不断的修正，让系统在可控的范围内开发下去，团队成员也越来越有能力自主的修正坏代码的产生，应该是架构师应该肩负的责任