编码二三事

随着项目的推行,各种问题逐渐显露出来了.

1.代码执行效率低下,客户反映前端响应慢.

2.代码结构混乱,代码重用度低,往往一些小小的改动,就需要调试很长时间.

3.开发项目过程当中,参与人数过多,导致夹杂着多种风格的代码,后期项目组新招入的开发人员,维护难度很大.另外,项目组相关开发文档不够齐全。

And So on.

近期,保监会行业平台推出新的商业险平台交互接口规范,时间紧任务重,今天早晨在调试新增接口方法时,看到同事写的代码,当时感觉很生气,明明是一个业务逻辑(与一次数据库交互就可以完成的操作),硬是将代码实现为与数据库交互两次. 至少从我个人角度看,这种问题是绝对不允许发生的.

客观的分析了造成这种现象的客观原因:

1.项目组目前没有专职Java 软件测试工程师,所以,往往当任务/模块细分到某个开发人员身上时,大家按照自己的开发思路和逻辑,以及编程风格,将代码编写完毕,然后在本地和测试环境下测试通过后,就提交到了SVN上…

2.而开发代码的质量与程序员自身的技术实力和编写代码的习惯有紧密的关系. 编码规范只是作为一个约束条件,而不能从根本上杜绝垃圾代码的产生。

So,如何杜绝这种现象(垃圾代码)的产生?如何提高项目做协作能力?如果提升产品的性能?这三个问题迅速在我脑海中呈现.

我的见解和建议如下:

1.引入Code Review机制,从根本上杜绝垃圾代码的产生.

2.在上述操作过程当中,不断迭代总结相关经验,并完善相关文档.

How to?如何去实施,去做,以及中间可能涉及到的问题?

1.需要领导的支持,以便能顺利的执行和推进该计划.

2.关于Code Review 建立相关的操作文档,For Example:Code Review操作步骤,Code Review代码审核规范文档等.

3.问题1:时间评估? 问题2:代码审核者责任? 问题3:交流过程中的问题记录?

4.Just do your best!

最后一点就是尽自己最大的努力去做好这件事情,我想任何事情都是先做然后才能总结出经验的.

Ps.继上周调查市场后, 发现,隔行如隔山,想的再多不如实际去做.而对于无知的我们,只能摸索着前进.