写代码需要养成的好习惯

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 写代码需要养成的好习惯

1.注释尽可能全面,写有意义的注释

接口方法、类、复杂的业务逻辑,都应该添加有意义的注释

  • 对于接口方法的注释,应该包含详细的入参和结果说明,有异常抛出的情况也要详细叙述
  • 类的注释应该包含类的功能说明、作者和修改者。
  • 如果是业务逻辑很复杂的代码,真的非常有必要写清楚注释。

清楚的注释,更有利于后面的维护。

2.项目拆分合理的目录结构

记得读大学那会,刚学做各种各样的管理系统,都是用MVC模式,也就是controllerservicemapperentity。如果未来业务扩展,你没有拆分业务结构的话,很可能就会发现,一个service包下,有上百个服务。。。

正确的做法,如果服务过多,应该根据不同的业务进行划分,比如订单、登陆、积分等等

当然,你也可以根据不同的业务划分模块,比如建一个moudles包,然后按订单、登陆等业务划分,每个业务都有自己的controller、service、mapper、entity。

我们拆分的目的,就是让项目结构更清晰,可读性更强,更容易维护而已。

3. 不在循环里远程调用、或者数据库操作,优先考虑批量进行。

远程操作或者数据库操作都是比较耗网络、IO资源的,所以尽量不在循环里远程调用、不在循环里操作数据库,能批量一次性查回来尽量不要循环多次去查。(但是呢,如果是操作数据库,也不要一次性查太多数据哈,可以分批500一次酱紫)。

正例:

remoteBatchQuery(param);

反例:

for(int i=0;i<n;i++){
  remoteSingleQuery(param)
}

4. 封装方法形参

如果你的方法参数过多,要封装一个对象出来。反例如下:

public void getUserInfo(String name,String age,String sex,String mobile,String idNo){
  // do something ...
}

如果参数很多,做新老接口兼容处理也比较麻烦。建议写个对象出来,如下:

public void getUserInfo(UserInfoParamDTO userInfoParamDTO){
  // do something ...
}
class UserInfoParamDTO{
  private String name;
  private String age; 
  private String sex;
  private String mobile;
  private String idNo;
}

5. 封装通用模板

一个优秀的后端开发,应该具备封装通用模板的编码能力。

我们来看一个业务需求:假设我们有这么一个业务场景:

内部系统不同商户,调用我们系统接口,去跟外部第三方系统交互(http方式)。

走类似这么一个流程,如下:

一个请求都会经历这几个流程:

  • 查询商户信息
  • 对请求报文加签
  • 发送http请求出去
  • 对返回的报文验签

通过HTTP发请求出去时,有的商户可能是走代理的,有的是走直连。假设当前有A,B商户接入,不少伙伴可能这么实现,伪代码如下:

// 商户A处理句柄
CompanyAHandler implements RequestHandler {
   Resp hander(req){
   //查询商户信息
   queryMerchantInfo();
   //加签
   signature();
   //http请求(A商户假设走的是代理)
   httpRequestbyProxy()
   //验签
   verify();
   }
}
// 商户B处理句柄
CompanyBHandler implements RequestHandler {
   Resp hander(Rreq){
   //查询商户信息
   queryMerchantInfo();
   //加签
   signature();
   // http请求(B商户不走代理,直连)
   httpRequestbyDirect();
   // 验签
   verify(); 
   }
}

假设新加一个C商户接入,你需要再实现一套这样的代码。显然,这样代码就重复了。这时候我们可以封装一个通用模板!我们就可以定义一个抽象类,包含请求流程的几个方法,伪代码如下:

abstract class AbstractMerchantService  { 
     //模板方法流程
     Resp handlerTempPlate(req){
           //查询商户信息
           queryMerchantInfo();
           //加签
           signature();
           //http 请求
           httpRequest();
           // 验签
           verifySinature();
     }
      // Http是否走代理(提供给子类实现)
      abstract boolean isRequestByProxy();
}

然后所有商户接入,都做这个流程。如果这个通用模板是你抽取的,别的小伙伴接到开发任务,都是接入你的模板;

封装通用模板,就是抽个模板模式嘛?其实不仅仅是,而是自己对需求、代码的思考与总结,一种编程思想的升华。

6. 封装复杂的逻辑判断条件

我们来看下这段代码:

public void test(UserStatus userStatus){
    if (userStatus != UserStatus.BANNED && userStatus != UserStatus.DELETED && userStatus != UserStatus.FROZEN) {
        //doSomeThing
        return
    }
}

这段代码有什么问题呢?是的,逻辑判断条件太复杂啦,我们可以封装一下它。如下:

public void test(UserStatus userStatus){
    if (isUserActive(userStatus)) {
        //doSomeThing
    }
}
private boolean isUserActive(UserStatus userStatus) {
    return userStatus != UserStatus.BANNED && userStatus != UserStatus.DELETED && userStatus != UserStatus.FROZEN;
}

7. 保持优化性能的嗅觉

优秀的后端开发,应该保持优化性能的嗅觉。比如避免创建比必要的对象、异步处理、使用缓冲流,减少IO操作等等。

比如,我们设计一个APP首页的接口,它需要查用户信息、需要查banner信息、需要查弹窗信息等等。假设耗时如下:

查用户信息200ms,查banner信息100ms、查弹窗信息50ms,那一共就耗时350ms了。如果还查其他信息,那耗时就更大了。如何优化它呢?可以并行发起,耗时可以降为200ms。如下:

采用线程异步的方式对代码进行优化;

8. 可变参数的配置化处理

日常开发中,我们经常会遇到一些可变参数,比如用户多少天没登录注销、运营活动,不同节日红包皮肤切换、订单多久没付款就删除等等。对于这些可变的参数,不用该直接写死在代码。优秀的后端,要做配置化处理,你可以把这些可变参数,放到数据库一个配置表里面,也可以放到项目的配置文件或者apollo上。

比如产品经理提了个红包需求,圣诞节的时候,红包皮肤为圣诞节相关的,春节的时候,为春节红包皮肤等。如果在代码写死控制,可有类似以下代码:

if(duringChristmas){
   img = redPacketChristmasSkin;
}else if(duringSpringFestival){
   img =  redSpringFestivalSkin;
}

如果到了元宵节的时候,运营小姐姐突然又有想法,红包皮肤换成灯笼相关的,这时候,是不是要去修改代码了,重新发布了?

从一开始接口设计时,可以实现一张红包皮肤的配置表,将红包皮肤做成配置化呢?更换红包皮肤,只需修改一下表数据就好了。当然,还有一些场景适合一些配置化的参数:一个分页多少数量控制、某个抢红包多久时间过期这些,都可以搞到参数配置化表里面。这也是扩展性思想的一种体现。

9. 会总结并使用工具类。

很多小伙伴,判断一个list是否为空,会这么写:

if (list == null || list.size() == 0) {
  return null;
}

这样写呢,逻辑是没什么问题的。但是更建议用工具类,比如:

if (CollectionUtils.isEmpty(list)) {
   return null;
}
StringUtils.isEmpty()
StringUtils.isBlank()

日常开发中,我们既要会用工具类,更要学会自己去总结工具类。比如去文件处理工具类、日期处理工具类等等。这些都是优秀后端开发的一些好习惯。

10. 控制方法函数复杂度

你的方法不要写得太复杂,逻辑不要混乱,也不要太长。一个函数不能超过80行。写代码不仅仅是能跑就行,而是为了以后更好的维护。

反例如下:

public class Test {
    private String name;
    private Vector<Order> orders = new Vector<Order>();
    public void printOwing() {
        //print banner
        System.out.println("****************");
        System.out.println("*****customer Owes *****");
        System.out.println("****************");
        //calculate totalAmount
        Enumeration env = orders.elements();
        double totalAmount = 0.0;
        while (env.hasMoreElements()) {
            Order order = (Order) env.nextElement();
            totalAmount += order.getAmout();
        }
        //print details
        System.out.println("name:" + name);
        System.out.println("amount:" + totalAmount);
        ......
    }
}

其实可以使用Extract Method,抽取功能单一的代码段,组成命名清晰的小函数,去解决长函数问题,正例如下:

public class Test {
    private String name;
    private Vector<Order> orders = new Vector<Order>();
    public void printOwing() {
        //print banner
        printBanner();
        //calculate totalAmount
        double totalAmount = getTotalAmount();
        //print details
        printDetail(totalAmount);
    }
    void printBanner(){
        System.out.println("****************");
        System.out.println("*****customer Owes *****");
        System.out.println("****************");
    }
    double getTotalAmount(){
        Enumeration env = orders.elements();
        double totalAmount = 0.0;
        while (env.hasMoreElements()) {
            Order order = (Order) env.nextElement();
            totalAmount += order.getAmout();
        }
        return totalAmount;
    }
    void printDetail(double totalAmount){
        System.out.println("name:" + name);
        System.out.println("amount:" + totalAmount);
    }   
}

11. 在finally块中对资源进行释放

应该大家都有过这样的经历,windows系统桌面如果打开太多文件或者系统软件,就会觉得电脑很卡。当然,我们linux服务器也一样,平时操作文件,或者数据库连接,IO资源流如果没关闭,那么这个IO资源就会被它占着,这样别人就没有办法用了,这就造成资源浪费。

我们操作完文件资源,需要在在finally块中对资源进行释放。

FileInputStream fdIn = null;
try {
    fdIn = new FileInputStream(new File("/公众号_捡田螺的小男孩.txt"));
} catch (FileNotFoundException e) {
    log.error(e);
} catch (IOException e) {
    log.error(e);
}finally {
    try {
    //此处判断是否为空根据自己开启的流进行对应的代码关闭
        if (fdIn != null) {
            fdIn.close();
        }
    } catch (IOException e) {
        log.error(e);
    }
}

12.把日志打印好

日常开发中,一定需要把日志打印好。比如:你实现转账业务,转个几百万,然后转失败了,接着客户投诉,然后你还没有打印到日志,想想那种水深火热的困境下,你却毫无办法。。。

一般情况,方法入参、出参需要打印日志,异常的时候,也要打印日志等等,如下:

public void transfer(TransferDTO transferDTO){
    log.info("invoke tranfer begin");
    //打印入参
    log.info("invoke tranfer,paramters:{}",transferDTO);
    try {
      res=  transferService.transfer(transferDTO);
    }catch(Exception e){
     log.error("transfer fail,account:{}",
     transferDTO.getAccount())
     log.error("transfer fail,exception:{}",e);
    }
    log.info("invoke tranfer end");
    }

12.1 选择恰当的日志级别

常见的日志级别有5种,分别是error、warn、info、debug、trace。日常开发中,我们需要选择恰当的日志级别,不要反手就是打印info哈~

  • error:错误日志,指比较严重的错误,对正常业务有影响,需要运维配置监控的;
  • warn:警告日志,一般的错误,对业务影响不大,但是需要开发关注;
  • info:信息日志,记录排查问题的关键信息,如调用时间、出参入参等等;
  • debug:用于开发DEBUG的,关键逻辑里面的运行时数据;
  • trace:最详细的信息,一般这些信息只记录到日志文件中。

12.2 日志要打印出方法的入参、出参

我们并不需要打印很多很多日志,只需要打印可以快速定位问题的有效日志。有效的日志,是甩锅的利器!

哪些算得的上有效关键的日志呢?比如说,方法进来的时候,打印入参。再然后呢,在方法返回的时候,就是打印出参,返回值。入参的话,一般就是userId或者bizSeq这些关键信息。正例如下:

public String testLogMethod(Document doc, Mode mode){
   log.debug(“method enter param:{}”,userId);
   String id = "666";
   log.debug(“method exit param:{}”,id);
   return id;
}

12. 3 选择合适的日志格式

理想的日志格式,应当包括这些最基本的信息:如当前时间戳(一般毫秒精确度)、日志级别,线程名字等等。在logback日志里可以这么配置:

<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
    <encoder>
        <pattern>%d{HH:mm:ss.SSS} %-5level [%thread][%logger{0}] %m%n</pattern>
    </encoder>
</appender> 

如果我们的日志格式,连当前时间都沒有记录,那连请求的时间点都不知道了?

12.4 遇到if…else…等条件时,每个分支首行都尽量打印日志

当你碰到if…else…或者switch这样的条件时,可以在分支的首行就打印日志,这样排查问题时,就可以通过日志,确定进入了哪个分支,代码逻辑更清晰,也更方便排查问题了。

正例:

if(user.isVip()){
  log.info("该用户是会员,Id:{},开始处理会员逻辑",user,getUserId());
  //会员逻辑
}else{
  log.info("该用户是非会员,Id:{},开始处理非会员逻辑",user,getUserId())
  //非会员逻辑
}

12.5 日志级别比较低时,进行日志开关判断

对于trace/debug这些比较低的日志级别,必须进行日志级别的开关判断。

正例:

User user = new User(666L, "公众号", "捡田螺的小男孩");
if (log.isDebugEnabled()) {
    log.debug("userId is: {}", user.getId());
}

因为当前有如下的日志代码:

logger.debug("Processing trade with id: " + id + " and symbol: " + symbol);

如果配置的日志级别是warn的话,上述日志不会打印,但是会执行字符串拼接操作,如果symbol是对象, 还会执行toString()方法,浪费了系统资源,执行了上述操作,最终日志却没有打印,因此建议加日志开关判断。

12.6. 日志系统选择

不能直接使用日志系统(Log4j、Logback)中的 API,而是使用日志框架SLF4J中的API。

SLF4J 是门面模式的日志框架,有利于维护和各个类的日志处理方式统一,并且可以在保证不修改代码的情况下,很方便的实现底层日志框架的更换。

正例:

import org.slf4j.Logger; 
import org.slf4j.LoggerFactory;
private static final Logger logger = LoggerFactory.getLogger(TianLuoBoy.class);

12.7 建议使用参数占位{},而不是用+拼接。

反例:

logger.info("Processing trade with id: " + id + " and symbol: " + symbol);

上面的例子中,使用+操作符进行字符串的拼接,有一定的性能损耗。

正例如下:

logger.info("Processing trade with id: {} and symbol : {} ", id, symbol); 

我们使用了大括号{}来作为日志中的占位符,比于使用+操作符,更加优雅简洁。并且,相对于反例,使用占位符仅是替换动作,可以有效提升性能。

12.8. 建议使用异步的方式来输出日志。

  • 日志最终会输出到文件或者其它输出流中的,IO性能会有要求的。如果异步,就可以显著提升IO性能。
  • 除非有特殊要求,要不然建议使用异步的方式来输出日志。以logback为例吧,要配置异步很简单,使用AsyncAppender就行
<appender name="FILE_ASYNC" class="ch.qos.logback.classic.AsyncAppender">
    <appender-ref ref="ASYNC"/>
</appender>

12.9 不要使用e.printStackTrace()

反例:

try{
  // 业务代码处理
}catch(Exception e){
  e.printStackTrace();
}

正例:

try{
  // 业务代码处理
}catch(Exception e){
  log.error("你的程序有异常啦",e);
}

理由:

e.printStackTrace()打印出的堆栈日志跟业务代码日志是交错混合在一起的,通常排查异常日志不太方便。

e.printStackTrace()语句产生的字符串记录的是堆栈信息,如果信息太长太多,字符串常量池所在的内存块没有空间了,即内存满了,那么,用户的请求就卡住啦~

12.10 异常日志不要只打一半,要输出全部错误信息

反例1:

try {
    //业务代码处理
} catch (Exception e) {
    // 错误
    LOG.error('你的程序有异常啦');
} 

异常e都没有打印出来,所以压根不知道出了什么类型的异常。

反例2:

try {
    //业务代码处理
} catch (Exception e) {
    // 错误
    LOG.error('你的程序有异常啦', e.getMessage());
} 

e.getMessage()不会记录详细的堆栈异常信息,只会记录错误基本描述信息,不利于排查问题。

正例:

try {
    //业务代码处理
} catch (Exception e) {
    // 错误
    LOG.error('你的程序有异常啦', e);
} 

12.11 禁止在线上环境开启 debug

禁止在线上环境开启debug,这一点非常重要。

因为一般系统的debug日志会很多,并且各种框架中也大量使用 debug的日志,线上开启debug不久可能会打满磁盘,影响业务系统的正常运行。

12.12 不要记录了异常,又抛出异常

反例如下:

log.error("IO exception", e);
throw new MyException(e);

这样实现的话,通常会把栈信息打印两次。这是因为捕获了MyException异常的地方,还会再打印一次。

这样的日志记录,或者包装后再抛出去,不要同时使用!否则你的日志看起来会让人很迷惑。

13.考虑异常,处理好异常

优秀的后端开发,应当考虑到异常,并做好异常处理。给大家提了10个异常处理的建议:

  • 尽量不要使用e.printStackTrace(),而是使用log打印。因为e.printStackTrace()语句可能会导致内存占满。
  • catch住异常时,建议打印出具体的exception,利于更好定位问题
  • 不要用一个Exception捕捉所有可能的异常
  • 记得使用finally关闭流资源或者直接使用try-with-resource。
  • 捕获异常与抛出异常必须是完全匹配,或者捕获异常是抛异常的父类
  • 捕获到的异常,不能忽略它,至少打点日志吧
  • 注意异常对你的代码层次结构的侵染
  • 自定义封装异常,不要丢弃原始异常的信息Throwable cause
  • 运行时异常RuntimeException ,不应该通过catch的方式来处理,而是先预检查,比如:NullPointerException处理
  • 注意异常匹配的顺序,优先捕获具体的异常

14. 考虑系统、接口的兼容性

优秀的后端开发,会考虑系统、接口的兼容性。

如果修改了对外旧接口,但是却不做兼容。这个问题可能比较严重,甚至会直接导致系统发版失败的。新手程序员很容易犯这个错误哦~

因此,如果你的需求是在原来接口上修改,尤其这个接口是对外提供服务的话,一定要考虑接口兼容。举个例子吧,比如dubbo接口,原本是只接收A,B参数,现在你加了一个参数C,就可以考虑这样处理:

//老接口
void oldService(A,B){
  //兼容新接口,传个null代替C
  newService(A,B,null);
}
//新接口,暂时不能删掉老接口,需要做兼容。
void newService(A,B,C){
  ...
}

15. 采取措施避免运行时错误

优秀的后端开发,应该在编写代码阶段,就采取措施,避免运行时错误,如数组边界溢出,被零整除,空指针等运行时错误。类似代码比较常见:

String name = list.get(1).getName(); //list可能越界,因为不一定有2个元素哈

所以,应该采取措施,预防一下数组边界溢出,正例如下:

if(CollectionsUtil.isNotEmpty(list)&& list.size()>1){
  String name = list.get(1).getName(); 
}

文章来源:1


相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
敏捷开发 设计模式 SQL
如何养成整洁的代码习惯
如何养成整洁的代码习惯
93 1
|
数据采集 数据挖掘 程序员
【我问Crossin】编程应该养成那些好习惯?
在 windows 系统下,依次点击 计算机→属性→高级系统设置→环境变量→系统变量→Path。 接着将你的Python安装路径添加到Path最后,切记将该路径与Path中其他的路径用分号「 ; 」分隔,最后重新启动一下 CMD 即可。很多同学在使用 pip 命令是也会遇到相同的情况,处理方法和上面一样,只是添加的路径为安装路径下的 scripts 文件夹。
【我问Crossin】编程应该养成那些好习惯?
|
程序员 API 数据库
想要写出好味道的代码,你需要养成这些好习惯!
大家好,我是小羽。无论做什么行业,良好的习惯会让我们受益终生。它就如我们的指南针一样,指引着我们的行动,从而走向成功。养成良好的习惯,会让我们的工作更加顺利,生活也会变的更加清晰。当我们久...
175 0
想要写出好味道的代码,你需要养成这些好习惯!
程序人生 - 如何养成学习的习惯?
程序人生 - 如何养成学习的习惯?
99 0
|
存储
养成随时注释的好习惯
打从学习编程开始,就知道注释的重要性。逻辑比较复杂的代码;修改代码逻辑;或是加上新的功能等等,最好加上注释。在程序开发、代码维护时我也一直贯彻着这样的思想。可是有时候你还是会忽略它,有时候是因为赶进度,不想花费额外的时间注释;有时候是因为对逻辑理解比较透彻,觉得没有必要注释.....须不知对别人来说,这段代码的逻辑可能不甚了解,也许对你自己而言,几个月或是半年过后,你还能自信满满的说“我对这些逻辑一清二楚”吗? 今天我就遇到了这样一件事件。
785 0
|
PHP
15个编程好习惯
译文链接:http://www.jobbole.com/entry.php/581
693 0