窃以为软件的最大追求是在合适的地方做正确的事
前段时间读了《软件的最大追求是什么》，击节叫好，深以为然，虽然该文章很多地方显得有点极端。

    如今的软件系统越来越复杂，如果软件的结构不好会影响软件的可维护性，重构代码是一件极其痛苦的事情。

    关于软件的复杂性问题，我做了一些思考：

    1）    Cyclomatic Complexity （圈复杂性 = number of decision points +1
　　    其中number of decision points是指一个if else之类的条件判断语句
           （引自《软件的最大追求是什么》）

         if else 语句可以被行为模式/策略模式代替，不妨看下列的例子：

        假设我们要根据条件判断来完成不同的行为，用if else 是这样写的：

        main(){
           if（case A）{
                //do with strategy A
          }else(case B){
                //do with strategy B
          }else(case C){
                //do with strategy C
          }
        }


       用策略模式则如下：
    class runner{
         do();
    }

    class A extends runner{
           do(){
                //do with strategy A
           }
    }

    class B extends runner{
            do(){
                //do with strategy B
            }
    }

         class A extends runner{
            do(){
                //do with strategy C
            }
         }

    main(){
        runner.do();
    }
    用了策略模式后main()中的语句的确简单多了，再也看不到该死的if else了^_^酷～～～

    
可实际上是这样简单吗？？？仔细研究一下上面的代码就能看出问题出来，首先这两段代码中的A、B、C的实际意义是不一样的：第一段代码中ABC代表的是某
一个逻辑条件的值而第二段中的ABC则是具体的类；第二段得到如此简化的前提是它得到的逻辑条件就是一个类；如果得到的仍然只是一个逻辑条件，那么为了达
到代码简化的效果，必须由另一个类（或方法）完成这种逻辑条件到具体类的转换，会出现类似下列的代码
    class RunnerFactory{
        runner getInstante(case){
              if (case A) return new A();
              else if (case B) return new B();
              else if (case C) return new C();
        }
    }
    
从测试的角度来说，两者的测试分支都是3，复杂度相同，而第二种方法在很多的时候貌似还要测试借口的有效性。用策略模式还有一个缺点就是会使系统中的类的
数量大大的增加，如上的例子，采用if else类的数量为1，而采用策略模式的类个数为5个或6个（主要取决于逻辑映射是否用单独的类）。

    如果逻辑判断的条件有三个，每个逻辑条件有三种可能的话，用策略模式系统至少会增加10个新类；如果条件更多的话类的个数也会更多

    这么看来GOF的策略模式还要它干嘛？？

    当然不是，策略模式在很多情况下是一种非常好的解决方案。

    
这还要从if else 语句造成程序复杂以至难以维护的真正原因说起。就我个人的感觉真正造成if else语句难以维护的原因是每一个逻辑分支中的处
理语句过长。比如我现在工作中维护的代码，常常一个条件下面的业务处理语句有两三千行，每次我光确定某个逻辑分支的结束位置就要找半天，头晕－_－!。如
果是多层条件的话情况就更糟了。一个分支就一千多行，几个分支上万行自然很难维护。

    if else 
语句本质上是程序的流程控制语句，而分支中N长的代码通常是业务处理语句。行为模式/策略模式就是把流程判断和业务处理进行了一次解耦，将业务逻辑封装成
一个个单独的类。换句话说，行为模式/策略模式并不是不需要if else 语句（事实上该判断的还是要判断），只不过的换了地方或者是别的代码帮你做
了。另一方面，进行逻辑判断的语句被集中起来而不是分散在程序的各个角落，有利于逻辑本身的维护。策略模式/行为模式还有一个明显的好处就是如果新增加了
一种状态，我们只需要新增加一个策略类（同上的ABC）就可以了，避免了在程序中改动那些大段大段让人厌烦的if else 语句。

    所以对于你的程序来说到底是使用设计模式还是简单的使用if else 关键在于你的程序是否复杂，有没有必要将控制逻辑和业务逻辑进行解耦。当然如果你可以用别的方式实现解耦也是非常好的。

    2)    Response for Class(RFC)
    当一个类和很多其他类存在依赖时，它就变得复杂甚至难以修改和维护，这样，RFC值越大，表示你的系统味道越坏。（引自《软件的最大追求是什么》）

    复杂性是由类与类之间的依赖关系（dependency）造成的。具体如下所示：

    interface  Runner；

    class A implement runner{
            do(){};
        }

    一个大型的系统中很多地方用到了runner接口，于是在很多地方出现了如下的相同代码：

    {
           Runner r = new A();
           r.do();
    }
    如果因为某种原因runner接口的实现类改为B，则在所有用到runner接口的地方代码都要统统改为：
    {
        //Runner r = new A();
        Runner r = new B();
        r.do();
    }
    这些遍布系统各个角落的改动是繁琐且容易出错的。于是出现了各种框架和模式，其中最著名的当然是IOC(Inversion of Control)反转控制或者称之为依赖型注射(Dependency Injection)
    那些讨厌的代码变成了如下：
    {
            ApplicationContext ctx = new FileSystemXmlApplicationContext("spring.xml");
       Runner r = (Runner)ctx.getBean("Runner");
      r.do();
    }
    这样我们就不需要对各个角落的代码进行维护了，容器会自动的为我们选择合适的类。

    
我到觉得维护的工作还是我们的，为了让容器注射入合适的类，我们必须要维护一个叫spring.xml的配置文件，或者如果你不喜欢配置文件这个东东的话
（比如偶）就得自己写一个注册类，将依赖关系一一注册进去。你还要为使用该接口的类定义一个以该接口为参数的构造函数或者该接口的setter方法，好让
容器可以将实现类顺利的注射进来。

    该做的还是要做，只不过换了一个地方做而已。但就是换了个地方，实现了对依赖关系的集中维护（又是集中），大大的改善了系统的结构，明确了不同职责单位之间的分工。呵呵，有时自己也极端的觉得设计的工作说到底就是解决代码结构的问题^_^

    IOC一直是和轻量级框架联系在一起的。所谓的重量级框架EJB也有实现相同功能的解决方案：Service Locator

    Service Locator就是一个定位器，它维护了一个数据结构（比如一个表），通过这个定位器你可以准确的定位到你的接口想要的实现类，Service Locator同样使你免去了改变接口实现类后的维护恶梦：
    {
        Runner r = (Runner)ServiceLocator.lookup("Runner");
        r.do();
    }

    
无论是IOC还是Service Locator都帮助你维护了类之间的依赖关系。那么是否我们在编程中一定要用呢，这又是个权衡的问题，IOC带来了很
多的好处，不过我个人认为它的代码是让人费解的（你根本不知道它做了什么），并且为了用它，一方面你要借助于容器，另一方面你要编写配置文件，要为依赖型
注射提供合适的途径。

    如果你的系统类之间的依赖型错综复杂，需求的变化常常导致实现类的变化，同时你又希望采用测试驱动的快速开
发模式，IOC毫无疑问是一个完美的解决方案；如果你的系统不存在上述的问题，为什么不简简单单的在程序中写死呢，何苦去维护一堆配置文件（我所在的开发
部门貌似都比较痛恨配置文件这个东东）。Service Locator也有很多缺点，被骂的最多的就是没法快速测试。

    反转控制，即转换控制权。依赖关系控制权的转换是对代码结构的一次重构，重构的目标还是解耦，让不同的职责代码集中放到不同的地方，于是程序员可以更加专注的解决特定的问题，比如业务逻辑。

    程序设计的发展就是对代码结构的不断调整，不断解耦，让特定的代码解决特定的问题而不是什么都混在一起。从面向过程到面向对象难道不是这样吗，封装的本质也是解耦。

    
在实际问题的解决当中，最重要的信条就是合适，要记住任何结构的改进都会付出代价，你的改进是否值得你为此付出的代价。比如当你做一个嵌入式程序的时候你
首要考虑的自然是效率问题；而如果你做的是一个ERP产品，在系统设计的时候，光系统的可维护性问题就让你不得不绞尽脑汁考虑一下代码的结构。

    一句话，只做最对的。

    程序设计的最大追求就是在合适的地方做正确的事。

    语句不通顺，愿博会心一笑。欢迎交流:shenzhipeng1983@gmail.com
                                                            

                    

                                                    来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/374079/viewspace-132298/，如需转载，请注明出处，否则将追究法律责任。
                                            

                
转载于:http://blog.itpub.net/374079/viewspace-132298/

  前段时间读了《软件的最大追求是什么》，击节叫好，深以为然，虽然该文章很多地方显得有点极端。 
      如今的软件系统越来越复杂，如果软件的结构不好会影响软件的可维护性，重构代码是一件极其痛苦的事情。 
      关于软件的复杂性问题，我做了一些思考： 
      1） Cyclomatic Complexity （圈复杂性 = number of decision points +1 　　 其中number of decision points是指一个if else之类的条件判断语句 （引自《软件的最大追求是什么》）
       if else 语句可以被行为模式/策略模式代替，不妨看下列的例子： 
       假设我们要根据条件判断来完成不同的行为，用if else 是这样写的：
        main() { 
             if（case A）{ 
                            //do with strategy A 
             }else(case B){
                            //do with strategy B 
             }else(case C){ 
                           //do with strategy C 
             }
       } 
   
       用策略模式则如下： 
             class runner{ 
                    do(); 
             }
 
             class A extends runner{ 
                  do(){ 
                       //do with strategy A 
                  } 
             }
 
             class B extends runner{ 
                do(){ 
                      //do with strategy B 
                } 
             }
 
            class C extends runner { 
               do(){ 
                     //do with strategy C 
                 } 
            }
 
            main(){ 
                 runner.do(); 
           } 
 
      用了策略模式后main()中的语句的确简单多了，再也看不到该死的if else了^_^酷～～～ 
 
      可实际上是这样简单吗？？？仔细研究一下上面的代码就能看出问题出来，首先这两段代码中的A、B、C的实际意义是不一样的：第一段代码中ABC代表的是某一个逻辑条件的值而第二段中的ABC则是具体的类；第二段得到如此简化的前提是它得到的逻辑条件就是一个类；如果得到的仍然只是一个逻辑条件，那么为了达到代码简化的效果，必须由另一个类（或方法）完成这种逻辑条件到具体类的转换，会出现类似下列的代码
      class RunnerFactory{ 
             runner getInstante(case){ 
                    if (case A) return new A(); 
                    else if (case B) return new B(); 
                    else if (case C) return new C(); } }
 
       从测试的角度来说，两者的测试分支都是3，复杂度相同，而第二种方法在很多的时候貌似还要测试借口的有效性。用策略模式还有一个缺点就是会使系统中的类的数量大大的增加，如上的例子，采用if else类的数量为1，而采用策略模式的类个数为5个或6个（主要取决于逻辑映射是否用单独的类）。 
      如果逻辑判断的条件有三个，每个逻辑条件有三种可能的话，用策略模式系统至少会增加10个新类；如果条件更多的话类的个数也会更多 这么看来GOF的策略模式还要它干嘛？？ 
       当然不是，策略模式在很多情况下是一种非常好的解决方案。 
      这还要从if else 语句造成程序复杂以至难以维护的真正原因说起。就我个人的感觉真正造成if else语句难以维护的原因是每一个逻辑分支中的处理语句过长。比如我现在工作中维护的代码，常常一个条件下面的业务处理语句有两三千行，每次我光确定某个逻辑分支的结束位置就要找半天，头晕－_－!。如果是多层条件的话情况就更糟了。一个分支就一千多行，几个分支上万行自然很难维护。 if else 语句本质上是程序的流程控制语句，而分支中N长的代码通常是业务处理语句。
      行为模式/策略模式就是把流程判断和业务处理进行了一次解耦，将业务逻辑封装成一个个单独的类。换句话说，行为模式/策略模式并不是不需要if else 语句（事实上该判断的还是要判断），只不过的换了地方或者是别的代码帮你做了。另一方面，进行逻辑判断的语句被集中起来而不是分散在程序的各个角落，有利于逻辑本身的维护。策略模式/行为模式还有一个明显的好处就是如果新增加了一种状态，我们只需要新增加一个策略类（同上的ABC）就可以了，避免了在程序中改动那些大段大段让人厌烦的if else 语句。 
       所以对于你的程序来说到底是使用设计模式还是简单的使用if else 关键在于你的程序是否复杂，有没有必要将控制逻辑和业务逻辑进行解耦。当然如果你可以用别的方式实现解耦也是非常好的。
 
       2) Response for Class(RFC) 当一个类和很多其他类存在依赖时，它就变得复杂甚至难以修改和维护，这样，RFC值越大，表示你的系统味道越坏。（引自《软件的最大追求是什么》） 
 
        复杂性是由类与类之间的依赖关系（dependency）造成的。
        具体如下所示：
         interface Runner； 
        class A implement runner{ do(){}; } 
 
        一个大型的系统中很多地方用到了runner接口，于是在很多地方出现了如下的相同代码：       
        { 
            Runner r = new A(); 
            r.do(); 
        }
 
        如果因为某种原因runner接口的实现类改为B，则在所有用到runner接口的地方代码都要统统改为： 
       {
        //Runner r = new A(); 
        Runner r = new B(); r.do(); 
      } 
 
      这些遍布系统各个角落的改动是繁琐且容易出错的。
      于是出现了各种框架和模式，其中最著名的当然是IOC(Inversion of Control)反转控制或者称之为依赖型注射(Dependency Injection) 那些讨厌的代码变成了如下： 
      { 
            ApplicationContext ctx = new FileSystemXmlApplicationContext("spring.xml"); 
            Runner r = (Runner)ctx.getBean("Runner"); 
            r.do(); 
      } 
 
      这样我们就不需要对各个角落的代码进行维护了，容器会自动的为我们选择合适的类。
      我到觉得维护的工作还是我们的，为了让容器注射入合适的类，我们必须要维护一个叫spring.xml的配置文件，或者如果你不喜欢配置文件这个东东的话（比如偶）就得自己写一个注册类，将依赖关系一一注册进去。你还要为使用该接口的类定义一个以该接口为参数的构造函数或者该接口的setter方法，好让容器可以将实现类顺利的注射进来。 
      该做的还是要做，只不过换了一个地方做而已。但就是换了个地方，实现了对依赖关系的集中维护（又是集中），大大的改善了系统的结构，明确了不同职责单位之间的分工。呵呵，有时自己也极端的觉得设计的工作说到底就是解决代码结构的问题^_^ 
 
      IOC一直是和轻量级框架联系在一起的。所谓的重量级框架EJB也有实现相同功能的解决方案：Service Locator Service Locator就是一个定位器，它维护了一个数据结构（比如一个表），通过这个定位器你可以准确的定位到你的接口想要的实现类，Service Locator同样使你免去了改变接口实现类后的维护恶梦： 
     { 
            Runner r = (Runner)ServiceLocator.lookup("Runner"); 
            r.do(); 
      }
 
       无论是IOC还是Service Locator都帮助你维护了类之间的依赖关系。那么是否我们在编程中一定要用呢，这又是个权衡的问题，IOC带来了很多的好处，不过我个人认为它的代码是让人费解的（你根本不知道它做了什么），并且为了用它，一方面你要借助于容器，另一方面你要编写配置文件，要为依赖型注射提供合适的途径。 
        如果你的系统类之间的依赖型错综复杂，需求的变化常常导致实现类的变化，同时你又希望采用测试驱动的快速开发模式，IOC毫无疑问是一个完美的解决方案；如果你的系统不存在上述的问题，为什么不简简单单的在程序中写死呢，何苦去维护一堆配置文件（我所在的开发部门貌似都比较痛恨配置文件这个东东）。Service Locator也有很多缺点，被骂的最多的就是没法快速测试。 
       反转控制，即转换控制权。依赖关系控制权的转换是对代码结构的一次重构，重构的目标还是解耦，让不同的职责代码集中放到不同的地方，于是程序员可以更加专注的解决特定的问题，比如业务逻辑。 
      程序设计的发展就是对代码结构的不断调整，不断解耦，让特定的代码解决特定的问题而不是什么都混在一起。从面向过程到面向对象难道不是这样吗，封装的本质也是解耦。 
 
      在实际问题的解决当中，最重要的信条就是合适，要记住任何结构的改进都会付出代价，你的改进是否值得你为此付出的代价。比如当你做一个嵌入式程序的时候你首要考虑的自然是效率问题；而如果你做的是一个ERP产品，在系统设计的时候，光系统的可维护性问题就让你不得不绞尽脑汁考虑一下代码的结构。 
 
      一句话，只做最对的。 
      程序设计的最大追求就是在合适的地方做正确的事。 
      欢迎交流：shenzhipeng1983@gmail.com
                                                                                                                                                        ppshen

电影《雨人》中的低能哥哥雷蒙是一个自闭症患者，所以行为举止和常人有些不太一样。他总是在固定的时间做固定的事，在固定时间看固定电视节目，在固定时间吃固定食谱中的菜，在固定的时间上床睡觉，而且只穿从固定一个商店购买的某一固定款式的平角内裤。但更为惊人的还不是这些，而是他过目不忘的本事。
他可以准确报出飞行史上所有重大空难发生的航班班次、时间、地点、原因；能迅速地数清掉落在餐厅地板上的246根牙签；能轻松地记住电话簿上任意一个读过的电话号码；心算速度不亚于计算器。而这些都是我们日常生活中无法轻易完成的。
甚至有网友羡慕地说：“我要是能拥有这样的本领就好了”。
前两天，有位朋友说他们家儿子背书把他给急死了，课文念了一遍又一遍，时间一分一秒地过去，看上去也背得挺认真，可怎么一到完整背诵的时候，总是掉链子，不是忘了前面，就是忘了后面。这都快成了朋友的心病，每天下班回来一听到儿子说要背书，背后就嗖嗖地冒冷汗。所以，他就问我，有没有什么好的背书方法。
其实，就像电影《雨人》中哥哥雷蒙的原型金·皮克这类人，天生就拥有超强的记忆力，根本不需要进行记忆力训练。他在18个月大的时候，就能把父母才诵读过的书籍，立即复述出来。但对于大多数人而言，要提高记忆力，训练是不可少的，因为记忆没有捷径。
记忆的方法
如今市面上关于记忆的书籍多如牛毛，改善记忆的方法也非常之多，除去通过调整生活方式改善记忆外(主要是说大脑需要哪些营养、吃什么食物、睡眠的重要性以及如何养成良好的睡眠习惯，如多吃蔬菜、不要忘记吃早餐、睡觉前不要玩手机等等)，大致上可分为两类，一种是通过人工体系改善记忆，还有一种是遵循心理学原理改善记忆。
通过人工体系改善记忆，主要是介绍各种人工构建的记忆体系以及使用方法。例如，希腊诗人西蒙尼特斯创建的“专题系统”。他让学生们想象出一座巨大的楼房，将每个房间、大厅可视化，把要记忆的事物放置于其中，当需要时再回到房间里去找。
遵循心理学原理改善记忆，主要是讲如何在赫尔维修斯提出的自然体系上，用心理学的方法更好地记忆。赫尔维修斯认为改善记忆的三个关键是：1、多用，多练，多重复；2、关注和兴趣；3、巧妙的关联。
两者的区别在于前者可能要花更多时间先记忆人工体系，等到把人工体系记熟了就可以记新的知识；而后者则跟我们平时记忆一样，只是提供了一些常用的记忆方法。
这两类记忆法，对于大多数孩子来讲后者可能更为实用，也是暖爸下面要与大家分享的。这类记忆法看上去比较普通，却实实在在能让孩子提高记忆力。
潜意识的秘密
尽管现代记忆研究时间并不长，就像玛格丽特·W·马特林在《认知心理学》中所说：“人类记忆的研究在20世纪20年代末开始形成”，但记忆的秘密已经像画卷一般逐渐向人类展开。
洛克在《人类理解论》中这样描述记忆：
“记忆是一种将我们脑海中曾经留下印象而又消失不见，或者曾经过目的概念在大脑中复活的能力。”
新心理学对记忆的定义则更进一步：
大脑接收并储存各种感官印象和想法的活动，直到它们将来被有意或无意地想起。
大脑的意识之外存在着一片广大的区域，被称为“潜意识”，而记忆正是储存于这片区域。我们所经历过、思考过和已知的一切事物都被记录在这里。有人说：你的气质里，藏着你读过的书，和走过的路。你孩子身上所散发的独特味道，其实都是由潜意识指挥着的。你孩子的潜意识里若充满了抱怨，他就会说抱怨的话；若是充满了爱，就会说出友爱的话。有什么样的输入，就会有什么样的输出。
如果输入的印象越深刻、清晰，保存在潜意识里的信息也就越清晰，输出也就越清晰；反之亦然。而想让输入变得清晰，就需要提升注意力；想要快速输出，则需要学会运用关联。
提升注意力
记得小学三年级的时候，我还没有学过记忆法，不过那时我总可以记住老师说“这道题可能会考”的题。后来我分析了一下原因，可能是因为当老师说“这道题可能会考”，我的注意力瞬间就特别得集中，所以记得特别快，并且一旦记住以后，不需要太多复习，考试时一看到题，脑海中立马浮现出这道题的答案。
注意力在记忆中有着至关重要的作用。
11月26日，世界记忆大师王峰在复旦分享了他对战德国记忆之王西蒙的心理历程。三年前，他在世界记忆大赛拿冠军时的纪录是24秒，而目前西蒙的纪录已经到了17.6秒。在只有两个月备战的情况下，他把自己关了起来，与世隔绝。他说，排除干扰，绝对地集中注意力才有助于提高记忆。最终，经过两个月的训练，王峰赢得了这次比赛。
塔珀说：“记忆是注意力的女儿，智慧的母亲。”注意的程度越高，留下的印象就越深。以上两个案例只是为了说明注意力对于记忆的重要性。
可是，要怎样才能提高注意力呢？
一、兴趣。人往往对自己不感兴趣的东西缺乏注意，但很奇怪的是，兴趣能够通过多注意而渐渐产生。如果，当你的孩子刻意重复地注意某件事时，兴趣很可能随之而来了。所以到这里，也许你已经知道如果一个孩子说，我对学英语没兴趣，一定是因为他对这件事缺乏注意，所以父母只要想办法让孩子多注意到英语，就能逐渐让孩子对英语产生兴趣。例如，父母有意无意地当着孩子的面分享英语小故事、小玩笑，或者谈论学会英语的好处等等，让孩子不自觉得就注意到英语。一段时间以后，他会逐渐产生兴趣或者至少没有这么反感，能主动地去注意英语相关的信息。
二、细节。等过了被动注意的阶段，孩子就开始进入主动注意的阶段。但要真正让孩子对这个事物投入更高度地注意，就需要让孩子付出一些时间用来练习。你得告诉孩子，想真正了解这个事物，你需要付出相应的努力，可能刚开始的时候会有一些困难，但过后你就会变得非常轻松。这个阶段的练习，已经不是停留在分享小故事了，而是需要更全面深入地让孩子注意到这个事物的细节。以一本书为例，你要让孩子注意到这本书共有多少页，多少个章节，每个章节有多少页，这本书的标题、印刷、装订等所有细节。一开始孩子会觉得有些枯燥，但练习不多久后，他会产生更浓厚的兴趣。
接下来，我们来实战模拟一下，假设这个孩子对背诵语文课文没有兴趣。那么，就可以判断出，孩子对语文课文中的细节注意并不多。于是，父母就可以想方设法从语文课文中找到有趣的句子、词语或者桥段，并在孩子面前谈笑风生，引起孩子对于课文中有趣事物的注意。一段时间候，他也许会趁父母不注意自己去寻找有趣的片段，说不定还会主动和父母分享。等到孩子有了这样的意识，会主动去注意后，我们就可以知道孩子已经有了兴趣。然后，就按照第二部分细节中所讲的去做就可以了。
此时，孩子的注意力一定会有显著的提升。但以上的情况是针对年龄较小的孩子，等到孩子再大一些，他还需要学会的是主动关注原本不感兴趣的事物，让自己瞬间处于对这个事物感兴趣的状态，这样他就能够轻松地对这个事物产生高度的注意力。
小时候的记忆
如何关联
注意力的训练是让孩子能够学会通过对于细节的观察，把对事物的印象更清晰、完整地保存到大脑中，可是仅仅保存到大脑中，这是不够的，还需要让孩子学会从大脑中把所保存的印象更快地提取出来。这就需要让孩子学会关联，新的记忆一旦与旧有的记忆关联，提取出来就方便多了。
记忆研究专家凯如此说：
“为了将记忆中的内容重新召回意识里，被召回的对象必须和一个或多个事物及想法发生关联，而与之关联的事物越多，被召回的可能性就越大。”
如果把旧有的记忆比作吸铁石，新的记忆比作铁，那么吸铁石的吸力就可以看成是关联的动作。想要让铁被吸铁石吸得更牢、更快，就需要让吸铁石的吸力变强。怎么样增强吸铁石的吸力呢？
有两个法则可供参考：1、相似性；2、连续性。
相似性：所记忆的事物能与原有的记忆找到更多的相似点，那么它将更容易被记忆。例如英语单词：pineapple，pine是松果，apple是苹果，如果孩子不认识松果，但认识苹果，那么只要告诉孩子pine是松果的意思，pineapple也就知道是什么意思了。长得像松果的苹果，就是菠萝。以后孩子只要记得pine是什么意思，就不会忘记pineapple的意思。这就是运用pineapple这个新单词与apple这个旧有单词的相似性，使单词更容易被记忆。
特别是在遇到新知识时，不要一味都去记忆，而是要通过观察，找一找是不是和原有的知识有相似处，将新的知识与旧有的知识进行巧妙地关联后，新的知识就会很快被记住。
连续性：使用连续性其实和相似性有共通之处，就是要会调用一切本领，使新的知识与旧的知识进行关联。连续性主要用在两个方面，一个是空间上，一个是时间上。两者都是根据记忆的先后顺序，一个是按着地理位置上的顺序，一个是按着某种思维、想法或感觉的顺序。
空间上，例如邮局后面是宾馆、宾馆后面有个沙县小吃、沙县小吃的后面有个公共厕所，类似这样按着一定空间的顺序，在记忆上会比较容易记住，因为他们是有连续性的，是按着某种顺序连下去的。所以，如果是记忆空间上的事物，不妨与原有的记忆按着某种连续的顺序进行关联，就很容易将其记住。
时间上，例如字母表：“abcdefg……”。有时候孩子已经记住整体的字母表了，但当你问他g后面是什么字母，他可能答不上来，这是因为将连续性的事物作为一个整体时，记忆会变得更容易，单独的记忆则相对困难。所以，给孩子一点时间，让他念一遍整体，念到g时，他自然想起了后面的字母h。
当孩子记忆某个信息时，告诉孩子不要单独去记忆，而是要与前面的连成一片，这样记忆会变得更简单。
我们来实战模拟一下，例如孩子要记忆《赠汪伦》这首诗。
李白乘舟将欲行，忽闻岸上踏歌声。
桃花潭水深千尺，不及汪伦送我情。
诗句的前两句，是有连续性动作的，“欲行”和“忽闻”，就是要走的时候，忽然听见。可以试着把孩子的名字代进去，他会很快理解并记住这两个动作的前后顺序，随后多念几遍也就完整记住前两句了。
接下来的诗句，也是连续性的。是因为听到了岸上传来的歌声，回过头看到了为他送行的好友汪伦，才作出了感叹：桃花潭的水虽然深，但是不及汪伦送我的情。
如果不按连续性的方法去记忆，单纯地光是念，或者不刻意去关联也能记住，但没有按连续性的方法进行关联更容易记忆。
注意：
1、对于原本没有太多旧知识储备的孩子，不要太过着急。越着急，孩子越记不住。随着知识量的增加，练习的深入，孩子的记忆将会越来越快，越来越准确。所以，对于记忆不佳的孩子，父母前期要作好跑马拉松的准备。
2、还有一点要说的是：旧的知识一定要经常复习，直至深深的印在孩子的脑海里，若干年以后还能迅速准确地回忆起来，这就说明旧知识孩子已经彻底记住了。原有旧知识的储量越大，新知识的记忆就越容易。对于如何复习更好，详见学会“温故而知新”，将不断有活水从孩子们的心里涌出。
3、给孩子定适当的小目标，而不是不切实际的目标，只要有一点进步就可以，有时的退步完全是可以接受的。只要保持总体在进步即可。
如此，虽然不一定能赶上雷蒙，但孩子的记忆一定能有明显地改善。最后，再用两个短语强调一遍记忆的关键：花时间注意细节、花时间去关联。越肯花时间在这两件事上，以后的记忆将越轻松。
参考书目：
《超神奇记忆术》美 威廉·W·阿特金森
《记忆圣经——20个人类记忆模式的根本方法》美 吉妮·格拉汉姆·斯科特

一、人员
  首先，在影响产品长期扩展性的因素中，"人员"是最重要的因素。其一是，没有人就没有扩展性这个问题；其二是，所有的产品都需要依靠人去架构系统、研发、运营，扩展性强的产品一定是一群合适的人在合适的时间做正确的事形成的。（案例：乔布斯被苹果公司开除，后续重新被雇佣的故事。）
  其次，不管一个人技术有多么牛，一个人的力量总是有限的，如果他不能和其它人有很好的合作，影响团队的整体产出，那么他/她的存在就对团队的负面影响要大于正面，应采取除草计划把这样的人及早的清理出团队。然而现实中多数公司领导更重视招聘工作，辞退员工更多是出于经济压力。

二、组织
  人是影响产品扩展性的最重要因素，从上述的文字中我们已经论证。但在一个分工精细的时代，完成一件事情往往需要很多人齐心合作，怎样把这些人组织起来、组织好就显得至关重要。为了更好的理解组织的概念，我总结了下面三条：
  第一、组织的扩展性表现在是否支持增加少量或大量的额外人手到现有的团队中或形成新的团队，当公司景况不佳的时候灵活地缩小组织规模。
  第二、组织的产出取决于规模（多少人工作）和效率（每个人的产出），所以管理组织就需要有关键性指标来度量组织的产出和工作的质量。简而言之管理需要度量，度量失败时就无法应对快速发展带来的问题。当组织的人数较多时，授权问题、组织内部冲突问题（情感型和认知型两种冲突类型）、组织产出与个人产出之间的关系问题都需要加以考虑。
  第三、成功地设计一个组织，首先必须弄清楚组织的产出、目标是什么；其次需要了解组织是如何对期望值产生正面或者负面影响的(如：组织对内部创新是促进还是阻碍作用、对产品上线起到促进还是阻碍作用、流程在组织内是否很容易流转等)。组织的设置也不是一蹴而就的事情，后续还会再铺开陈述。
  案例：亚马逊著名的“两张比萨团队”的规则是“任何一个团队的规模不能大过两张比萨所能喂饱的人数”，这样沟通主要发生在团队内部，额外的沟通负担就会大大减少，团队间情感冲突程度也大大降低，同时团队拥有足够的授权来完成目标。通过学习亚马逊的案例，我们很容易理解什么是高效的组织，应该如何设计一个扩展性强的组织。
三、管理和领导
  好的领导和管理能够聚焦打造出具有高扩展性的组织、流程和产品。在我国，大多数理工科的毕业生从来没有接触过管理学和领导方面的培训，基本都是从基本的独立技术贡献者起步，从工作中不断学习才逐步发展成为初级管理者，假以时日承担了更多的领导职责。但我们也应该明白，技术上比较牛的人，管理未必就做的好。因为技术是一种相对较为死板的知识，只要勤奋好学就可以掌握，而管理是把一群人有效的整合起来，需要的方式方法完全不同于技术管理。糟糕的任命会使技术大牛在管理岗位上一塌糊涂，同时也荒废了他技术的沉淀。
  虽然管理和领导经常同时出现，但它们对扩展性的影响大相径庭。总的来说，管理是与“推”相关的活动，而领导是与“拉”相关的活动。如果一个人聚焦在事务处理方面，那么他就是管理者，如果一个人更具有远见卓识，那么他就是一个领导。管理好比是推动组织爬坡，而领导就是选择山头。
  组织管理必然绕不开“授权”这个话题。管理和领导工作，都必须得到上级的充分信任和授权，否则只能是按照上级的要求去管理，久而久之个人的领导力也会受到影响。充分的信任和授权，才能为管理者营造一个好的环境和舞台。
  关于领导和管理的内容还有很多，后续单独开篇进行总结。
  最后，如果这篇文章对您有益，给我点个赞吧。💗