重构代码之2-函数

函数(Java中称之为方法,由于我是一名Java程序员,所以下文就都写为函数了酷)无疑是程序员理解程序逻辑的第一手资料,同样毫无疑问让函数变得清晰,规整就成为了写好代码的关键点。如何写出一个个牛逼的函数呢?我觉得是这样的:

 1  短小精悍,只专注于一件事情。

我真的不知道我该如何用各种公式去证明这个理论的成立,但是个人觉得if,else,while这样的语句一个函数中就应该出现一次,保持函数短小,块内调用函数由于拥有较具说明性的名字(当然要是你自己命名较优雅),从而使得结构格外清晰,易读。短小精悍就意味着不应该在函数中出现大量的嵌套,缩进层级也不要多于两级,这样的函数读起来会很舒服。

一个函数就应该做一件事情,确切的说应该是一个函数就应该做一个层级上的一件事情,其实判断一个函数是否不止做了一件事情很简单,就是试图将这个函数拆分成两个函数。只有函数中的所有的语句都处于同一层级,才能将基础和细节进行合理的拆分,逻辑上也会清晰,不至于进入纠结的状态。同时代码拥有自顶向下的阅读顺序,我们在每个层级的函数后面跟随着下一抽象层级的函数,当以后查看代码时候就能循抽象层级进行阅读。

 

2  万恶的switch

说了半天函数应该专注一件事情,结果switch的存在貌似违背了这个原则,因为switch原生支持多件事情,那我们如何避开switch带来的问题呢?个人觉得像switch语句埋藏于深处,抽象层级,可以放到工厂中根据需求来生产对象。

首先看一段代码

 很清晰问题在于,如果我当前类中还有相似的方法isPayDay,deliverPay等,依然需要写各种状态的判断,同时如果增加了一个状态,必须重新每个方法。这是个在平常编码中很常见但是又很少有人解决的问题,如何解决呢看下面的代码

 其实也就是采用了接口编程的方法,屏蔽具体细节,使用类与状态判断进行一一对应,如果有新的状态引入,直接继承,重写就ok了,解了耦合,又清晰了代码。

 

3  函数参数越少越好

 参数少,首先解放的就是测试,越少的参数意味着测试更容易覆盖。

对于函数的返回值而言,如果这个函数做的是转换,那么用返回值更容易理解,如果这个函数的参数是event,或者做的是类似StringBuffer类中的append方法的事情,这样不使用返回值会更加的容易(其实是用this指针作为返回值)。

鼓励参数越少越好,如果你维护过多参数方法的代码你就会知道,需求突然说要再加一个参数,你会一直去修改方法的定义以及所有的调用,这样会让你的代码变得异常的恶心,千万不要这样做。可以把多参数抽象成为一个参数类(Point, Circle, etc)方便维护,当然最好的办法肯定是细化函数粒度,使用更少的参数。

4  函数无副作用,分清楚做什么事和回答什么事

比如说一个函数校验用户名,密码问题,就不要去做关于初始化session的问题,如果两个耦合无法拆分的话,可以破坏做一件事情的原则,但是要把函数名命名的清晰就可以了。

对于传入boolean变量作为函数的参数是要坚决杜绝的,用传入的true or false 判断做不同的事情,直接说明了就是两件事情两个函数,比如传入一个什么String "add" "modify"使用一个函数也是一样,直接就应该写成两个函数逻辑。

5  错误处理

使用异常代替返回错误码,好处就是异常类可以通过继承扩展,同时也简单明了。要注意的一点是异常是要在同一个层级处理的,不能到处都是处理异常的代码看起来会非常的混乱。异常处理本身就是一件事情,单独一块处理最好。



 

 6  避免冗余的代码

同样的代码如果写了两次,你就要考虑抽象成为一个工具类或者工具函数(方法)了,这样才不会出现修改了一处的逻辑却忘记了修改另一处,导致上线后,大把的money从你的指缝间溜走。

所谓项目重构,其实开发中很少有时间回去重构一个项目的,大部分都是开发完了就完了,所以项目是否优雅完全在于大家在平时中是否多留意,多注意,不断地改进才能不断地提高,更加值钱。

以上的这些技巧大部分都是针对大函数的,其实对于小函数可能本身就是一件事情了不需要拆分。

感谢您读完,希望共同成长。

猜你喜欢

转载自himichaelchu.iteye.com/blog/2113980