之前已经参加过一次公司内部的重构培训，当时讲的冰山模型的概念，即内部质量和外部质量的比例，这一次的讲师又强调了一下这一点，这个模型看起来是不错的。但是真正在实际开发中，这个又是显得比较理想化了，生产环境下面为了需求而开发功能，不会考虑什么之后改的时候好不好改，比较好的就是我这种新人，在一年之内参加了两次这样的培训。从头做起，所以这一次的培训中的案例重构过程中，我们小组频频得奖的原因。
本次收获的主要有几句大师的话，总结成自己的话就是:
1. 开车稳点，别太着急，别开快车，不需要飙车炫技。车开的太快我们知道容易发生事故，写代码也是同理，复杂的程序和语句就像是我们开快车一样。一个包含77个if-else语句的程序，让谁看谁都不愿意看，一个for里面包含while在包含for的程序，也是谁的不愿意维护的，还记得刚进公司的时候，有位同事说维护一个3K的存储过程，根本不敢改，阅读，理解需要花费很长很长的时间。
2. 简单、简单、就是简单。代码是给人看的，如果不是给人看的话，可以像一些高手直接去写java字节码去，这些都是可以的。但是大部分程序都是业务程序，需求多，任务重。大多数时间都是重复的代码，或者逻辑，或者增删改查。但是如果我们把这些简单的任务加以抽象，提取共同点，那么是不是改起来更加简单呢。如果阅读代码像阅读优秀的文章一样有条有理的，我们每个人是不是不会再去看代码的时候骂那位写代码的人了么
3. 价值观决定行为。 这句话在入职的时候经理专门开了个会，给部门所有人讲了这个概念，并且每个人桌子上面也有了对应的标语。但是真正做的有谁呢？几乎是没人，代码还是一样的烂，每次看了很气，但是烦死一下自己的代码有时候也是那么烂，心情不好了写的就烂，五十步笑百步。
4 好代码不是坏代码。 给我的感触最新的就是这句话，说的就是坏代码是可以量化的，我们可以找出那些是坏代码的指标。
本次我也就我自己找出十个可量化的指标，不是对每个人都是适合的，因为有一些规范我已经不会再去写了，比如魔法树，if的{}号。
1. 函数：不超过50行
2. 函数：一行代码只做一件事
3. 函数：不返回null，不传递null
4. 函数：不过度追寻单一出口原则
5. 函数：public方法写成一个目录
6. 分支：if尽量用肯定句
7. 变量：命名不用not、no，作用域尽量小
8. 测试：多写些临界条件的测试（至少三处）（勤修车）
9. 性能：不测试情况下不判断程序性能( 不开早车 )
10. 心态：专注并怀有谦卑的心态（不开快车）
