“我情愿用一天时间重写”

今天分配任务，因为时间关系，一个我已经实现的模块的改动，需要他人帮忙完成，我用了三四天时间完成的模块，接受任务的人说“我情愿用一天时间重写”。

十种有一定共性的报表，需要用纯文本形式表现，我把报表分成多个区域定义为对象，整个报表定义基类负责数据的格式化填充，十个子类通过配制的方式确定各自的格式和需要显示哪些内容，用Factory和Template Method模式实现最主要的框架结构。这样处理主要因为报表的类型比较多，格式及内容需求相当不明确，从维护性和扩充性的角度，以及个人的倾向选择了这种实现的方式。

同事打算采用过程化的把文档空格换行及内容拼凑出来的方式，这样处理是因为他以前做过类似的实现。我看过那份代码----报表就一种类型，格式是早就定死的，排版对齐的复杂度也不是很高。

我无法想象用他的实现来处理十种类型将写出维护性多么糟糕的代码，他可能也没理解需求不一致已经使复杂度完全是两个级别。我可能没理解他心目中的实现究竟是什么个样，或许他真的一天能够实现，不过PM认为不可能，后来PM用了半天的时间把两个函数做了些修改，基本上解决了问题（要从根源上解决问题，要用GDI获取DC,获取每个字母的宽度....,而这些代码在服务器端执行,faint!)。

最本质的原因我想是接受的人对OO还不感冒吧，正好对应起《DDD》里面Bus-Rule-Net Example的两种实现的例子，他选择了前者，我选择了后者。不禁又想起以前公司Mole项目里面我的一套代码，同事告诉我接手的人不敢动。

我常常考虑可维护性，但是对真正维护代码的人来说我的代码却好象是最不可维护的，有意思! 我研究过ORM OpenSource Obj.Net，我也不敢动，第一是我的研究还不彻底，第二是没有人可以给我仔细讲解里面的结构和逻辑。设计的人总是精心构架系统，整个结构对他来说烂熟于胸，他自己来维护和扩充绝对是优势毕显的。但是换了一个人，如果缺少OO的实践，如果没有足够的高质量的文档而创建者又不能亲自讲解，那么，引用mzhou的一句话“简直是一场灾难”。

对管理者来说，需要发挥每个人的最大优势，而不是让他充分的去展现劣势，当然锻炼人是另外一会事。