Tin's Blog » TDD

DDD重构初步

tin — Wed, 04 Nov 2009 01:24:17 +0000

所做的系统是一个连接到外部信息发送和搜索引擎调用服务的Web前端系统。系统与外部的接口使用的是一层Service外观进行包装，原先的设计目的是使用服务层剥离对外部系统的强依赖──解耦，同时还希望使用Service将系统的商业逻辑集中存放──提高复用的可能。但是实际上我们发现Service这样的抽取方法并没有提高代码的复用度，反而造成数据结构和其算法的大量重复。经过分析，发现由于使用了大量的Hash结构存放接口间的返回结果，造成数据与其Service内部的行为分离，传递后商业逻辑就出现了重复（这样的结果是引入大量Quick but dirty的解决方案所欠下的技术债造成的）。所以我和我的Pair绝对对其进行DDD（领域模型驱动设计）的重构。

领域模型驱动设计和面向对象设计在代码的抽象上很相似，它们都推荐让数据结构（状态）与商业逻辑（行为）统一管理。这样数据的状态与行为就不会分离，这样可以很大的减少由于商业逻辑分散造成的代码重复。这可以让我们实现我们非常重视的DRY（Don’t repeat yourself）。
一开始我们尝试的是找到重复的商业逻辑和其对应的数据结构，然后尝试让它们映射到我们的领域模型。这样的效果还不错，但是经过了一天的工作，我们发现我们对领域模型的理解有问题，我们居然抽取出了重复的领域模型类。这个时候暴露的问题是我们对系统的领域模型没有统一和深入的认识。

所以下一步我们计划进行领域模型语言的讨论会，目的就是使用自己的“领域语言”描述系统的所有行为，从这样的领域故事中找到我们的领域模型（领域概念模型，不是具体编程的时候的类）。

领域模型讨论会最好由最熟悉领域模型的人起草，可以由这个人把它写在白板上。领域的故事最好能够涵盖系统的主要行为，描述要使用简练的语言。一般来说IT系统的内部行为可能很复杂，但是到了领域高度还是可以用比较简单的语言描述的，如果遇到一块白板不够的话最好首先考虑提高观察的高度，让领域的描述简练一些，其次再考虑扩展到第二块白板。在这个过程中我们要注意消除歧义，比如同样一个“术语”在两个功能区域中出现，那我们就要妥善的给他们各自取一个容易区分的“领域术语”作为名字。还有就是我们应该在写领域故事的时候考虑领域模型（或者理解为系统模块的抽象）之间的交互关系，最好在写领域故事的时候对行为的归属（它会指导行为到底会被建模在哪个领域模型中，可以体现为类的调用关系，哪个类持有交互逻辑）达成共识，这个时候达成的共识比在做具体的OO设计时候分辨商业逻辑归属要更体现商业价值。完成领域故事后我们要找到其中的所有领域模型（也就是前面说的领域对象和领域中的术语）。然后团队最好一起通读这个用户故事，一起讨论是否通顺（行为是否完备，抽象是否合理），是否有遗漏（遗失的领域模型或行为）。对于有外部系统的情况下，即使外部系统是面向消息的（或者说是没有使用领域模型驱动的SOA接口），那么团队最好对消息的内容有一个讨论，对其中设计到本系统和外不系统的领域模型进行认领，然后使用一个适配器来保证数据到达系统后就使用领域模型表示，外不系统的数据（一般没有行为）最好也使用一个领域模型进行约定。

完成了上面这一步后，DDD最重要的一部分就完成了，它可以实现系统领域模型自顶向下的“名正言顺”，减少在自底向上的重构过程中产生的大量重复领域模型。下面的重构过程就是给领域模型写测试，使用TDD（或者也可以用BDD的方式提早对行为做验收测试，用它们来驱动对领域模型的实现，其实对领域模型的TDD和BDD是殊路同归）的方式逐一实现领域模型。而后争取给系统写一些验收测试或者高级别的集成测试，再逐一替换这些领域模型。这样就达到了DDD重构的效果。

准备可扩展的网站-架构与部属

tin — Mon, 30 Jun 2008 14:57:33 +0000

这个幻灯片是我为Beijing Open Party所准备的，好看簿也有图片版本。欢迎所有对网站可扩展架构感兴趣的朋友一同交流，也欢迎参加Beijing Open Party的活动。

| View | Upload your own

在Mac下启动多个Firefox实例方便JsUnit运行

tin — Tue, 15 Apr 2008 00:11:16 +0000

项目中的JsUnit是使用ant脚本运行的，里面需要设置BROWSER_PATH的环境变量来启动浏览器。在本地check in代码的时候，我们会运行一下测试来减少愚蠢错误被提交到代码控制系统。但是在我的mac下Firefox只能启动一个实例，在运行JsUnit test的时候会提醒我已经打开了Firefox，不能打开另外一个实例，这样我必须关闭正在运行的Firefox。而且由于我比较喜欢打开非常多的Tabs来保持浏览状态，所以关闭Firefox让我很不爽，再说，因为重新启动的Firefox里面带了很多的Tabs，所以经常造成实际运行的JsUnit test发生随机性的超时错误，这个就不能容忍了，因为这无法保证我们的信心。

那么，为什么FF不能启动多个实例呢？原因是它们共享同一个Firefox的profile，所以没法多个实例并发访问。但是通过命令行参数是可以创建多个profile给firefox的，简单了。不过遇到的问题是JsUnit的ant任务会检测BROWSER_PATH是否存在，所以如果我把带参数的命令行写到环境变量里面Ant无法检测到这个文件就会报错。那么如果关闭检测可以么？还是不行。因为JsUnit的StandaloneTest里面实际最后会调用DefaultProcessStarter的execute方法，这个方法调用Runtime.getRuntime().exec(command)，这个实现非常直接，不过因为parameters如果直接写到命令行里会发生文件无法找到的问题（应该用数组将命令和参数传入）所以没有办法传入，还是无法运行。

放弃hack吧，我可以修改Ant task和JsUnit的方法，但是绝对不好，因为这个hack没有提交回去的意义。
所以换个思路，这样做：我们去写个shell来解决它。

先在终端运行/Applications/Firefox.app/Contents/MacOS/firefox-bin -CreateProfile jsunit，这时候会弹出窗口让你确认创建这个profile，选择一下不使用extensions和各种工具条，这样减少这些设置对测试的不良影响。
然后在你的home目录创建一个firefox.sh，里面写上：

/Applications/Firefox.app/Contents/MacOS/firefox-bin -P jsunit $1

前提是你的Mac使用的是默认的bash，否则修改$1为对应的引用字符。然后chmod firefox.sh 555，让它可以运行。

下面就是修改你的~/.profile：

export BROWSER_PATH=/Users/[User path]/firefox.sh

source ~/.profile让修改生效再运行JsUnit就OK啦。如法炮制想开几个Firefox实例都可以啦。同样方法也适用于让Firefox2和Firefox3共同运行！非常简单。还可以做到开发和浏览分开……以此类推。

回顾一下JsUnit的代码写的不好，如果像Selenium一样能够自动创建一个profile就好了，因为那样可以减少测试之间的影响，还可以让Selenium并行执行。我想，如果有空我可以做一下这个工作:D

写javascript单元测试是挺爽的事，可惜不要在safari上？

tin — Thu, 31 Jan 2008 07:55:37 +0000

对于javascript来说，通过单元测试，你也可以实现TDD。对你非常有好处，一是减少了js变动带来的代码退化问题，另外一方面是TDD可以改变你设计程序的方式。
举个简单的例子，写javascript很多情况下是和BOM（也就是文档模型）和DOM打交道的，这样可以说javascript程序很容易与dom高度耦合，这样的程序运行起来没有问题，但是应对需求变化的能力会比较地。但是根据人的思维方式，javascript很多时候是先出页面，然后根据页面逐渐调试着写出javascript，对于开发者来说，脑子里并不是真正的清楚自己要什么，而是在想界面的结果……这样产生的高耦合代码不容易测试，也难以面对多变的界面。
所以，换一种方式思考。如果用单元测试的方式去写，你就需要考虑程序的可测试性，这会细化你的程序的模块粒度，因为细粒度的抽象容易单元测试。同时由于js单元测试的页面是mock出来的，所以一般都会尽量的简单，这样会减少程序远对界面的依赖。同时由于界面的可测是性问题，也许会减少对element的style的修改，转而使用语义话的css。例如如果一个元素高亮，你可以element.style['font-size']=’bold’;element.style.color=’red’l….，当然你也可以element.addClassName(‘highlight’)，然后那些不好验证的界面的约束条件可以放到css里面去，放给可用性和用户验收测试去验证。这样的单元测试的验证条件（assertion）会简单很多，如果写过单元测试的朋友肯定会有感触的。
那么，常见的Javascript的单元测试框架有JsUnit和scrit.aculo.us的单元测试框架两个。前者方便用ant调用和分析结果，适合使用了ant的项目。而后者的优点就是界面好看，直接运行产生的报告清楚漂亮。所以小型项目我倾向后者，而大型项目我倾向前者。当然，由于js的动态特性，其实做个单元测试框架非常简单，所以自己动手也无妨。关键是要写，而且争取做到测试先行。

前面是个引子，其实写这个的原因是今天上午的一个郁闷的事。
前面的blog entry说道我升级了Firefox3，结果遇到了getElementsByClassName问题。但是今天换到另外一个项目组，没有用那个方法，程序也正常。可是我TDD的写一个新的feature的时候却发现可爱的JsUnit的testRunner在Firefox3里面无法工作，从firebug里面看到了一堆安全性问题。估计是firefox3的新安全模型造成的吧。那么，由于firefox3覆盖了firefox2，所以难道我没法写程序了？当然不可以，还有safari嘛。马上开始去写测试了，写好测试执行测试，发现红条。嗯，很满意，因为TDD的红－绿－红－绿的节奏就是这样的。然后我开始去写实现来满足这个测试……结果忙活了一上午就是不行……而且发现一些原来的测试也无法通过了……我仔细寻找问题，diff修改的内容，可是最后实在没有发现任何让它不能通过的原因，因为手工在firebug里面都已经验证了写的实现是没有问题的呀……崩溃。此时我突然想起来我们的持续集成服务器里面没有跑safari的JsUnit测试……也就是说不能确定在safari下全绿（此时的背景是我们的持续集成显示全部绿色，也就是说所有的测试都可以同过，包括windows和linux平台还有IE及Firefox），那么我可能衰了。马上开动camino（靠，一上午都忘记用它执行JsUnit了，因为我的习惯是Camino里面保存to read list），运行一下全绿。很兴奋，但是感觉刚才寻找问题的1个多小时被无辜的浪费了，心疼呀。

那么，请注意啦，我只是想提醒，jsUnit可能不能在safari下正常工作（大部分测试没有问题，少量在其它浏览器正常的测试在safari下无法工作），我用的是safari3.0.4……