假如你是一个Leader，那么你敢对你的自己的项目Refactor吗？当然我这儿所说的Refactor不是仅仅修改几个Class而已，而是将旧有的框架完全抛弃，而建立一个全新的框架。你能面对Release的压力，还有项目成败的挑战吗？
当一个Project越来越大，Logic越来越复杂的时候，就有的框架体系往往不能满足新Feature的要求，于是程序员们有两种选择，要么重构，要么打补丁。对于后者，如果开发人员水平高一点，补丁的痕迹还不会很明显，如果水平一般的话，这段代码往往就会形成一个恶梦。久而久之，整个项目都会积重难返，直至崩溃。
很幸运的是，我所在的Team从一开始就定位于坚持Refactor。基本上每个MileStone，都会有1-2个人手上的活不是new feature，而是refactor。也许刚刚开始refactor的时候会无从下手，毕竟很大的一块，不是说动就动的。但是不管怎么样，refactor之后的效果是显而易见的，新的扩展很容易实现，往往只要覆写某个方法就可以实现一个新的feature。磨刀不误砍柴工，refactor很好的诠释了这一点。
看过《重构》这本书的人，都会知道重构须从小处做起，不断坚持，但这样的重构也只仅仅局限于某些功能点的重用性而已。真正的重构，是需要大刀阔斧的。一个项目，你很难知道后期的行为，因此代码框架也很难一直适应新的需求。当需求不断变更的同时，如果固步自封，浑身打上狗皮膏药，补丁越多，维护越累。当量变达到质变的时候，也就是项目崩溃的时候。只有坚持对框架进行调整，才能够不断的满足新的需求。
说到这儿就不得不说到团队间的合作问题，一个产品，往往是由几个Team共同协作完成的。基本上每个Team都只需要负责自己的模块，并且根据工作量的大小有相应的人手。那么你认为在这儿Team之间，大家工作的感觉会想差不多吗？实际上，每个Team内部的情况完全不一样，有的Team，一个人平均每天只能该1个Bug，有的Team能够该3-5个。归根结底，还是由于框架的问题。如果框架结构清晰明了，改起来自然简单，往往一行代码的修改就能解决问题。框架结构复杂的话，那就不好收拾了。框架的作用就是增加重用性，降低耦合度。我们这儿有一个Team，框架3年都没有什么改变了，而且由于人员的更迭，很多代码都和黑盒一样，没有人能够看明白。我敢说，我一天改10个Bug都不在话下，他们能说吗？
一个Leader要维护Team之间的平衡真得很累，结构好了，自然就做的快了，可那又不是自己的错，做得慢的Team不但拖累自己，到头来还硬要说你出风头。开发人员第一个需要拥有的素质就是能够不断自省，要学会先怀疑自己。把所有的责任都推卸出去了，到最后问题没解决那还是自己的。一个项目的成败也往往是由Leader的管理水平来决定的。如果Leader都怕失败，不敢去承担责任，那么手下的人自然也没有这个义务了。
我只想说一句，不敢对自己现有的框架体系做出挑战的，不能够自省的Leader，都是对自己的项目，自己的手下不负责任。一个项目最终的成败，也可能就毁在这些人手上。