partech
- 浏览: 31662 次
- 性别:
- 来自: 深圳
-
最新评论
-
rrtrip：
引用透过方面的视角也许是一个可以考虑的方法。
这样测试会不会 ...
测试的粒度如何界定？ -
刑天战士：
比如遗留系统，就算是很多现在的数据库也不是按照ActiveRe ...
用ActiveRecord能否完美的匹配DomainModel? -
BirdGu：
除了单表继承某些情况下不一定适用以外，Active Recor ...
用ActiveRecord能否完美的匹配DomainModel? -
刑天战士：
partech 写道yuxie 写道难道你看现在ror那些例子 ...
用ActiveRecord能否完美的匹配DomainModel? -
tuti：
partech 写道yuxie 写道难道你看现在ror那些例子 ...
用ActiveRecord能否完美的匹配DomainModel?
文章列表
对于测试驱动来说，如何确定要测试的主体，是个似是而非的问题。
在OO中对象是最基本的组织结构，那么测试的主体是否可以以对象为基本单位呢？
所以我们可以看见很多“对象”和“对象测试”对，比如有一个CustomerOrder对象，就会有一个CustomerOrderTest对象。虽然后者并不是总是存在。
另外一个常见的做法是只在服务层有测试，也就是说同时测试了Service,DomainModel，DAO。
前者的问题在于对象都是普遍联系的，紧紧测试某个对象，会产生一些意义模糊的测试。这好比流水线作业，某个局部动作如果不放到整个流水线来考察，就没有意义。另外，需要很多的mock或stub也确实恼人 ...
用ActiveRecord能否完美的匹配DomainModel，对此我有些疑问，你有何感想？
看看老马的定义：
引用Active Record
An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.
该定义表明Active Record是对于数据库某一个表或视图行的封装，也就是用数据行的方式来建立DomainModel，还是会有阻抗失配的情况吧......
前些天测试中发现，缓存好像不能处理数据变更的情况。原来还是好好的阿。
经过跟踪，发现问题出在UpdateTimestampsCache，不知哪位仁兄手快，改了一行if语句，把原来正确的逻辑改错了。在7月13号到11月15号之间，下载的hibernate都有这个BUG。
return lastUpdate.longValue() < timestamp.longValue();
// if ( lastUpdate.longValue() >= timestamp.longValue() ) return false;
从这件事情，引申出另外一个问题，测试是如何的重 ...
在Spring Framework2.0的开发参考手册中，看到将AOP译作“面向切面编程”。
下面谈谈我的看法。
把Aspect理解为切面是有道理的，因为最终的实现中，Aspect确实表现为横切与多个对象。不管是在
扩展模式还是对等模式。切面很形象地表达了这样的事实。
然而，把Aspect作为切面理解，意味着被切对象的存在，似乎，切面不过是对已有对象的一个补充。
实际上，我认为Aspect是同Object同样重要的概念，如果从需求的角度来看，甚至还更重要。要在软件开发中全程运用Aspect，就必须提升Aspect的地位，让它成为最重要的概念之一，所以，我比较倾向于按照"方面&qu ...
直接用SWT当然累，可以考虑用Jface和jface databinding开发一个Model/View的框架阿。
框架开发，当然是件辛苦的事情。不过，随后的开发就轻松多了。
并且Model和View是分离的，测试也相当的好作。EclipseRCP提供了很多现成的东西可以复用，比如可折叠的Section就是个不错的东东。并且由于合理的模块划分，使得界面的交互变更也很容易得到满足。至少，目前我看不出效率低在那里.学习曲线也并不高，看看已有的代码，只要几天就可以自主开发功能了。
EclipseRCP是开源的，翻开代码看看，Eclipse的模块划分还是不错的，只需要花上一两天的功夫，就可以实现不需 ...
- 2006-11-10 15:48
- 浏览 2066
- 评论(0)
ozzzzzz 写道partech 写道
1.在我参与开发的项目中，绝大多数决策，都是有充分理由的；
有充分的理由你还需要决策吗？如果决策真的是一件简单，明显，不需要费脑筋权衡的事情，这个东西还能叫决策吗？
这个观点，让我有点吃 ...
- 2006-10-24 20:31
- 浏览 2002
- 评论(0)
最后作一下澄清吧：
1.在我参与开发的项目中，绝大多数决策，都是有充分理由的；
2.如果出现决策信息不充分的情况，如果不是必须决策，那么，就等条件成熟了再决策，如果不得不作出决策，那就选择最简单，最容易的。
3.我相信“快速决策，痛苦执行；缓慢决策，迅速执行”，不无道理。与其乱动，不如不动；
4.对客户有价值，并不等价于“客户说有价值”；
5.我不认为“难于解决的部分往往就是项目是不是可以真正的构建起来的关键”（这倒可以成为开发人员研究新技术/难技术的借口）；
6.别“越俎代庖”，客户固然有他的弱点，但人家也不傻，不要认为开发人员恰恰就能弥补这些弱点；
- 2006-10-23 13:23
- 浏览 1807
- 评论(0)
ozzzzzz 写道
首先我们都承认如果没有充足额信息，做出的决策，无疑会带来偏差和错误的可能性大大提高。于是瀑布的做法就是，那么就等待这些信息被我们得到之后，条件成熟了，我们再做决策；要么就是做出种种长期的预测，从而进行决策。
就瀑布方法的具体表现来看，不可能是得到充分的信息后，做出的决策。
瀑布方法缺少应对变化的对策，并且不提供功能强大的反馈支持，导致其趋向于僵化。
ozzzzzz 写道
而以敏捷为代表的迭代方法则采用有勇气的探索决策的方式。首先我们在当前迭代中安排的是对于客户最有价值的，最难于解决的，最模糊不清的，最难于取舍的部分进行开发。
“对于客户最有价值的，最难于解决的，最 ...
- 2006-10-23 13:23
- 浏览 2053
- 评论(0)
又看了一遍Ivar的演讲，感觉思路满新颖,下面是EssUP的基本原理Aspect-Oriented/Separation Of Concerns。编程中的Aspect和过程的Aspect的对比。
Aspect相互相对独立，可以叠加组合。
实践相互相对独立，可以叠加组合。
Aspect横切业务过程
实践跨越（横切）软件开发的整个生命周期
Aspect需要识别，方面可以组合
八大实践，就是八大方面
作为扩展的Aspect，不是必须
不需要所有的实践
Test is every Where，是一个方面的方面？
可以通过一个Aspect来扩展另外一个Aspect
其它实践来扩展核心实践框架 ...