看这篇文章：http://www.cnblogs.com/greyzeng/p/4077732.html
对评论引发我的思考。
网上有人说这句话我赞同：
优化和重构是两个概念啊，楼主还是没有搞清楚
优化不宜过早主要指的是性能的优化不宜过早，因为很多性能优化其实没有对系统有明显的提升。
而重构主要指的是修正代码中不好的味道，提高代码的可读性和可扩展性
优化的确不宜过早，但是重构是应该持续在整个开发过程中的
当需求比较稳定的时候，就应该考虑通过重构来整理代码
另外一个人的观点：
我们的做法是，将重构这件事当做一种思想，还不是行为来做。
简单的说，就是在日常的开发中，发现任何一个别扭的地方，就可以在自己时间和质量可控范围内，进行完善，并且不要求自己一次性做到尽善尽美。经过了一段时间的积累就会，重构就会由量变转为质变。
不管当初的设计有多好，代码都需要持续不继的成长和改变，所以，重构也需要当作思想，在任何一次开发时持续来做。
-----------------
启发思考：量变到质变。而不是专门花费时间，丢掉手头开发的新任务，新需求，通过这样的方式来重构，成本太高，风险太大(业务部门压力)。的确不可取。在实际工作环境的确时间上不太允许。
像打扫房间，清理桌面，定期清理一下，还一还技术债务。每一次改一点点，慢慢就会形成量变到质变了。我发现这样的方式还不错。看到有坏的代码，在力所能及的范围内重构一下，把代码抽一下。等到病入膏肓的时候，再去重构，所花费的时间将会是绝大的，而且面对一堆量大的工作，根本就没有信心开展下去。内心会放弃。
看别人优秀的代码，对自己是一种提高。看别人不好的代码也是对自己的提高：知道自己以后不要这样子写。
以博客园和CSDN为代表的社区中,普遍认为重构是修改代码,
这完全是错误的观点,
一份工单的完成就是以通过测试为标志,
一旦通过测试,谁都没有权利或者义务去修改代码(成本是需要买单的,是企业承担还是让程序员免费劳动?),
如果后来发现性能问题或者BUG,请重新开出工单,重新核算工价,
这些都必须体现在开发成本当中,
出于成本的考量,设计师自然会把性能测试的工单投放到最合适的时机
这个观点很奇怪：
真正的重构绝不会修改代码,而是以消灭代码为目的的增加代码,
对程序员来说,就是一份份普通的新开出的工单,
并且重构是设计师的日常工作,是企业行为,绝不仅仅针对某个项目,
重构影响的是未来,长期的看,重构会使新增的代码量趋近于零
启发性思考：
有些人是做事业，有些人只是做一份工作，或者是混日子，混工资生活而已。
那也告诉我们，精兵强将的思路招聘人的话，的确是要花价钱招聘精英，实际上是一个抵住10个普通的热。
那么问题来了，如果花不起钱请呢？我觉得，也并不一定要招聘厉害的。那么退而求其次，招聘有理想、有事业心的人。愿意把工作当成自己的理想，至少说是有人生理想，信念追求的人，这样的人会为了理想而奉献，勤奋，执着行动。
在看到唐太宗的讲解中，唐太宗注重有信义的人，就是那个时代的德。这样的人，当信念与利益冲突的时候，会选择坚持自己的道义(信念)。而不是唯利是图的人。
所以并不是要能力强的，能干的。而是有事业心追求的人。
