当前位置:首页 > 开发 > 编程语言 > 缓存Cache > 正文

TDD, Cache

发表于: 2006-08-02   作者:buaawhl   来源:转载   浏览次数:
摘要: 关于Cache部分,写了一篇 http://forum.iteye.com/viewtopic.php?t=21631 下面写开发JPA Cache 的感受。 firebody 是一个信仰坚定,水平很高的 TDDer。 很荣幸加入他的JPA团队。让我体验了TDD,集成测试。 对TDD, test,我的看法是这样,由于目前,测试远远没有达到应该重视的程度,现阶段无论怎么强调都是
关于Cache部分,写了一篇
http://forum.iteye.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言语,说明现在说出肺腑之言多么不容易啊。还需要瞻前顾后的。防止一些一定会出现的通用模式的没有任何内容含量的反驳话语。
有内容的话语,还是欢迎的。

TDD, Cache

  • 0

    开心

    开心

  • 0

    板砖

    板砖

  • 0

    感动

    感动

  • 0

    有用

    有用

  • 0

    疑问

    疑问

  • 0

    难过

    难过

  • 0

    无聊

    无聊

  • 0

    震惊

    震惊

推荐文章
2 tdd
3 TDD
4 TDD
5 TDD
6 TDD
7 TDD
9 @Cache
10 cache
11 cache
12 Cache
13 Cache
14 cache
15 Cache
16 cache
17 cache
18 Cache
19 Cache
20 Cache
编辑推荐
1 Cache
http://netkiller.github.com/ http://netkiller.sourceforge.net/ Cache 6.1. CDN (Content Delive
TDD的魅力 06年,我学习Ruby on Rails的时候,首次听说TDD。那时我刚刚进入软件世界,虽然很多概念
一.重构实践 实践题目:重构获取指定数值内的所有质数的方法 单元测试案例: package training.gene
一.重构实践 实践题目:重构获取指定数值内的所有质数的方法 单元测试案例: package training.gene
“我的TDD实践”系列之TDD概念篇 写在前面:   我的TDD实践这几篇文章主要是围绕测试驱动开发所展
开发现状 当新的版本快要发布的时候,大家都忙于加班,加紧修复BUG1、BUG2。我想这就是很多公司开发
作者: Todd Wei 来源: 博客园 发布时间: 2011-12-06 12:02 阅读: 904 次 原文链接 全屏阅读 [收藏]
InfoQ:请介绍你自己,以及TDD的实践经验。 熊节:ThoughtWorks公司总监咨询师,曾参与《重构:改善
实践题目:保龄球比赛计分 保龄球比赛一般分十局,每局最多可扔两个球,如果第一个球将所有的瓶子打
一.TDD开发过程 回顾TDD的开发过程,我们是在不断重复如下过程,直至需求完成。 二.TDD的收益 三.单
版权所有 IT知识库 CopyRight © 2009-2015 IT知识库 IT610.com , All Rights Reserved. 京ICP备09083238号