MR源头控制

每次MR的时候需要跑脚本控制代码质量，并且由对改模块较为熟悉的人员进行Code Review, CR不能流于形式，可以考虑采用 LGTM原则，出bug写代码以及CR的人一起承担责任。

一些重要指标

1、单个函数方法行数控制100以内

2、函数的圈复杂度小于40

3、本地提交的图片小于 50k(这是瘦身逻辑)

4、所有单元测试需通过

5、每个需求强制至少写一个单元测试

重视单元测试

单元测试要考虑写的目的，而不是流于形式，考虑异常输入、边界条件，
函数应尽可能短小，遵守单一指责原则，一个函数要可测试性高、便于阅读、可维护性高
对于iOS oc项目而言, OCMock是一个不错的选择 http://ocmock.org/

阶段性重构

相信很多大公司的项目都有这样的弊病，
某些类或者函数就像懒姑娘的裹脚布，又臭又长，
大家工作任务繁重的情况下，也通常倾向于偷懒，
而我们项目采用这样的方式去推动大家对老的逻辑进行重构，
比方说某个函数已经300行，A 需要在函数中增加一行，
那么这个函数就无法通过MR流水线的脚本检查，
无法合并代码，那么A就必须重构这块儿代码。
这招真的够狠！