工作随想2013-03-14

我看了你列举的10个代码问题，其中有两个地方，我认为有点问题。

8. 省平台核心的com.huateng.haobai.ppcore.model.CardRecord.getActiveFlagDesc()方法：

public String getActiveFlagDesc() {
    return activeFlagDesc;
}

 

这里的activeFlagDesc变量是类的私有成员

private String activeFlagDesc;，

 整个类都没有对其赋值，因此上面的方法永远返回null，不知道作者这样做的意义何在？

 

这段代码只不过是对activeFlagDesc属性设置getter方法而已。

 

 

10. 手机前置com.huateng.haobai.riskControl.pool.impl.SocketObject.sendData2Server(String)方法：

if (e instanceof SocketTimeoutException) {
    DataQueue.addData(jsonstr);
    return true;
}

 

这里的e是Exception类型，可想而知这里的if条件会永远是什么值。

 

try{

...

} catch (Exception  e) {

if (e  instanceof  SocketTimeoutException) {

   ...

}

}

 

这段语句是针对socket读取服务器端数据超时而进行的异常捕获，在运行区中，如果发生了超时异常，e的实际类型就是SocketTimeoutException，这是典型的java的多态特性，你只考虑了编译期间的代码逻辑，并未考虑到运行期间的实际情况，而且这段代码是进行过严格测试的，你可以找测试人员赵箫剑进行核对，这个业务代码是我写的。

 

其他的8点，我表示赞同。

 

代码检测工具的引入是必要的，在文档缺乏的情况下，对于我们这些技术人员而言，看代码就成了最直接的了解具体业务内容的方式。当我看到这些不符合规范的代码的时候，我会说，“我靠，谁写的，这。。。，唉。。。，你用点心啊”。但是我们也不能过分依赖代码检测工具，我使用过findBugs，它在一定程度上能规范我们的代码，但是检测工具是死了，它自定义的规则也是死的，不能过分依赖它，有的规则并不适合我们代码的编写规范。

 

关于代码规范问题，我的建议是，在引入检测工具的同时，进行一些人为的评审。主要想法如下：

关于1-3-9的设想。1个总负责人带领三个项目负责人，这三个项目负责人分别负责自己的业务部分的代码管理，每个负责人手下有三个开发人员，分别对自己接到的业务在项目代码中写业务逻辑，然后交由项目负责人审核，审核通过后才能上线。每隔一段时间对各个负责人的项目代码进行总的评审，分别从项目代码的整体架构、项目的文档规范、代码的编写质量、bug数目、代码的冗余程度等不同角度对代码进行评审，实行百分制，对于好的项目代码，对负责人和开发人员进行嘉奖；对于差的项目代码，对负责人和开发人员进行惩罚，令其在规定时间内进行整改。

目前的情况是，业务需求主导代码逻辑的开发，我们这些开发人员整天被各种需求、各种人催债，比如：刚有个人对你说，“你那个业务开发咋样了，这个明天就要上线啊，你给测试组测试过了吗”，另外又来个人对你说，“我的那个东西做的咋样了，啥时候能好的，我那边还等着呢”，一般是在这样的情况下，我们开发人员对业务进行代码的编写的。等开发上线完成后，大家都认为没事了，结束了，一般不会有人再回过头来看看自己写的东西，我就这样。呵呵，所以。。。

其实真不应该招我这样没什么经验能力的人来开发代码，如果我是领导，我一般会招工作了2-3年的开发人员。

 

以上是我随意的想法，没进行什么整理，也没给什么建议。但是在以后的道路上，我会慢慢摸索着，慢慢解决这些事情，毕竟这非一朝一夕能完成的。

 

请不要转发，谢谢。