大家眼中的程序员标签
作为初级的程序员,我们在平时项目中,接触最多的就是业务层代码,每天就是CRUD,可以说没有什么技术含量,即使我们基础很差,依葫芦画瓢很多功能也能够勉强做出来。
但是问题就来了: 工作很简单,为什么每天累成狗???
通过在实验室内全职加入两个项目中,我总结出时间主要花在了 测试+定位问题+改代码。 真正开发的时间并不多,在项目中会经常遇到这样的情况,一个简单的功能模块,1-2个小时写完了业务层的功能代码,但是需要5-6个小时去不停的定位问题该bug。这主要是因为自己写的代码太lan。
所以说, simple is not easy!!!
无论是在实验室项目中还是在公司中,很多人都会有这样的心理:功能简单,很快完成,简单测试OK就算了,没有思考有没有更加好的方式。很多情况下会因为代码写的太lan,代码质量差,很多无关的的代码和业务代码搅在一起,导致遇到问题时,会很难快速定位到出现问题的代码,浪费大量的时间。 这种情况下,你不加班才怪。。。。。。
对于我个人来说,技术很重要,编码更重要。因为很多情况下,在实际的项目中,在面试中问到的很多“高深”问题,在项目中很少用到。因此,对于业务开发来说,规范业务层代码,不但能够减少代码量,快速定位问题,而且还能够方面他人快速易懂阅读代码。
下面看一下这样一段代码,这段代码是controller层的删除数据的接口。
@PostMapping("/delete")
public Map<String, Object> delete(long id, String lang) {
Map<String, Object> data = new HashMap<String, Object>();
boolean result = false;
try {
// 语言(中英文提示不同)
Locale local = "zh".equalsIgnoreCase(lang) ? Locale.CHINESE : Locale.ENGLISH;
result = configService.delete(id, local);
data.put("code", 0);
} catch (CheckException e) {
// 参数等校验出错,这类异常属于已知异常,不需要打印堆栈,返回码为-1
data.put("code", -1);
data.put("msg", e.getMessage());
} catch (Exception e) {
// 其他未知异常,需要打印堆栈分析用,返回码为99
log.error(e);
data.put("code", 99);
data.put("msg", e.toString());
}
data.put("result", result);
return data;
}
这段代码在项目中运行没有什么问题。但是如果拿着这段代码让资深的Java开发人员看得话,会被满脸的嫌弃。因为这写得太lan。
因此,如果将代码规范化,可以修改成:
@PostMapping("/delete")
public ResultBean<Boolean> delete(long id) {
return new ResultBean<Boolean>(configService.delete(id));
}
其实就简单实用了一下AOP技术(也不是什么高深的技术)。代码就一行,特性一个都没有丢。
所以说,技术无所谓高低,最重要的是看你怎么用。 “知道”、“懂”并不代表能够很好的使用。其实在项目中的业务开发中,很多情况下使用到的技术都很简单,但是一样的业务开发人员,为什么别人能够受到部门老大的喜欢?
接下来,我就从以下四个方面介绍在实际的项目开发中的编码规范
1. 接口定义规范
2. controller规范
3. 异常处理规范
4. 工具类规范
网上讲技术的博文很多,但是讲编码习惯和风格的很少。这几篇博客是参考晓峰轻的博客,以及结合自己在实验室参加的两个项目后的总结。