由一个team内的code merge问题引发的思考
stand up meeting上，几个做同一模块的同事都说到merger代码很头疼，花费了很多effort，有同事重构了sub module依赖的base code， 有多位同事修改了相同的文件。SCM为CC,每个人有自己的sub-stream 和view。
简单看一下，问题很common,每个人闷头做自己的task， code merge的频率小，UT滞后于source code。比较忙，不详细分析了：
1、估story时、拆task时就应看到多个story或task有共同frame的倾向，coding之前或前期就应有简单的沟通，讨论framework，这时当然不宜在framework上花费太多时间，后续的沟通是必须的，pair-programing哪里去了？
2、后续的重构当然需要，但有相应的UT保证重构的正确性吗，先run GUI测试功能后补UT的做法目的是什么，只为了clover生成的覆盖率？
3、base code 重构，也要对依赖它们的code做相应的修改，code merge的情况在team中很正常，尽快提交，尽早merge，小步前进，对于多人更改频繁的code，pair-programming不正减少了更改code的“人”数吗，对于framework code，改时在team里说一声并不是难事。
