糟糕的代码设计真的让人很心烦..

既然你知道代码质量不是一下子变坏的
为什么又认为它会一下子变好？

那如何才能使它变好呢？

大规模重构 or 推倒重来？

每天重构一点点不是也可以让它变好一点点吗？
既然是用了很长时间变坏的一个东西，自然也要很长时间才会变好。

嗯,谢谢 gigix了,前面有朋友提到 重新找份工作,我不认为再找份工作就能避免这种问题,问题肯定有,关键在于怎样去面对它,我的想法是首先要保证自己的代码的可读性,至于别人写的那是下一步要做的事..

键盘所及处，能清扫的就清扫，能加测试的就加测试
消除工作中遇到的一切重复代码，不引入新的重复代码
把持续集成搞起来，哪怕一开始只跑一个测试，只要每天都在增加自动测试的量，总是向着好的方向发展
发现defect的时候，第一件事就是用一个测试来描述它
坚持让代码变好的实践，不向让代码变坏的实践妥协
只要每天都在进步，就是好的

貌似我没有说过代码会一下子变好的话。。。

可能是我想太多了吧
代码要变好，不是靠“大的代码变更”来达到的
我的标准是，三行以上的代码不应该重复
（当然还有别的标准，例如一个方法不应该超过10行）
发现这样一个小小的不好，你就把它扫干净，于是代码就变好了一点点
一点点积累起来，整个代码库就会变好

[quote="gigix可能是我想太多了吧
代码要变好，不是靠“大的代码变更”来达到的
我的标准是，三行以上的代码不应该重复
（当然还有别的标准，例如一个方法不应该超过10行）
发现这样一个小小的不好，你就把它扫干净，于是代码就变好了一点点
一点点积累起来，整个代码库就会变好

（当然还有别的标准，例如一个方法不应该超过10行）
这个应该有点难度吧...
那要写多少个小方法，而且有些代码内聚度比较高的，为什么要拆成多个方法

其实初步看来你的这个问题是可以解决的。如果你可以确定你得到dao的方式是以factory的形式来得而非直接new，那么你在这里使用proxy，返回一个proxy的instance，在proxy里面判断是否已经init过了，没有做过就做init，如果已经做了则直接调用target对象的方法。
这样既可以满足你每次不调用root class的方法也可以不让你的同事的代码受到影响。

其实“陈旧”还是要比“不统一”来得要好一些。

各自为战的混乱远比武器落后要可怕……