第十二章 迭进

前言：

一蹴而就的设计是危险的设计。过度设计也是不应该的，我们应该只去实现今天的用户故事，然后重构，明天再扩展系统、实现新的用户故事。这就是迭代和增量敏捷的精髓所在。

本章主要是讲如何通过遵循四个原则的迭进方式，来实现简洁的设计。
重要性从高到低排：

1. 运行所有测试

   • 再一次强调UT的重要性。UT写的越全面，越顺手，那么代码结构就越好。
   • 常说的一句话就是，如果你UT不好写，或者跑不过，那么就需要回去看看业务代码是否
   • 设计的合理或者正确。如果UT覆盖越多，设计就越好。
   • 不可以测试的系统，是永远不能部署的系统。任何设计也是如此。

2. 重构
   UT是消除了清理代码就会破坏代码的恐惧。重构或者删除代码，UT不失败。

3. 不可以重复
   对于方法中重复的部分，可以进行抽取。抽取出更小的方法或者其他新的类。

模板模式是一种很好的方式。

public abstract FatherClass{ 
    public void setUp(){
       functionOne();
         functionTwo(); 
    }
    private void functionOne(){
    ///
    }
    abstract void functionTwo();
}
public SubOneClass extends FatherClass {
    public void functionTwo(){
        //
    }
}
public SubTwoClass extends FatherClass {
    public void functionTwo(){
        //
    }
}

表达力

代码的可读性是很关键的，软件项目的主要成本在于长期的维护。可能从开发到上线商用，不需要一年时间。但是到一款产品结束商用，可能需要十年或者更长的时间。所以系统整个生命周期中，维护占据了很大的成本。前期代码表达力强,减少缺陷，可以大大减少维护成本。

1. 编写良好的单元测试也具有表达力，单元测试的主要目的之一就是通过实例起到文档的作用。
   之前听到说阅读单元测试(不是测试用例)，来理解需求，很不可思议。现在想想确实，如果一个
   UT写的够合格，那么通过读取UT，很容易了解到对应类的作用。所以UT也要尽量遵循CC原则。

2. 还有一句就是，太多的时候，我们写出能够工作的代码，就转移到下一个问题上去了，没有下足功夫调整
   代码，让后来者易于阅读。记住，下一位读代码的人，很可能是你。所以，多少尊重一下你的手艺吧。
   花一点点时间在每个函数和类上，选择较好的命名，将大函数切分为小函数，时时照拂自己创建的东西，
   用心是最珍贵的资源。

总结

后面原则需要用整个职业生涯去执行。时时照拂自己创建的东西，用心是最珍贵的资源。执行力的不同，决定了每个人不同的高度。