读《重构与模式》所想（二）

代码坏味

    书中开头如是说：当你学会用挑剔的眼光审视自己所写的文字时，会发现将一段文字反复读上五六遍，每次都会找到新的问题。书的这种写法甚合我意。在《代码大全》中将这种方式成为隐喻。形象的隐喻描述了软件领域中各种特定的现象和事物。生动活泼的隐喻能够描述广泛的现象。借助隐喻，我们能更深刻地理解软件开发的过程。将书写到这种程度，我辈也只能是望其项背了。

    因为我常喜欢写点东西，虽然写得不很好。但是，书读到这里。我对什么是代码坏味儿，其实已经有了些感性的认识。我们说书读百遍，其意自现。一个东西见得多了，自然就熟习，便知其中真意，我们可以用很多不同的方式表达出来了。代码同样如此，我们写一段让计算机明白的符号。而这符号中所承载的是我们自己的思想。如此，让计算机完成了我们打算做的事情。而这符号也有多种写法，跟我们常用的语言文字一样。我们要做的是让这些符号更加的简洁（最好无重复），清晰，而且不复杂。这样的代码我们说是没有坏味儿的代码。（如同，我们不希望有人天天在我们耳边唠叨-重复，希望能够听到简单而清晰的表达，此我们人之本性。）

 

几种代码坏味

    重复代码——最常见的坏味儿。分为明显的和不明显的。明显的一类，可认为是完全相同的代码。比如我们有多个地方要用到取当前的系统时间这样的代码，我们就可以将这样的代码写成一个方法来调用。而不明显的一类则是虽然代码不同，但是所完成的功能是相同的。这类是不好区分的。这样的代码想要去重复，需要我们经过精心的设计，选好接口。如此才能把他们提炼成一个类或者方法来实现。比如构造方法，很多中构造方式，我们可以提炼出一个类来。把他们放在这个类中来实现。

   方法过长——短方法胜过长方法的几个理由。最主要的是逻辑共享。两个很长的方法很可能包含包含重复代码。如果将这些方法分解为多个小方法，就能发现有很多方式能够使他们共享逻辑（事实上就是共享大段的代码）。次之，小方法可以帮助理解代码（10行以内的方法。大多数方法的代码应该只有1-5行）。如果系统的大多数方法都比较小，那么可以有少数方法稍大一些，只要它们比较容易理解，而且不包含重复代码。

   条件 逻辑太复杂——写程序的时候我常遇到这种情况。开始的时候if，else语句中的判断比较简单。但是随着需求的变化，语句中的限制条件越来越多，渐渐变得不好理解。

   

 一点理解

    代码坏味儿是我们写程序的过程中不可避免的。因此，不要因为自己写的代码回头审视简直惨不忍睹而放弃了coding。随着，我们不断的coding，我们的代码一定会变得更加的简洁，清晰。重构的过程其实是很有乐趣的，而且比我们初次创建那个不堪忍受的代码要省不少力气（这里指自己写的小的程序，如果重构别人写的冗长的代码。那你会发现比自己写都累。。。）。经过重构后的代码能够，更加的易读由此也变更好维护和扩展。