架构师训练营 第二周 个人感想

0期3班4组 杨娴艳

本周的课程内容非常饱和，智慧老师通过step by step的方式带领大家对具体的有“臭味”的设计实例进行了优化，非常自然的将可扩展性差、脆弱的设计推演出了优雅的、具有可扩展性的设计。整个推演过程中，包含了对UML图的设计优化以及代码的重构，蕴含了对设计原则的遵循，更深一个层次是灵活运用了部分常用的设计模式。



这种推演的过程非常有趣也的确直击人心，在实际开发过程中，只要我们有心去翻阅一下现有项目的代码，不乏这一类充满了 if else 的缺乏良好设计的代码，出现这样的问题的原因是：

1）对面向对象分析和设计的知识了解太少，不愿意也不知道需要花时间去阅读如《敏捷软件开发》、《重构》等经典书籍，在实际开发过程中，很难意识到自己是在写有“臭味”的代码。

2）因为历史原因，很多既有的业务在进行二次开发的时候，一般的开发人员为了规避风险会选择不去重构他人或者过去自己写的代码，即便代码已经有了浓重的臭味，针对这样的情况需要相机行事，当一个业务已经交到我们手里，我们对其有充分的设计和开发权力的时候，就是我们对其进行重构和优化的时机。



在本周课程中，智慧老师的重点内容包括：设计原则以及对部分设计模式（如策略模式）的详细介绍。大概在2012年，我进入当时的架构部门，参与当时公司的开发框架的研发，开始系统的学习面向对象分析和设计的相关知识，本次的课程中很多的概念和思想在当时的团队中都有过很多深入的探讨，下面我谈一下通过本次和大家一起分享了智慧老师的课程后，结合自己的感受，对部分设计原则和设计模式部分核心思想的理解和感受。



一、依赖倒置

单独想谈谈依赖倒置原则，这个是一个非常有趣的原则。在《敏捷软件开发》一书中的定义是：1）高层模块不应该依赖于底层模块。二者都应该依赖于抽象。2）抽象不应该依赖于细节。细节应该依赖于抽象。用最简单的一句话描述就是：上层不依赖于下层，大家都依赖于接口。



上层依赖接口，这个很好理解，因为高层模块往往提现了系统的核心业务模型，是可以独立于实现构建为一个独立的应用的，它甚至可以说是一个应用系统的最高层次业务api的集合，在设计这个层次的api的时候，我们往往要考虑的是：

1） 他们所能依赖的应该是基于JDK或者通用的框架的一些接口或者类，如Apache、Spring等框架，或者是由高层自己定义的领域接口类，这一类的接口是属于高层框架中的一部分，非常稳定。

2） 具体的实现就会存在变化，一旦高层模块依赖的是低层具体的实现就会存在具体实现的变化影响高层，高层的代码就会出现不稳定性和脆弱性；

3） 高层模块依赖了具体后，一旦出现了业务的变更势必就需要通过修改既有的代码，从理论上说违背了开闭原则，具体来说就是代码的可扩展性极差，代码也变得业务迭代困难（没有测试保障的话就更可怕），非常脆弱和不稳定，最容易出现的就是版本升级一下很容易影响既有业务。

4） 如果我们能够设计良好，面向接口编程，我们可以充分的利用面向对象多态的妙处，在合适的场景使用合适的设计模式，让我们的代码简单、优雅并且具有可扩展性。



二、好莱坞原则

著名的Hollywood原则是："Don't call us , we'll call you" ，翻译过来是：请不要调用我们，我们会调用你。这个原则阐述的是接口的所有权，提现了“倒置”的精髓，也是作为框架（framework）设计的核心原则。具体来说就是低层模块实现了高层模块中声明并且被高层模块调用的接口。



在面向对象设计和编程过程中，我们应该遵循的是面向接口的编程，而到底接口是什么？是两个模块的连接点？最让人误解的是会让人觉得接口就是一个“服务”的声明，事实上，它从编程的语法角度上看，的确是一个实现类的声明，那我们应该关心的是什么？接口是哪里来的，是谁定义的是关键。接口属于调用方，是由调用方定义的。所有的低层实现都应该遵循高层既有的接口定义进行具体实现。这样的思维的确和传统的分层思想有一些冲突，但如果考虑到高层模块接口的独立可提取、重用性、多种实现等角度来讲，就可以理解了。什么是高层，高层是决策者，是标准和规范定义者，它所定义的协议和约束都需要被遵守。当然，如果按照TDD（测试驱动）的方式进行开发的话会更加容易理解，接口究其根本是由其调用者驱动出来的。一般情况下，以J2EE平台+Spring框架开发过程为例，通过TDD的方式进行开发的过程中，在编写测试用例的时候，起初编译器都是红通通的一片，因为一开始的接口都没有任何的实现。



三、设计模式

针对设计模式，我们如果把它当作知识来记忆和学习特别的困难，每一种设计模式都是在其特有的场景中才适用的。记得当时针对策略模式和状态模式进行对比的时候，发现两个模式的UML图是相同的，让我思考了很久，后来再慢慢去体会策略模式和状态模式，两种是在完全不同的场景下应用的，策略模式是系统运行时动态的策略的选择，而状态模式针对的是同一个对象状态的变迁，即便UML图的结构类似，所表达的也是两种截然不同的概念。



第一次深刻的接触设计模式是在阅读Martin Fowler的《重构》这本书的时候，书中开篇通过对《影片租赁 Movie Rental》的示例代码进行了重构的推演，最后推演出了策略模式的运用，在团队领导的要求下，我们将重构Movie Rental 作为个人的课后练习推演了不下十几遍，只有亲手对代码进行重构了数遍才渐渐对策略模式的妙处有了更加深切的体会。后续参与现就职公司的电商平台的架构和研发的时候，面对各种价格策略业务，运营活动的业务，策略模式就起到了非常重要的作用，合适的场景加上熟练的运用让类似“增加一个优惠券类型后计算优惠金额的算法有相应的变化”这样的业务变更变得非常灵活和简单，项目的迭代也相应变得迅速和稳定。当然还有很多常用的设计模式，如监听者模式、组合模式、单例模式、命令模式等，都会在项目中起到四两拨千斤的作用，当然对于一开始如何去掌握设计模式，可以以重构推演为方法，慢慢熟练后就能做到面对不同的业务场景去快速映射到使用合适的设计模式进行应用。



作为IT从业人员，我深知自己还有很多很多东西欠缺，对于互联网开发、分布式开发、中间件的使用、系统性能、可用性和可扩展性的优化等等都是需要我继续去实践和学习的。想要成为一名合格的架构师，不仅要让自己有全局思考的能力，有丰富的项目经验，更加要有扎实的刻在心里的编码基础功底，马步扎稳了，才有可能身轻如燕。希望坐着智慧老师的大船扬帆起航，带着敬畏和求知的理想走的更远。