很遗憾，任何使用Use Case的人都会对一件事情产生烦恼：用例的粒度。没有什么书籍能够回避这个问题。因为用例的定义本身就是从参与者的角度出发的，用例考察的场景是由参与者发起的一系列完整活动，对于普通的应用系统而言，比如一个连锁店的管理系统，我们都会遇到几十个或几百个用例。这些用例如果要文档化，就需要考虑他们的参与者、涉众、前后置条件、基本事件流和备选事件流。如果你的经理或你自己严格按照RUP去工作，你还需要写上一大堆的限制条件，直到你确确实实“编写有效用例”。对于一次订餐，基本事件流可能需要十几步，而对于事件为参与者的打印服务，也许只需要三步。从技术角度来看，为订餐进行的建模活动远比为已经有了很好的打印机底层接口的打印服务进行建模的活动要复杂的多。而不管你遇到了多少这样的悬殊差距，最终考量你的工作成果总是看你实现了几个用例（在一些传统的规模巨大的公司中）。

      用例到底应该被定义为什么粒度？没有一个完全合适的说法，这是用例的本质造成的，如果不计算工作中因为用例粒度问题造成的工作不平等，我们完全可以不考虑这个问题，但是，这种不平等是存在的，如果项目组开始集体工作，这样的问问题就会出现，你不能做到尽量的平等（经验充足可能会好一些）。即使按照用例的复杂度来分配工作，也会遇到新的问题：辛辛苦苦完成的用例可能对客户是完全简单的，客户甚至不认为为此需要花费什么时间。而且，我们还得面临一个问题：用例即使存在价值，也可能会因为实现过晚而导致无法为公司尽快赚到钱。

      因此，在用例的有效性问题上，从公司和开发小组利益出发的考虑使得FDD开始流行，同样是用例，但是这回成为特征，特征就是对客户有价值的用例，真正由用户开始执行的活动，而不含有从时间开始驱动的过程。特征总是具有类似的粒度，用户心中的特征，往往由一系列的活动组成，在他们心目中，某个尺度的活动就已经“足够了”，这使得特征的粒度趋于一致。为什么我认为这样从公司和开发小组的利益出发呢？因为我发现，FDD能够更多的带来有实用价值的实现，有最佳实践组成，这一切都和员工的成就感有很大的关系，如果公司选用类似的FDD，我们总可以得到更多的Finished特征，而不是在完成了漫无目的的一对类后不知道‘自己究竟干了什么。

      这里也许不该提到TDD，虽然TDD中的测试最终要根据经验来编写，我们却总能从中得到相似的粒度，一个程序员对于一个要靠测试来驱动的方法的编写是有一个限制的，比如，总希望自己能够在固定的时间内完成一些固定数量的测试，这样还是会使粒度趋向一致，带给他们的公平感和成就感也会增强。

      价值驱动的软件开发应当建立在FDD上，对于一个或一些有价值的特征，我们才应当考虑它们是否适合销售的问题。对于大项目而言，采用最小试销特性的确可以大大增加ROI，或者说增大未来现金流的现值，我们可以对特征进行考察，筛选出马上就可以卖钱的部分（这和小规模发布不同），然后去拿它变现。当然，这种方法仍旧存在选择粒度的问题，但是由于决定权在客户，效果也要好得多，客户总会要求一个真正的成品，这种规模也是类似的。

      在宏观尺度上，我们总可以找到类似的粒度，而拥例本身却做不到这一点，它考虑的是整个流程，不管这个流程有没有客户需要的价值。

      因此，我们逐层的包装用例，这些xDD们也都在改变自己对需求的认识，毕竟，需求是模糊的，用数量来定义他们的复杂度非常困难，我们总是需要依赖经验在某一个尺度上建立相似的评价标准。

      极限编程也是类似的，用户故事反映了用户心中的价值标准，我们对用户故事能够基本找到合适的粒度。在划分为任务的时候，因为依赖程序员的经验，我们也可以相信，在同样的公司中，因为工作方式接近，程序员们能够自己达到平衡。

      前两天在学校里遇到了一个期货公司的人，看不出干了几年了。聊了一会儿后，他讲了讲他对软件的一些认识，看的出来，他很想从用户的角度为我诠释一下他心中的软件是什么样子，向告诉我他认为软件应该是怎么被开发出来的。当然，他对公司的软件只是使用过，我也不知道他使用了多长时间，但是，就从她和我聊天的情况来看，他认为他们公司正在使用的软件“作的不太好”，当然，他客气了，我认为他的意思可能是说，那个软件根本就不行。

      作为软件的开发人员，或者说作为开发软件的公司，对客户到底应该怎样认识呢？这位“客户”又和我们现在的认识非常一致的地方，他认为软件的开发必须要有既懂软件开发又是业务专家的人来参与，让这些人来充当客户代表。软件工程当然会考虑这方面问题的，不管是什么过程，搞清楚客户的需求都是第一位的，那么现在客户为什么感觉不到清晰的需求的存在呢？也许答案很简单，需求的变化总是出乎所有人的预料。对于一个不懂软件开发的人而言（比如客户），要求他们去理解“需求变更”或者是“配置管理”是件非常困难的工作，几乎是不可能的，可是对开发过程的不了解将使开发人员和客户之间的协作关系非常混乱和痛苦，我们需要他们了解，“软件不是几张界面，而是一整套的前后台联动的系统，点一下鼠标、按一个快捷键并不能解决他们的问题，所有的具体工作的执行都是在他们看不到的指令序列中完成的，程序员编写这些需要付出最艰苦的劳动，耗费最长的时间，因此客户不应该要求我们几天就完成一个一般规模的项目”。可是客户对这些描述仍旧半信半疑（即使在今天也是一样），在他们心中，一个程序就是load()，display()再加上save()，对于中间的process()，他们并不太关心，仿佛那是一两句话就能解决的问题，如果我们不能尽快解决，就是在“故意拖延时间”。

      不用多说了，软件开发从来都要以客户为中心，因此，他们要求快速，我们给他快速，他们要求质量，我们尽量保障，他们认为“程序员偷懒”，我们就通过禁止程序员上班时看技术文档或者与同行聊天（当然也是交流技术）来让他们满意。最后，他们要求软件“几乎要免费”，我们为了争取与他们的合作，也被迫答应......还要说什么吗？我们的客户认为我们是“廉价生产线”，如果我们不变成真的廉价生产线，也就将走向灭亡。

      我们走向“自动化”，走向“产品化”。我们还有别的方法，根据“敏捷法则”，我们邀请客户从头到尾和我们参与软件开发的整个过程，以期提高他们对我们的认识，更为了能够尽快地解决开发中遇到的问题。于是，我和那个期货从业者聊到了敏捷，向他建议和采用这样过程的软件公司合作，他给我的答案是：“你觉得这可能吗？你们软件开发用得着这样吗？我建议你不要再想这些没用的东西了，老老实实多学点业务吧。”

      客户对软件公司和软件的认识非常清晰准确：IT民工很廉价，软件本来就很简单，你们应该几天就能做完。因为廉价和简单，做出来的东西几乎不值钱......

      当然，在他们的心中，然件公司不是公司，不需要管理，不需要运营，人都不需要吃饭，而且个个都是冲着电脑说两句话就能让电脑自己一下子把所有的东西都干完的家伙。如果我们不能和他们交流，他们对我们的认识将会始终如此。

    按照Debu Panda的说法，一个PAR文件应该是这个样子的：

META-INF/

                  Manifest.mf (Class-path may include another jar file that includes entities classes)

                  persistence.xml

                  HRmapping.xml

                

Managed Classes

    其中persistence.xml文件描述了类似Hibernate的hibernate.cfg.xml文件的信息，而HRmapping.xml则描述了持久化类的映射信息。当然，这个映射信息文件也是可选的，因为我们完全可以通过“注释”来解决所有的问题。不过对于这种源码级元数据，我并不是完全赞成，看起来似乎我们把耦合性重新以这种方式带回到代码中来。

    如果把PAR部署到一个应用程序服务器中，那个persistence.xml也成了可选的了，有些如JBoss的应用程序服务器会允许我们将EntityManage实现类和持久化所需要的数据源统统写入全局配置文件，这时候再用上注释，干脆不用PAR文件了。可惜，这样的话我们也享受不到EJB3容器为实体Bean提供的企业级服务。

    另外一件事，很多人都注意到了持久化框架正在覆盖全部的JavaSE以及JavaEE，只要你提供一个EntityManager，就可以在EJB3容器之外进行持久化工作，这个时候Hibernate3又该派上用场了。PAR因为是普通的压缩文件，同样也可以被应用程序正常调用，这个时候我们需要在persistence.xml中声明EntityManager的提供者为Hibernate或是TopLink什么的，而Hibernate也会积极的读取persistence.xml和HRmapping.xml的信息用以和自身的Persistence服务结合。

    总之，目前我们看到在JSR220的规范编写队伍里，最为活跃的就是Hibernate和Oracle，他们正在分别给出可用的EJB3的预览版本，不管PAR这个意见在最后的规范中是否会保留下来，EJB3持久化机制已经取得了巨大的进步，不同之处仅仅限于我们如何处理这些轻量级的Bean类的部署问题而已。

   

 

 

 

  

赔本就是贴现之后的净现值为负，这没有什么可争论的，什么利润大于成本之类的说法全是小孩子们过家家说的。

我们随便考虑一个项目，公司如果预算了20万元的成本，用了18个月完成，机会成本10%，最后收回了23万。这个项目还能做吗，没法做，直接投到10%的机会那里赚得更多。

目前很多客户好像都不太理解这件事情，他们认为公司的花费总是应当“很小”，即使付出两万，他们也会说：“这样一个小项目，你们能写几天，价格已经很高了”。事实上，公司把场地卖掉，每个员工都发可怜的工资，兴许能按照客户的要求只收很少的钱。

对于一个小公司来说，租用一个二十平米的场地每个月租金也动辄就要上万元，还要发工资，还要花水电费，加起来一个一个月就完成的小项目也要花掉两万块银子（五个人的公司），只给两万当然没有挣头。

对于一个大公司来说，拥有几百号人，项目是否赔本的计算仍就应当使用净现值方法，只不过就没一个项目来看，要按照本项目的参与者来制作成本，不要拿整个公司的消耗来计算成本。这样，得到的成本是真实的，它不代表公司的运行成本，而只是项目的成本。我们谈论的赔本应当尽量局限在“项目”的范畴内，公司的运营成本则还要考虑很多其他的开支。处理这些开支的方法一般是简单的将此开支分摊到项目成本中，但是这样严重侵害了项目的独立性。公司对项目的把握程度和选择标准也会出现问题。

停止这样的计算方法吧，让项目回到项目自身，管理的费用在项目以外另行计算，不要给项目经理施加“肩负全公司命运”这样的压力，让他们在项目自身的范畴内尽量的施展自己的才华。

如果你想减少公司的运营成本，从运营过程中去寻找原因，优化自身的资源配置，别拿项目小组开刀。

客户永远都不会轻易讲道理的，如果优化了资源配置，减低了运营成本，仍就不能和客户达成一致，你才该说：“对不起，不做了。”

最后一点，公司总是要继续运营的，如果除了这赔本的买卖你没有别的事情可以做了，那就接受吧，总比光花运营费强

 

Eclipse总在更新，我们一次又一次的下载，共享以前的工作区，然后删掉旧的版本

现在，IBM也混进来了，真令人沮丧，他们竟然在Eclipse上建筑了新的RSD平台，然后，用不完善的功能作为最终的发布版本（一向如此）。

所以，每次他们的补丁都特别大，这次也不例外，新的补丁有一个G还多，都通过他们那不能断电续传的升级管理器来传输，我每次升级都失败，只好采用了下载整个压缩包的方式，当然，HTTP续传没个失败，不过我也耗费了几个小时。

IBM的产品给我们什么呢？

（1）绝对标准化的实现（如UML或MOF什么的）

（2）绝对巨大的体积

（3）绝对困难的使用

（4）绝对资源的浪费

（5）时间飞逝，没有成效

（6）一切苦恼带来之后BEA接近的性能，有点摸透了门路之后的易用性

当然，下载和更新IBM产品令你浪费所有的网络带宽

通过源代码可以注意到，Hibernate3中，不要试图通过事务处理中的commit()环节而调用的Session的flush()操作去保存新的对象，要注意，Hibernate3并不等到你提交事务的时候才去进行向数据库进行持久化。

按照原本的设想，或者是Hibernate2中的方式，Session.save()方法会最终向操作对列中写入一个SQL操作，并且将对象存入缓存，当事务提交的时候，flush()方法会执行所有的SQL操作。而在Hibernate3中，作者们认识到数据库本身对事务的隔离级别的支持已经是一个不错的主意了（非分布式事务的条件下），而且session-per-request模式也可以为每个请求启动独立的Session实例，由容器来保障请求的隔离性（同时保障了Session的隔离性）。sava()操作本身涉及到的竞争性资源只有数据库，因此不需要我们在专门编写并发的程序，上面说到，数据库自己管理事务隔离性。

基于以上考虑，persister中的performSave()等类似的方法不需要再等待flush了，可以直接调用而同步到数据库。

Sun, give them new names from JavaSE, JavaEE to JavaME, so I follow them and discuss EE here.

You should noticed that something interesting happend:

1.Eclipse 3.1 final

2.Apache Geronimo passes J2EE 1.4 test suite

3.EJB3(JSR-220) released a public review

......

now, welcome to the new age of Java, pay attention to it, or you will get lost and kicked off.

Thanks