Code Review 很有必要，在Code Review时，要按既定的原则与目标进行，不炫技，不挑刺，找出代码的缺陷和需求理解不到位的地方，相互学习代码设计与思路。
要做到对每个人的每次提交都做严格的code review机制，这需要一个强大的制度流程保证和团队leader的主力推进。否则很难在实际工作中推行。
关于这点，我有一个思路，在每周四下午，进行集中式的code review，抽检范围为上周四至本周四，对提交记录中随机挑选3条，先由对应提交者讲解，然后大家针对本次提交，提出各自的观点看法，具体可从以下几个点来展开：
判断提交类型，是Bug单、需求单还是优化单？
若是Bug单，则要理清Bug的产生链条，修改的思路和影响分析
若是需求单，则需要讲解自己对该需求的理解，完成需求的任务分解和基本解决方案。
若是优化单，则要讲解优化的动机、具体手法和影响范围。
其他同事可对讲解者的当前做法提意见，若没什么意见，老员工可就业务流程进行一些适当的延伸，不管是技术原理讲解，还是业务规则梳理，都可以。整体时间控制在1小时左右，每个commit平均分配20~30分钟即可。
每两周一次业务分享，可以是新技术研讨，也可以是现有架构介绍：团队定期进行新技术的研讨，保持对新技术和新业务的敏感度，业务分享需要提前一周确定分享主题。这个可以和code review每周交替进行，一个月四周，两次code review，两次业务分享。
团队协作当使用他人提供的接口或者模块时，如果现有功能不能满足自己的需要，即使可以看到他人的具体流程（有源码的情况），也不能去贸然去修改，要将改动的动机以及自己的看法通过邮件或者QQ截图传达给原作者，让他去评估是否做修改。回到自己的工作上，可以自己组合接口基本功能，提供函数来满足自己的需求。
不是所有的Bug的最终走向，都以修复为结束，对于那些暂时不予修复的Bug，需要和产品、测试沟通确定后，将结果落在Bug单中，以备查验。
接收其他部门发来的设计文档、接口文档等原始文档，一定要纳入本地的版本管理系统。纳入版本管理后，才能走下一步。
一定不能去改动原始文档，因为一旦有修改，那么该文档的有效性就由其他部门转给你身上，以后由该文档的错误导致的问题，也会归责到你身上。如果觉得有必要将分散在各个文档的零碎信息汇总到一起，那么，自己应该在本地建立汇总文档，不要将自用的汇总文档覆盖原始的接口文档。
跨部门的协作，如果别人通过群发邮件来咨询问题，当自己知道解决答案时准备回复，需要群发回复，让每一个接收者都知道该问题已经得到解决，以防其他人浪费精力解决已解决的问题。
在实现功能时，有一些细节地方，在需求文档里面没有明确指示的，在A做法也行，B做法也行的时候，一定要向产品经理提出疑问，等待反馈后，将得到的反馈到JIRA需求单例去，根据JIRA需求单来做,做到凡是修改要有记录和可回溯性。
在团队合作中，作为基层员工，你只需要对你自己负责的模块负责。在平时开发工作中发现其他模块的坏味道时，不要想着自己发现别人的问题，然后尝试偷偷地去解决这些问题。这里犯了大错，错在不通知他人的情况下，擅自改动他人代码。
自己的贸然改动，修好了，没有人会知道你的劳动成果，修的不好，一旦发布后出去问题，层层追责后定位到是此模块的问题，这就会你带来不必要的麻烦，即便出现的问题不是因为你的修改直接造成的，但因这其中有你的改动，就不好说清楚因果关系，自己曾经犯过这类错误，以后必须时刻谨记，谨记。不要自作聪明。好心办坏事。
从开发者的角度来看待改动，除非改动的影响范围极其有限，否则是无法拍胸脯保准自己的修改不会带来任何问题，就算是增加一行空行，也无法确保。
对于测试人员来说，开发的任何修改对他们都是黑盒的存在，是不可信的，即使开发说本次改动只影响某个模块。在团队作战中，自测是对开发人员最为基本的要求，除了自测之外，还要让测试人员知道我们所做的修改影响的模块或者范围，不能闷头做事，自己提交代码一时爽，测试人员两行泪。
重构时一定要有边界，做什么，在哪里提交，分几次提交，在哪里记录，在哪里反馈等等，在这里，不谈具体重构手法，而谈谈重构的一些注意事项。
当自己发现其他人代码（亦或是自己的代码）中一些坏味道、腐朽的迹象时，心里动了重构的念头，此时，有三种心态：