一、系统里面存在的糟糕代码情况有:
1. 代码规范,命名规范和注释
2. 公用代码的抽取和封装
3. 性能低下的代码
4. 表现层、业务层、数据持久层位置存放混乱问题
二、问题
-
岗位调动,接手一个新的项目组。旧项目一踏糊涂,全部无规范和设计。
-
组成员各做各的,毫无团队协作能力,更别说团队凝聚力。简直不能更糟糕。
-
新项目、新成员,新项目重新做了明确规范和框架设计,但组员很多时候不能很好的按照规范进行开发
-
我有强迫症
三、开始犯的错误,也是最笨的做法
定时核查,自己看到不正确代码同时指出,让开发优化,缺点:
-
比较耗时,没有很多时间来检查所有开发代码
-
周期长,这个过程要一直持续很久,才能有效果
-
效果慢
-
容易导致组员开发反感,这很重要,任何事情重复了次数多了,都无法避免
四、解决方案
-
选一个检查负责人,定一个周期(一周),每周三出一份检查报告。
-
报告放入文档,附带截图和问题说明、以及所随机抽查的文件,发送全组
-
负责人规定最后修复时间,所属问题对应开发修复后并回复
五、要点
-
负责人检查这个过程,他会自己认真考虑问题和优化方案,这很重要,负责人过程肯定印象深刻,可以避免再犯
-
实际中,负责人检查的肯定有不少遗漏和不正确或要点没指出,特别是首次作为检查人时
-
自己通过检查文档,过一遍,把负责人考虑不全的同他当面沟通指正, 同时让他更新问题文档, 这里可直接提高他的编码能力
-
这个检查过程,提高最大的是负责人。所以负责人每周期一换,轮流来, 当他们经历规范负责人后,对项目归宿感和规范要求会大有提升,后面至少负责人会认真写出正确的编码
-
相信经过几轮后,每个开发最后都得到大量提高和合作能力
-
项目经理可节省大量时间,且提高开发水平、代码规范、性能、代码重用等优化
六、总结
1. 把问题抛出给组员,并尝试让他们独立解决
2. 大部分时候,只要引导方法正确,他们很处理的很好
3. 非必要的话,需避免自己独自扛着问题,让组成员处理、进步变得优秀才是‘可持续发展’模式,这需要一个过程,虽然难,但一定要进行
附带新规范代码预览