扫除你的“垃圾代码”

最近忙着充电，写读书笔记，很久没写一些关于技术的东西，今天想谈一下最近的编码过程中的一个小感悟。七条广为人知的评判代码质量的基本原则：内聚性、松耦合、零重复、封装、可测试性、可读性以及单一职责。但是，长时间的编程过程中，因为自身长期以来积累的“恶习”，在编程过程中常常并不是真正注意并遵守这些原则。最近在重构一个我很久以前用C++编写的大概1万行左右的小项目，虽然代码整体架构还算OK，这次重构不算是伤筋动骨，只是一些小手术--很多的工作在想尽办法消除代码中的重复，在重构的过程中，发现自己写的“垃圾代码”非常多，真是很“汗颜.....”。

这次重构的过程中使用了一些《软件开发沉思录》里的关于“用精炼的代码表达出简单而优美的抽象”的一些规则，现在重构结束后总算是深有感触，这些规则虽然看似简单，但是如果身体力行有一定的难度，当坚持大部分规则后（暂时实在无法坚持所有规则），代码的质量和可读性会有一个质的飞跃，这也非常大的减轻了后面测试的压力。现在想想，我们给代码测试人员留下的很多bug其实就是我们我们编码“不规范”（没有注意“精炼的代码”的重要性，也就是没有重视编程“简单性”原则）造成的。

 

这里对书中这九条规则做出简单的摘要，和大家一起分享：

规则1：方法只使用一级缩进

一个常见的原则是将方法的行数控制在5 行之内。如果每个方法都只关注一件事，而它们所在的类也只做一件事，那么你的代码就开始变化了。由于应用程序中的每个单元都变得更小了，代码的可重用性开始指数增长。一个100 行的，肩负五种不同职责的方法很难被重用。如果一个很短的方法在设置了上下文后，能够管理一个对象的状态，那么它可以应用在很多不同的上下文中。在这样短小的代码段中查找bug 通常会更加容易。

规则2：拒绝else关键字

适当地使用多态；

规则3：封装所有的原生类型和字符串

规则4：一行代码只有一个“.”运算符

规则5：不要使用缩写

缩写会令人迷惑，也容易隐藏一些更严重的问题。尽量保持类名和方法名中只包含一到两个单词，避免在名字中重复上下文的信息。

规则6：保持实体对象简单清晰

这意味着每个类的长度都不能超过50 行，每个包所包含的文件不超过10 个。代码超过50行的类所做的事情通常都不止一件，这会导致它们难以被理解和重用。小于50行代码的类还有一个妙处：它可以在一屏幕内显示。

随着类变得越来越小，职责越来越少，加之包的大小也受到限制，包中的类越来越集中，它们能够协作完成一个相同的目标。包和类一样，也应该是内聚的，有一个明确的意图。保证这些包足够小，就能让它们有一个真正的标识。

规则7：任何类中的实例变量都不要超过两个

不断应用这条规则，可以快速将一个复杂的大对象分解成为大量简单的小对象。

规则8：使用一流的集合

任何包含集合的类都不能再包含其他的成员变量。每个集合都被封装在自己的类中，这样，与集合相关的行为就有了自己的家。

规则9：不使用任何Getter/Setter/Property

如果可以从对象之外随便询问实例变量的值，那么行为与数据就不可能被封装到一处。

其实以上的9个规则就是关于“编程简单性”一个小总结，努力地拥抱“简单性”，那么开发过程会变得更愉快，代码质量提高了，测试的花费就会少了很多，其实项目的整体开发速度也会相应的提高。

PS:今天的配图，是我最近在网上看到的，个人很喜欢的一张照片，感受阳光，简单，舒服，一切都恰到好处。