Morning@Weblog

前些天借着给新员工内培的机会向同事们推荐了老马的《重构》，今天顺便又重温了一下“Bad Smell”那一章，感觉依然还是很有收获的。重构的时机来源于“见识广博者的直觉”，比如：一个类中有多少实例变量才算太多，一个函数有多少行代码才算太长，而这种直觉是锻炼和培养出来的。想来偶尔在看同事代码时不免皱眉也是蛮有道理的，习惯成自然，看到Bad Smell就算没有“标明”，心里也会觉得不畅，总忍不住要把它改掉。老马《重构》一书的一大特色在于其技法的名称基本都可以“望文生义”，因此即使没有看过每个技法的详细说明，也已经基本能够猜个八九分了。从侯sir网站当下来的中文电子版开放了前六章，封底内页有一张Bad Smell与相应重构技法的对应表，准备将它打印出来贴到我的办公桌旁，作为时时提醒之用：）

[Bad Smell]
- Duplicated Code
- Long Method
- Large Class
- Long Parameter List
- Divergent Change
- Shortgun Surgery
- Feature Envy
- Data Clumps
- Primitive Obsession
- Switch Statements
- Parallel Inheritance Hierarchies
- Lazy Class
- Speculative Generality
- Temporary Field
- Message Chain
- Middle Man
- Inappropriate Intimacy
- Alternative Classes with Different Interfaces
- Incomplete Library Class
- Data Class
- Refused Bequest
- Comments

重构、好的编码习惯、设计模式的合理运用，作为开发者的基本功应该是一个持续修炼的过程，对于一个团队而言，在一定程度的掌握了这些技能之后，建立起了一定的语境，成员间的彼此技术交流就会变得更加畅快和有效率，一些分歧也会变少。大家不会因为争论一个设计或者一段代码是否合理而耗费很多无畏时间，也不会因为不合理的设计和代码而导致日后维护与更新的极度困难。并且，作为开发者来讲，个人也会从不断进步之中体会到工作的乐趣，而不是在重复单调乏味的Copy & Paste过程中逐渐消磨了自我。

昨天看到一位同事的unit test是这么写的：

if (…) {
　assertTrue(false);
}
assertTrue(true);

抛开assertTrue(true)这个“无效”语句不说，怎么看怎么觉得别扭。在JUnit中，assert有很多“变体”，灵活使用将会给TestCase的结果验证带来很好的表达能力。它们包括：

assertTrue
assertFalse
assertEquals
assertNotNull
assertNull
assertSame
assertNotSame
fail

其中，每个assert*还有一个带有message的重载方法，比如：

assertEquals(String msg, Object arg1, Object arg2);

这表示，当assert失败时，会附带一段用户友好的说明性文字。

由此，对于上述的unit test，更好的书写方式应该是：

if (…) {
　fail("…");
}

而最好应该直接写成assertTrue(…) 或者assertFalse(…)。

想不到一个小小的assert也会引出问题来。