自己一点心声

你所谓的“完美”可能只是一厢情愿，一文不值。当需求变动来临的时候说不定你那苦苦构思的“完美代码”和“架构”都要推到重来。更可能的是当未来的你回头维护自己的代码的时候，再也想不通自己当初的设计为何如此怪异。

很多公司是做项目的，项目做完人也要被调到别的项目组去了，除非你被留下来做维护，才可以做些自己想做的事情。
到是觉的互联网公司和做产品的公司更适合做这些事情，反正我已经开始讨厌一遍一遍的花时间理解一个新的业务需求。

C3PO的话很简单，你认为好的，别人不一定认为好，你觉得完美的，别人可能不够完美。

如果你是头目，可以指定一套规则，限制代码的结构和编码规范，如果你不是头目，那么应该遵守上头指定的编码规范，规范上写了，每个方法大于100行就应该重构，写了cpd上出现的代码就应该整合到一起，那么就去重构好了。

如果没有标准，完全靠自己去判断，就没什么争论的必要了。我觉得，既然是工作，还是要统一标准的好，要不最后互相扯皮就没意思了。

恕我直言，能把代码写得又精简又易懂的人很稀罕，可能一个公司也没几个。

实际情况是：能把代码写得清晰明了，让以后维护的人能很快找到需要修改的地方，就已经是很谢天谢地的状态了。能把代码写成那样的人才都不多。在高呼“重构”，“完美”之前，先问问你自己是不是这样的人才，有没有人维护过你的代码之后跑来跟你说很欣赏你的代码？

有人跟我说过，如果我的一段代码5秒钟之内不能让人看懂，那就是写得不好。如果将来有维护的人跑来问你这段那段代码（也许不到30行）是什么意思，希望你不要骄傲地跟人吹嘘什么“精简”，“重构”，人家看不懂你的东西说明你是个低手，不是什么光荣的事情。