TDD, Cache

关于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。:D
TDD，agile成为了一种文化，甚至一种宗教信仰。传播手段铺天盖地，甚至有传销的意味。正如任何一种新技术的传播一样。
身处其中，能不为所动吗？所以，当然要参与，当然要采用。

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

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

最近是老眼混花了,
一个贴子一遍读下来,总是不知所云.

:oops:

表达能力问题。
自己对一个问题没有理解透，说起来就没有条理。
俺也曾经写过条理清楚的帖子啊。不过，越来越少了。
唉，这个世界变化快啊，跟不上了。

　　如果是行业应用项目，如果在市场需求变更和进度压迫之下，如果还能这么从容，那才是高手。

看得直后悔，早知当初便入了伙，每日里只大口吃酒，大块测试，岂不快活？ 也可学他些tdd的手段耍耍。

俺也想大口喝酒,大快测试,耍耍tdd,有人收吗?

我现在就是顶着ajoo 的名头进行check in。

横议：赚卢俊义上山
http://culture.163.com/06/0523/10/2HQ403FF00281M76.html

今天，开了一个长会。分出两个阵营。
新新人类，firebody, nihongye代表了最先进的生产力，TDDer。
我作为食古不化的老一辈工作者，代表了过时的 Bottom Up Designer。

下面是我的设计和开发ORM的思路:
需求细分一开始尽量做到底，能细致详细到什么程度，就做到什么程度。
然后根据这些细致需求的考虑实现，并识别变化最小的、最关键的功能作为优先级最高的核心模块。
把这些识别出来的核心模块按照优先级排序，优先级越高的，越放在前面实现。
实现的方法，采用TDD，越核心，功能和性能测试就越密集。重构，review也应该最密集。
集成部分，组合部分等次要功能最后考虑，花少量的时间，匆匆完成即可。
比如，orm里面，
sql composer 是实现 embeding class, 1 to 1, 1 to n, batch lazy load, multi tables, native sql support 等关键功能的核心模块。
这些地方是体现orm品质的关键特性。应该最先实现，而且拼命测试，完善功能，和提高性能。

其余的glue, 规范adapter部分，parser, config, 最后匆匆凑合攒出来就行。做几个简单的集成测试，就可以。

理由是:
好钢应该用在刀刃上。最关键的功能，应该贯穿始终，从头就开始考虑。
越底层的需求，变化越小。越上层的需求，变化越大。
这样可以保证，总体上的代码重构率减少。
（
重构率其实就是废弃率。
当然TDDer认为是可喜的演进。
还是上面的老话重复，TDD有可能带来这样的负面影响。
每次设计实现的起点，都是从 0 开始。
然后，每次都是同样的可喜的演进，和同样的满足感。
）

firebody, nihongye的反驳意见是:
核心模块为什么不在外围模块实现的重构中，浮现出来？先做，后做，没有区别。
而且，先做，肯定要 over design。
另外，这种方法忽略了总体的集成测试，不能很好保证持续集成。

最终，求同存异。
每种过程都有各自的优缺点。

问：你与你父母经常交流吗？你们有没有代沟？想不想填平？怎样填平？
答：当然有代沟。没有代沟的时代是木发展的时代。为什么要填平？要么你被父母同化， 要么父母被你同化。你以为填代沟是填阴沟啊？

-----

下面是我的想当然的总结。

TDD 和 Bottom Up Design 的基本开发方式都是大同小异。
都是代码先行，agile，也可以都是 测试先行。

主要区别在于，模块层次的实现顺序不同。
TDD 的 to do list 实现过程是 Top Down。最先实现外层，上层模块。

另外一个主要区别在于，积累的主要目标和结果不同。

一个项目过后，
Bottom Up 主要总结和积累的是设计经验。
TDD 主要总结和积累的是过程管理经验。

注意，主要这个词。
每个过程当然各方面经验都积累。只是侧重点不同。

Bottom Up Design 的风险很明显。慎用。



必须花费很大的精力时间代价，研究学习比较现有的同类实现方案。
之后，才能够识别出真正有用的底层核心模块。

这个"识别"能力的练成，非一日之功。
所以说，Bottom Up Design 的主要积累目标是，设计经验。

呀呀，还漏了一个我的问题:

睡醒了。buaawhl忽视集成啊。不如让firebody说下jpa的selecter的开发过程。