最近对面向对象分析的一些思考

   整整花了一个月的时间完成一个统计功能，以下是一点心得体会。

不能头痛医头、脚痛医脚

我是在项目经理的指导下进行开发。项目经理联系客户、确定需求，要实现哪些功能、长成什么样都是项目经理说了算。通常他明确了一项功能，我就开始实现该功能。可以看效果了，就让客户看。客户说是这样，那就继续做；若不是，又修修改改。

这可能算得上是迭代式开发。书上一般推荐这种方法。但存在什么问题呢？可能看不到多个功能之间的联系。在实现前一个功能的时候，没有考虑到后一个功能。而它们之间可能是相互联系的。这样在做后一个功能的时候，为了复用、让代码好看一点，又去改前一个功能的代码。

应该有全局观，整体上把握，对所有需求要大致了解，要先把架子搭好，这样代码改动量可能会少一些。

了解真正的需求

Martin  Fowler说要了解真正的需求。确实是这样。我的项目经理关心怎样实现，甚至直接告诉我怎样写查询条件。他说用job计算交易持续时间的查询条件是"nm_transact_days"为0或null。但这不是真正的需求。需求应该是：计算“已办结件”的交易持续时间，放在nm_transact_days字段中。这还不是真正的需求，真正的需求是：计算“已办结件”的交易持续时间，只计算一次，不能让job下一次执行时又计算。查询条件"nm_transact_days"为0或null表明尚未计算过。 写代码的过程中，经得项目经理的同意，我没有用这样的查询条件。用另外的“已办结”标识。job执行的时候，发现办件已办结，同时设置nm_transact_days的值和已办结标识。

数据是不可靠的

要以两种方式计算办件总数，且要显示各分项值。各分项只有单独统计。但总数肯定是一致的，我觉得没有必要计算两次。于是把一种统计方式的总数直接赋值给另一种的总数。这样做的后果是：第二种统计方式有分项值与数据库中的记录数不符。花了不少时间才找到原因：计算该分项时用了减法-------用总数减去其他分项值，而总数是另一种统计方式的总数。

   我要完成的是统计功能，应该是数据库中数据的真实反应。不要偷懒，不要相信数据，不能因为数据不一致，而导致统计出错。而数据不一致，是另外一个问题。

不要太勤快

  这是一个教训。我习惯把不用的、废弃掉的函数，统统删掉，让代码好看一些。可过了几天，情况有变，又要用到哪些函数了。可此时，我把类名改过了，放在其他包里面了，结果是，版本库中也找不到被删掉的函数了。

  结论是，不要了的代码，先让它在那里，不要急着删，说不定还有用。即使要删，先在本地留备份。