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