keep it simple

上周末开始打算用周末的业余时间整理一下原来项目的代码。其实最早的想法是重构——用martin书上的方法试验一把。但是刚开了一个头，就感觉到处都不对劲儿。于是试着改用DDD的方法开始重写代码，业务逻辑还真实TMD复杂阿。我希望重写后，代码更加的敏捷——更容易被阅读，容易被修改本，当然运行效率的大幅提升也是重要目标之一。看着n多的synchronized关键字被干掉，n多的sql被cut，感觉爽多了。

 

本周在写从另外系统同步数据到本系统这部分代码的时候，我突然觉得很大的sql感觉相当的不爽。其实这部分的功能很简单——像极了的beanUtils.copyProperties方法，只是这个属性对应数据库的列而已。为了让这部分代码保持代码的简单，考虑是否需要将这个同步抽取出来成为单独的一个project。

考虑再三，决定完全copy原有的code。甚至在这一层次将java中对象的概念都去掉。

1. 如果我将这部分同步数据的工作抽取出来，成为一个高复用性的lib，那么我这部分的同步代码将看起来相当简单
2. 但是为此，我必须另开一个project来完成这个工作，而它的代码量一定比现在要多的多（为了可复用）
3. 这种需求很少，并且在整个project中，仅仅是一个很小的环节，这个项目本身的工作量在业务流程处理上因此决定放弃，改用完全copy原有代码。

原因是同样是保持代码的精简，为代码保持简单——虽然这会导致在这个class中的职责比较混乱，但是我认为应该是可以容忍的。

 

早上在je上看到一篇帖子 http://www.javaeye.com/topic/306436
感觉不大的一个项目，居然为了容灾处理连异地双机双向备份都用上了，却用的小区2m宽带(如果是adsl，那么就意味着实际上的备份的理论最高速度只有512k/8)。我觉得一个manager在初期应该将问题简单化，使工作放到重点中来。

 

保持简单并不仅仅意为着对于自身质量的追求，同样需要勇气和胆量去掉不合理的需求，保持平衡。

 

感觉真是践阿，周末都在“加班”，boss甚至连知道都不知道，不过这样也好，这个“项目”对我来说就是可以容忍失败的试验而已。

难不成生来就是程序员的命？