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就必须重构这块儿代码。
这招真的够狠！
