我想念Jim Weirich。我想念他的笑，我想念他的好脾气。最重要的是，我想念他去年和最近几年教我的东西。我感到如此失落。
　　去年Jim做了一个叫“Decoupling from Rails”的演讲，讲解了怎样去重构一个Rails框架APP，从而从Rails框架代码解耦事务逻辑。这个演讲很精彩。如果你有时间听下这个演讲，它将会给你带来很多倍的价值。
　　这个演讲的最后时刻Jim说出了他这个演讲的动机。他说：

　　一个成长的系统的Rails程序没有发现那些问题？
　　最近，我读了DHH写的《测试引起的设计损坏》。里面提到Jim的演讲，还声称Jim正在毁坏他的程序设计。

　　这不是我所见的，一点都不是。我所见的是Rails内部的密切联系和商业逻辑正在被这门技术的掌控者知晓和梳理。结果是令人满意的。在他讲座的最后，学生们开始了解到这个新结构给他们带来的所有选择。你可以看见Jim眼前一亮，当他看见他的想法被很好地传递，并扩大了学生们的研究范围，甚至比他自己的观察范围还大。
　　Jim所做的是，分离它们之间的关系，这种关系的分离是一种旧的设计原则，是由David Parnas在他1972年发表的论文里首次提及：On the Criteria To Be Used in Decomposing Systems into Modules。我认为这是一份非常值得阅读的论文。如果你认真研究，你会发现Parnas推荐的模块化方案与Jim的重购理论是一致的。
　　正如Parnas提到，分离关系的一个重要的好处就是可变性。在讲座的最后，学生们谈论，在目前解耦业务逻辑是如何被调用到服务中而不是在网络上或者如何从数据源取出数据，不同于DB。他们正在谈论易变性。
　　你怎么分离关系？你分离那些在不同时间因为不同原因、不同频率而改变的行为。聚在一起的东西你将它们放在一起。变成分开的东西你将它们保持分离。
　　那些在Rails应用的绑定商业规则到Rails框架的代码会因为不同原因和不同频率而改变，而不是因为商业规则本身而改变。将那些商业规则放到Rails控制器或Rails模型因此违反了Parnas的原则。
　　GUI在不同的频率和不同的原因下改变，而不是因为商业规则改变。数据库模式在不同的频率和不同的原因下改变，而不是因为商业规则改变。保持这些关系分离是好的设计。
　　测试是怎样在这些方面进行呢？Jim在他的演讲里几次提到，他一旦分离了关系，他可以更容易测试那些关系，测试也会跑得更快因为它没有耦合到Rails框架。DHH争辩，Jim因为注重测试速度而毁了他的设计。但是无论测试跑得多快Jim也能完成这个分离。Jim会完成它因为它提高了可变性，以及将商业规则变得比以前更清晰。Jim的分离改善了，它也没有破坏代码的设计。
　　DHH的论文最初的论题是严格实践TDD的程序员创建扭曲的形状，仅以适应测试目标的代码。在他的论文中，DHH实际并没提及这类的例子，反而在Jim的讲座中被提及过。但Jim的讲座中并没有展示有人把扭曲他们的代码。相反，这展示了忠诚的TDD用户正在极大地提高他的编码形状。
　　现在如果你分离联系，测试运行速度当然更快。原因很容易被发现。如果你不耦合到一个旋转盘，你会运行地更快。如果你不耦合到一个SQL，你会运行地更快。如果你通过网络套接字发送数据，你会运行地更快。如果你不耦合到一个需要很长装载时间的框架，你会运行地更快。你采用它。如果你不耦合它，你会运行地更快。所以如果你测试运行地很慢，这是一个提示，你还没分离它们的关系，因为你缺乏设计。
　　仅仅为了提高测试速度而去扭曲代码这可能吗？我认为有可能。我不知道那会像什么，我也不想知道。或许那就是DHH正在讨论的，而不是分离关系。然而，DHH特意地指出Jim的演讲，以及将Jim的重构描述成：“没必要的间接性和观念性的管理开销”。他提到的就是Jim的结构化的分界定义，以及他关于如何管理穿插于那些范围的依赖的理念。换句话说：关系的分离。我发现很难去接受Jim的分离被称为“变形”。
　　总而言之：对我来说，使用好的设计原则去让你的测试运行得更快是一个高尚的目标。对我来说，从诸如Rails这样的框架解耦，随着你的应用增加，这是一种明智的做法。我相信，用来证明像Jim Weirich这样的专业人士的这些内容正在奏效。