思路
重构是重新架构，并非一般意义的抽取合并方法之类。
如果没有问题，那么要制造问题，要敢于对项目进行破坏性的修改。然后你就有事情做了，至少修补和修复bug是一项很繁重的工作。重构的精髓往往在于此，这时候不改，后面麻烦。
人脑中所虑及的一切，相当有限，系统实际上很难一次成型，往往是在多次修改的过程中不断优化，很多事情事先没有考虑的情况下事后补救，往往需要一场破坏性极大的手术来改进。系统的进化过程就是不断吸收，思考，整合，定期进行这种破坏性极大的手术。
不要纠结于技术，库，语言，优化手法。这些都是招式，必须要有内力才能使唤到出神入化，并且招式无穷无尽，永远学不完，要挂在合理的框架下才能发挥合力，前者是功力，后者是阵法或连招套路，是合力。招式在良好的功力和阵法下可以不断优化，随时随势变化。
考虑的精髓就在于不考虑，不在意单个招式的精绝，在意起承转合的节奏，宜精则精，宜粗则粗(精炼则一定会付出时间上和脑力上的代价)，某种程度上先搭建能用的系统，避免做出一个半好的系统抱残守缺，或是缺乏与实际的互动闭门造车，后期周期性根据系统和需求的变化做颠覆性修改。前期要尽可能把能公共做的东西独立出来，架构和规则一定要尽可能做好，也不能故意做差或闲散无为，系统能承受的手术的程度是有限度的。
整体上以精简为基调，精所以简，所以明。整体知识了解深刻，写出的代码往往会是最优解，最简解。凑出来的解往往是复杂解，难懂解。
1． 新浪微博的架构启示
a) 技术来源于业务同时提升业务发展，业务发展又反过来推动技术的前进，他们是一个相互影响互相促进的关系，和业务共同发展的技术才是有生命力的。
b) 技术选型建议是寻找当前的最短路径，然后进行不断优化迭代，一口气吃撑是不现实的，也是不合理的。花花注:这个最短路径全局上应由架构师进行设计，约定和代码审查。
c) 推广某个框架和工具的最好的方式不是行政命令也不是请客吃饭，而是大家都是参与者，如同开源项目，每个人都是它的主人，这样人人维护，人人使用。
d) 团队崇尚简单可靠，它说起来容易做起来难，不过有一个好方法就是懂得自己不应该做什么，而不是应该做什么。
e) 说到推荐这个特殊领域上来，设定目标，跟踪目标很重要，把数据和目标摆出来，产品、架构以及算法都回想办法去解决的。
策略
1．.逐渐明确依赖顺序，自底层而顶层逐级编译通过。务必保证项目大部分时间里能编译通过，尽可能利用反馈了解项目。
2．对互相依赖项进行拆分，重新整理项目的逻辑，抽象出公共依赖的简单逻辑层。
3．若思考中停滞，勿轻易退出，这是熟悉代码的大好时机,宜深饮糖茶而参死禅，以求进境。
当然，这只是个别处理，定目标的时候本身要定得容易一些，尽可能步步为营，
应工求将复杂而强大的基础问题转化一个个简单的，可以实现并享受其好处的步骤。
