设计模式总结

设计模式实践中的要点：

1.通常由一个模板，定义程序的骨架流程（这需要对业务了解得比较透彻，捕捉到不变的东西，如果流程没定好，后面要变，将是大手术，老板（花钱）和程序员（加班）都会要为此付出惨痛的代价）。

2.骨架流程里具体的步骤，要使用到的组件，都抽象成接口（可以更换具体实现策略）。

3.对于组件接口，具体类型的获得，就可以有多种途径，视情况而定。

   简单的，直接new一个；

   复杂点，可以用简单工厂去生产；

   再复杂点，工厂build，来构建复杂工厂，创建更复杂的对象。

   甚至，可以弄个rpc的代理对象，利用本机以外的机器资源。（分布式系统，就是这么起源的吧，ejb的出生和这个差不多。---这个差不多，就需要一点架构的思维和能力了，因为，要在比较高的层次，做分布式组件的划分）

每一个流程，对象的设计，特别是最顶层的设计，都要谨慎，要可读，易扩展。抽象的好坏，会直接影响到扩展性，这就需要考虑到设计的几个基本原则solid。

基本上，上面说的做得比较好的话，程序或软件就不会出大的问题。其他的设计模式，基本就是在局部使用。

当在写代码的时候，碰到在重复写类似代码的时候，就要提取和抽象，来增强代码的重用，可维护，可扩展性。通过对同一类的业务，以前代码写得比较多的时候，就能提前预见，要怎么写比较好，这也是工作经验的一部分，能无形中减少折腾的成本。

多看和理解设计模式，但不在生硬的去套，需要的时候才用，套出来的设计模式，自己看上去很高端，其实后面维护的人，看了一脸蒙逼（我接手过一些维护性的项目，说那啥 想死的心都有了，代码真是难读）。

还有就是有多去看一些开源项目的原理，看了原理之后，再去里面看看关键的源码，印证自己学到的东西，同时也能够有能力对框架，做一些定制，扩展有二次开发。

技术的水很深，最近看到讲阿里的多隆视频，称之为神的人，都说，其实他也有很多没有解决的问题，神只是个传说，谦虚，多学多总结，是王道。

相关的题外话：

    从架构层面，如何做系统的技术规划。

    做新系统：

        新系统，首先从分析，归纳出核心业务流程，围绕核心业务流程，来初步分解和设计组成系统的模块/组件/系统。分解完后的模块/组件/系统要能够做到，用文字可以描述清楚，它的职责，并用总结性的文字和交互图，描述整个大系统的流程。这个过程需要，业务，产品，架构师，高级开发来参与讨论，由架构师主导。架构师根据模块/组件/系统的业务特点选用与团队技术储备匹配的技术，描述模块/组件/系统具体的交互机制。完成后的架构，要能方便的运维和运营。

       除了与当前业务阶段紧密相关的系统外，架构师还需要规划业务后期的配套基础服务和技术储备。目前，各行各业的发展，都很快，产生数据的速度和量都很大，一般后期都会需要规划大数据，流式分析等用于经营决策，在数据上，为改善和提升用户体验给出适当的建议。一开始，不需马上要做这些，只做个规划就好了。因为，这方面的人才相对比较少，各方面的成本也大，可以在业务发展过程中，在现有团队中，进行培养。在适当的业务阶段，进行实施。

  

   接手老系统：

        如果接手的是老系统，首先除了要快速了解业务知识外，还要快速的熟悉业务系统。然后，就是按照业务目标的重要程度，分步做系统优化。系统优化可以理解为，解决技术负债，做新系统的时候，理解不全面，时间紧，当时会做一些折衷的方案，后面没时间再修改。既然是债，就总是要还的。分小步快走，是最合适的方式。一次改动太多，容易出大问题。每次改完上线，最好做个开关之类的，同时，慢慢切流量，稳定后，再完全切换。老系统上，再做新项目，就和做新系统的套路一样了。

    架构师需要有广阔的知识面，在系统交互方面要有一定的技术深度。我想好的架构师，需要在，业务，产品，架构，技术，带技术团队方面都要具备一定的能力，路很长，偶正在路上。

     技术的价值在于，在节省成本的前提下，能支持业务的快速发展。