之前已经参加过一次公司内部的重构培训,当时讲的冰山模型的概念,即内部质量和外部质量的比例,这一次的讲师又强调了一下这一点,这个模型看起来是不错的。但是真正在实际开发中,这个又是显得比较理想化了,生产环境下面为了需求而开发功能,不会考虑什么之后改的时候好不好改,比较好的就是我这种新人,在一年之内参加了两次这样的培训。从头做起,所以这一次的培训中的案例重构过程中,我们小组频频得奖的原因。
本次收获的主要有几句大师的话,总结成自己的话就是:
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. 心态:专注并怀有谦卑的心态(不开快车)