TDD, Cache

totoo130

原文 http://www.javaeye.com/topic/21636

关于Cache部分，写了一篇
http://forum.javaeye.com/viewtopic.php?t=21631

下面写开发JPA Cache 的感受。

firebody 是一个信仰坚定，水平很高的 TDDer。
很荣幸加入他的JPA团队。让我体验了TDD，集成测试。

对TDD, test，我的看法是这样，由于目前，测试远远没有达到应该重视的程度，现阶段无论怎么强调都是不过分的。
同样，对于已经TDD已经强调够了的人们来说，也应该考虑超越TDD，而不是满足于现状。

JPA是一个相当大的项目。firebody控制的相当好。TDD功不可没。
需求分析，问题分解，to do list , test,  design, implemnent。这样的一个步骤循环，有条不稳。
在firebody控制下，我感到很放心。不用担心整个项目失去控制。

TDD的好处不用说了。我自己开发，虽然不用TDD，但是也逐渐加入了越来越多的Test，对Test越来越依赖。每次增加功能，重构，只要把几十个test （我的代码不多，而是每个test个头不小，所以test个数不多）跑一遍，green bar出现了，就心满意足的把它放在一遍，认为通过了。这是一种保障和心理安慰。

下面就说说，一些感受。为什么不能躺在TDD的成绩上睡大觉。
（
自然，一定会有TDDer出来说，那个什么什么TDD, Agile经典，早就指出了这种问题的存在，是你自己没有领悟到啊。是你自己的误解啊。自己没有用好，不能怪工具不好。
这个我当然是承认的。
任何武功达到了最高境界，都能战无不胜。
汇编绝顶高手用汇编开发应用程序，都可能比我用Java快多了。
只是我觉得，TDD是贴近实际的，并不存在很高的理论和实践门槛。
）

TDD让人们能够一次只关注一件事情，把一件事情做好。
firebody 做了一个集成测试，用来保证 Cache 的 Read Commited。

如我在那篇Cache的看法，我是觉得，这么做的必要性不大。
但是，Hibernate都做了。而且，不保证Cache 的 Read Commited，应用程序就有可能出错。
（其实，我的那篇帖子说了，保证了Cache 的 Read Commited，也一样出错。出错控制根本不在这个点上。要采用application 悲观锁或者乐观锁）

这个地方大家讨论了一下。认为做，总比不做好。多控制，总比少控制好。
那个集成测试的时间粒度非常严格。相当于记录了db server 真正commit的时间点，用来作为update time，然后和read time进行比较，来测试read dirty。
最后我采用了非常严格的 锁机制，通过了这个测试。hibernate都没有这么严格。

后面，我们考虑加入cluster support，先讨论了 cache & db transaction 的问题。还没有讨论到最关键的问题，数据通信问题。

由于严格的锁机制，还有query cache的关联实现，使得cache的内部实现，存储了很多锁数据和关联数据。
这些锁数据和关联数据，是否需要传播？
不传播，很可能可能有read dirty。传播，数据量不小。
而且，即使传播了，cluster环境下面，仍然有read dirty的问题。比如，通信时间差，通信失败，等。假如把db server time作为基准的话。
当然，这个问题肯定是可以解决的。只要高粒度级别进行同步就可以了。

现在，给我的感觉是，我们关注了太多不应该在这个点关注的事情。
（实际上，在这个层次上关注多少，也没有用）
事务冲突解决，read dirty 属于一个更高级别的处理范围。

然后，我就开始思考，是什么导致了对一个问题的过分关注，导致了over design, and over implementation。

按理来说，TDD应该是防止over design的。
现在看来，tdd一样可能出现over design。
不能说，这种情况，是因为我们需求没有分析对，造成的。上述分析至少是没有错的。

-----------

上面讲述了TDD的一个可能负面影响 -- 有可能引起对一个小问题的过度关注。
以点代面。过度关注细节，忽略了整体。丢了西瓜，捡了芝麻。当然这是极端情况。我们还没有出现这种情况。只是有这个端倪。

下面讲述TDD的另一个更明显的负面影响 -- TDDer有可能满足于毛胚实现。
TDDer可能认为test没有揭露的问题，就不是问题。需求明确了，增加了，测试增进了，才需要考虑更多的问题。
这是对的。尤其是对付客户的时候。凡事都要有个度。不然没完没了，永远无法验收。

TDD很容易令人满足。这是TDD的吸引力所在。
以前那种心里没底的感觉没有了，换上了一种踏实感。小步行走的集成测试，不断感到一种满足感和成就感。
所以，我们可以看到，TDDer是最自信的人群。踌躇满志。只要掌握了TDD利器，没有解决不了的问题。

同时，有些TDDer有这样的倾向，认为以前的设计积累，并不是那么重要。所有的知识都可以从test, refactory中来。要那些知识干啥？没有最好的技术，只有最适合的技术。最适合的技术从哪里来，当然从当前的具体项目中来。

于是，有些TDDer有意识地不把一遍能够做好的事情，一遍做好。而是满足于给出一个通过测试的最简单的毛胚实现。明知道，这个毛胚实现 80 %需要丢弃，也要这么做。理由是，永远不要去猜想用户下一步想要什么。等他要了，再给也不迟。我们是agile TDDer，拥抱变化，而不是猜测变化。
大多数情况下，很多一遍就能做好的事情，分成5遍，或者更多次反复，才最终做好。最终做好的这个版本，可能是早就知道的，但是，不能一下子做好，要让这个最终版本，浮现。

这些情况，我屡次从论坛讨论中发现，从一些项目中发现。就不针对具体人和事了。只是一个善意的提醒。
人不能满足于成绩。还要有一些挫折感。可以不时地放弃TDD一小会儿，体验一下没有TDD的挫折感，激发思考，怀念TDD，然后回到TDD，更好地使用TDD。

（
资格问题。
一定有人提出，TDD一定要实践，才有发言权。
我只有一点点实践。
但是我认为，TDD不像CMM那样，有很高的门槛。任何人都有发言权。
虽然，TDDer通常宣称，没有人逼你使用TDD啊。你可以不用啊。
这和某google员工的话一样，没有人逼你使用google啊，你可以不用啊。

这主要是一个都市话题的问题。
就比如，无极，很多人是一定要看的。是为了参与这个话题。
这个例子不恰当。
TDD不是无极，而是能够抗衡令一线开发人员痛恨的CMM的唯一利器。
两害相权，取其轻。当然要支持TDD, agile。
TDD，agile成为了一种文化，甚至一种宗教信仰。传播手段铺天盖地，甚至有传销的意味。正如任何一种新技术的传播一样。
身处其中，能不为所动吗？所以，当然要参与，当然要采用。

另，一定有人指出，tdd, agile, xp等的名词解释和细微区别。
这个我提前承认，我确实没有深入过研究过这些名词解释。
我也不打算了解。我打算继续跟着firebody了解。

前后放了这么多guard言语，说明现在说出肺腑之言多么不容易啊。还需要瞻前顾后的。防止一些一定会出现的通用模式的没有任何内容含量的反驳话语。
有内容的话语，还是欢迎的。
）