代码检视拟定方案(已完成,非代码博文,开发流程相关)

代码检视拟定方案(已完成,非代码博文,开发流程相关)"/>

代码检视拟定方案(已完成,非代码博文,开发流程相关)

代码检视拟定方案

为什么要进行代码检视?

• 提前发现代码逻辑问题
• 优秀的代码分享、坏味道代码警示
• 要求别人的同时提高对自己的要求
• 性能初步检查
• 抽象组件、函数沉淀、常量抽取、设计模式引入
• 解决代码审查消耗大量时间精力问题
• 结对编程,利于双方代码风格的靠拢,业务的互知,岗位的互替,风险的平均
• 注释的即时更正
• 可读性优化

代码检视误区和争议

1. 任务重,加班多,赶进度,代码检视不利于快速上线

    以个人开发经验来谈,一个人一天所写的有效核心代码大致在150-200行,一个迭代的代码交接时讲一个
小时也就够了,可以在每天AM 10:00-10:30,PM 2:00-2:30,PM 5:00-5:30这三个时间窗(现在敏捷的主流都
强调部署时间窗,可以和部署时间窗同节拍进行)去找检视人检视代码,150行代码,查阅时间在10分钟之内,指出
issue并讨论或者pk的时间,20分钟足够,碎片化代码检视时间,其实并不会占用很大段时间,除非积累了很多代
码,把一个功能的代码全堆在一起让检视人检视

2. 代码检视太费时间,且大多数都是检视一些不痛不痒的issue,没有技术含量

    我们做代码检视这个动作就是拍散风险,大面积撒网,重点捞鱼,如果没有这个动作,那整个工程的代码将成
为盲区,留存的技术债早晚要还,无非就是组织开发人员定期检视代码,还只能安排到周六周日这种不占用工作日
的时间,并且谁也不能保证这样长时间的审查的力度是否足够,提出来的问题是否能比不痛不痒的issue更高明,
以个人的经验做反思,基本上这种集中长时间的代码审查也是不痛不痒,为了赶时间,可能比碎片化的检视更肤
浅,因为大量开发人员聚集的会议容不得时间纠结一个问题

3. 团队的习惯和流程就是不做代码检视，大家都是这么过来的

    当今告诉发展的社会,最稳定不变的就是改变,要拥抱变化,从个人而言要提升自己,团队也应逐步完善制
度,先举两个例子,ECP的九天平台,和zf的信息化搭建,ECP为什么要舍弃osgi框架,大家之前都是按照osgi框
架开发的,为什么不保持这个习惯呢,互联网公司是为了高并发高可用,水平向扩缩容,避免形成数据孤岛,和各部
门之间的重复功能开发,咱们还有一些客户的要求、技术栈的升级,公司是在拥抱变化的,再看zf的信息化,之
前的办事难,拿着一份资料到十几个部门盖章,跑断腿,现在随着zf信息化的搭建,个人公积金提取,网上办事大
厅,电子报表,加密电子签章,无一不在说明,zf也从指导型机构向服务型机构转变,总之,一切都在变化,我们只
有正确对待变化,才能更加稳定,组织的进步会给员工带来能力提升,员工自我进步,会给组织交付的产物更加可
靠,一旦有一方停步不前,可能就会出现互相不合适的情况

4. 代码检视容易制造内部矛盾

    首先提一个问题:开车容易出现道路安全事故,那我们就不开车了吗?现实世界告诉我们,还是有很多车行驶
在公路上的,如果代码检视是对人不对事,那么即使不是代码检视这项活动,也会在日常沟通和团队协作中产生摩
擦和矛盾,如果只针对代码而言,最底线的解决方案无非也就是按照检视人的建议改,如果改的是错的,那么检视
人也是责任承担的一方,因为下文提出的方案就要带出检视意见和检视人这两个概念,有了检视意见和检视人,无
理要求的提出者多多少少也会先经过对自己担责的思考,不会出现把java代码改为C++代码这种过分的检视意
见,理越辩越明,我们只强调事情的合理性,大家的目标是保持代码高质量,交付成果令客户满意即可,管理者不断
强调向着共同目标去检视,就会极大纠正检视中的歪风邪气,提高团队成员的分析、思考、权衡、归纳、表达，
乃至心理承受力等综合素质

代码检视流程

SVN库代码检视

流程图

时序图

git库代码检视

流程图

时序图

代码检视试点及方案选取

• 客户化开发四组
• 人员:两位开发
• 干系人:项目经理,技术经理,需求,开发,测试
• CCB评审频率:当前阶段所有需要评审的问题收集完毕后
• 选型:SVN库代码检视方案,因当前开发的微服务项目较少,且SVN库检视流程清爽,故适合试点后推行
• 代码检视时间:每天AM 10:00-10:30,PM 2:00-2:30,PM 5:00-5:30这三个时间窗
• 修改响应时间:非节假日,建议(24h内),一般(12h内),严重(6h内),致命(3h内)
• 最晚解决全部可修改问题周期:5*24h内,不可进入下周

代码检视指标

• 建议 = 0.2
• 一般 = 1
• 严重 = 2
• 致命 = 4

Git仓方案附加要求:

• 每人每周提的有效issue不少于三个;
• issue要写明代码问题所在行数，问题类型，级别，修改人，处理日期可选。
• 要求代码满足一致性，可读性，简洁性，可定位性，可重用性，健壮性。如果不满足的话，可以从这方面入手提出issue。
• issue级别有建议，一般，严重，致命。负责人修改完代码之后，通知提出issue的人复检，关闭issue.

注:试点成功后的推广又PMO以周为单位收集检视意见归档文件和每位开发提供的issue截图

代码检视表格