工作三年后, 我作为Java后端开发的一些心得

工作三年后, 我作为Java后端开发的一些心得

关于开发

敢于和善于使用package

• 对于Java后端开发来讲, 在长时间的web开发中. 大家已经熟悉了MVC架构, 也被这套结构所束缚. 导致创建出来的包也一直都是controller, manager, service, dao. 也将各种各样的类文件都放入其中. 这并不是一种好的做法.
• 其实我们可以大胆的创建相关的package, 只要让结构更合理, 可读性更高.
• 比如可以把对接前端的类写到request, response包; 把一些处理器提取出来放到handler中, 把一些定时任务放到schedule包; 把参数构造相关的放到generator; 把校验相关的放到validator下等等.

合理的提取业务逻辑, 让方法只做和它相关的事情.

• 不知道大家是否看到过下面这种代码. 例如在一个单据的创建方法中, 做一系列的事情, 比如一坨校验参数逻辑, 一堆取价逻辑, 一堆扣减库存逻辑, 再加上创建单据本身的逻辑. 写下来一个方法上百行不止.

  public class OrderManager {

    @Autowired 
    private OrderService orderService;

    public String createOrder(Request request){
      // 1. 检查单据创建参数是否合法
      if(Objects.isNull(request)) {
        throw ....;
      }
      if(CollectionUtils.isEmpty(request.getGoodsList())){
        throw ...;
      }
      ... 

      // 获取商品的价格
      List<Goods> goodsList = request.getGoods();
      goodsList.forEach(goods -> {
        // 查询商品价格

        // 校验价格
        
        // 对价格进行填充
        
      });
       
      // 构造单据逻辑
      
      // 创建单据

      return orderCode;
    }
  } 

• 这个方法里做的事, 没有多余的事情, 但是没有合理的进行业务逻辑的提取. 导致代码看起来非常的杂乱.我们可以对一些业务逻辑做提取封装. 来的到更好的可读性和解耦. 这只是一个简单的例子, 在复杂的业务逻辑里更需要合理提取, 否则屎山就出现了.

  public class OrderManager {

    @Autowired 
    private OrderService orderService;

    @Autowired
    private OrderValidator orderValidator;

    @Autowired
    private OrderGenerator orderGenerator;
    
    @Autowired
    private PriceService priceService;

    @Autowired
    private InventoryService inventoryService;

    public String createOrder(Request request){
      // 1. 检查单据创建参数是否合法
      this.orderValidator(request);

      // 获取商品的价格
      this.priceService(request.getGoods());
       
      // 构造单据逻辑
      Order order = this.orderGenerator.generator(request);
      
      // 创建单据
      this.orderService.create(order);
      return order.getOrderCode();
    }
  } 

合理的方法命名和方法定义

• 方法名的定义很令人苦恼, 常常思前想后想不到好名字. 我曾经因为方法命名不好, 被疯狂的comments

• 方法命名的好坏受个人主观影响, 所以只说几个共同点:

  1. 言简意赅 准确表达方法内容
  2. 方法名与方法内容匹配
  3. 尽量别生僻单词...

• 对于方法的参数, 参数过多的时候, 对方法进行拆解或者抽象出对象去传参:

  // 错误的案例
  public int setParam(int xxx, String xxx, String xxx, String xxx, String xxx, int xxx, String xxx, String xxx){
    ... 
  }

  // 合理的写法
  public int setParam(XxxRequest request) {

  }

控制方法的圈复杂度, 让代码更有层次感

• 我一直觉得, 好的代码读起来应该像故事一样, 有前因, 有后果, 中间娓娓道来. 简单举个例子, 我们可能会遇到在方法中去for循环处理数据的情况. 比如在一个方法中, 套了三层循环.

  List<String> orderCodeList = request.getOrderCodes();

  // 第一层循环
  for(String orderCode : orderCodeList){

    // 查询单号对应的单据明细
    List<OrderItem> items = this.orderItemService.getByCode(orderCode);
    // 第二层循环
    for(OrderItem item : items) {
      // 执行操作1
      // 执行操作2
      // 执行操作3
      
      // 第三层循环
      for()
    }
  }

• 可以把每一层for循环都提取出来, 成为单独的一个方法, 来降低圈复杂度, 提高可读性

  List<String> orderCodeList = request.getOrderCodes();

  // 第一层循环
  for(String orderCode : orderCodeList){
    this.processSingleOrder(orderCode);
  }

  public void processSingleOrder(String orderCode){
    // 查询单号对应的单据明细
    List<OrderItem> items = this.orderItemService.getByCode(orderCode);
    this.processItemsData(items);
  }

  public void processItemsData(){
    for(OrderItem item : items) {
      // 执行操作1
      // 执行操作2
      // 执行操作3
    }
  }

不知道的知识可以去问问Google, 不要自己编

• 不知道标题是否贴切, 但是大家看了例子就会明白我的意思.

• 其中最为典型的例子我认为 是对Obejct和集合的判空 和 创建集合

  // 对于判断, 很多人喜欢这样写
  if( list == null || list.size == 0) 
  或者 
  if(order == null)

  // 对于创建集合, 去创建空集合, 再添加
  List<String> list = new ArrList();
  list.add("xxx");
  list.add("bbb");

• 其实只要我们Google以下, Java下如何对集合判空, 就能看到apache.commons 或者google.common等很多类库已经包含这些内容, 并且实现的更严谨, 更优美. 要请善于使用搜索引擎去填补自己不了解的知识.

  CollectionUtils.isEmpty(list);

  List<String> list = Lists.newArrayList("xxx", "bbb");

不要for循环请求数据库和外部系统接口

• 慢请求的分析, 可能不需要要先去看有没有复杂的关联查询, 或者是不是数据库查询有没有命中索引, 而是先去看是不是有大哥在for循环去请求数据库和dubbo接口. 循环了1w次. 我曾经遇到过多次请求超时都是因为有人在代码里for循环去select , update.
• 对于这种问题的解决, 将循环调用改成单次的批量接口就可以解决问题. 对于mysql的化in操作就可以解决, 对于外部系统对接的, 双方提供批量接口就可以了.

没有意义的注释不要写

• 我很反感在类上要先写上 @Author @Date @Description 一大串内容表明这是你的杰作, 这不是JDK 也不是什么开源项目!!! 除了你和你的同事没人去看.

• 再或者像下面这样在方法上直白翻译了一堆废话, 注释不是这么用的...

  /**
   * 查询用户名称
   *
   * @Param name:用户名
   * @Return 用户
   */
  public User getByName(String name);

不要忽视UnitTest

• 写过单元测试的会发现, 编写完善的单元测试会占用大量的时间, 一般都会超过需求的开发时间, 但是我还是认为单元测试是必须且重要的. 因为作为研发人员, 才是最了解代码中哪里容易出问题的. 更容易写出发现问题的测试用例. 并且代码迭代或者修改后, 也能更快速的发现问题, 将问题停留在研发阶段去解决, 提高整体的进度.

善于使用AI编程工具

• 在我使用了Github copilot和ChatGPT半年后, 我发现我的摸鱼时间变多了... 因为AI编程工具帮我完成了一定量的工作. 例如最常用的代码补全, 代码自动生成, 自动生成单元测试等等
• 在当今, 熟练掌握AI编程工具, 是提高自己工作效率的极佳的方法. 在未来, AI也一定会代替掉一部分程序员的工作.
• [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ONbgJ6nV-1690847312973)(C:\Users\quyanliang\AppData\Roaming\Typora\typora-user-images\1690847111862.png)]

利用IDE的工具来完成代码和优化代码

• IDEA自带功能扫描代码无用引用, 重复代码等坏味道 : Code → Inspect Code

  SonarLint

  MyBatis Plus

  Lombok

  Alibaba Java Coding Guidelines

  CheckStyle-IDEA

  ...

拥抱新技术

• 可能随着工作的时间变长, 大家对新鲜技术的兴趣并不像之前感兴趣. 或者认为目前的技术足够, 远不会过时, 即使过时了, 也会有公司使用.
• 技术是不断迭代更新的, 使用技术的人也要随之更新. 当大家都去开始了解和使用云服务, 容器化, 使用JDK 17的新特性, 开始用云原生框架去替换现有技术时, 咱总不能一直玩转jdk 1.8吧.
• 了解一些新技术并不是什么值得炫耀的, 不知道也不一定影响你工作和赚钱, 但是当互联网红利已经逐渐褪去, 内卷在越来越重的今天, 机会也变得弥足珍贵. 更好的知识储备, 也能让你能获得下一份工作, 在人才市场获得更多青睐.
• 我也一直认为, 开发对很多人来说不光是工作, 也有着一份热爱.

关于处理工作和人际关系

开发并不只是开发

• 这个标题就是字面意思, 指的并不是光顾忌自己的开发任务. 同时也要关注公司的运营和公司业务或者说自己负责的项目的业务.
• 我见过一些程序员只是单纯的根据产品的文档写需求, 你需求怎么写, 我功能就怎么写. 但是研发在看待需求时, 应该持有自己的见解, 观点和建议. 这也就是需求评审的目的.
• 不要觉得需求是产品提的, 和研发没有任何关系. 但是你需要考虑到, 当需求存在问题, 后续的需求优化, bug修复, 甚至数据处理, 可都是要由研发来做的. 简单来说, 错在产品, 但引发问题由你处理.
• 而公司的运营, 关系到了你在公司的生存和发展, 所以关注着公司的运营情况, 也大概你知道你明年的涨薪是否有希望, 年终奖是否能按时发放, 以及你是否应该考虑换一个公司去继续搬砖.

合理的分配和安排自己的工作

• 拿到需求不要急于开发, 不要急于开发, 不要急于开发.
• 我见过一些开发, 在拿到需求后会马不停蹄的开始Coding, 然后就出现边写边改, 再写又发现哪里存在问题, 最后发现写不通, 推翻了之前的结构再写.
• 这个可能并不适合所有人, 但是我认为在开始Coding之前, 是需要构思一下再着手的. 花一些时间分析一下这个需求, 考虑下设计到的各个部分, 构思下自己的开发思路, 设想下其中可能遇到的问题, 当思路清晰后, 再去着手开发, 这样会让你能够流畅的完成开发工作, 并且让你的代码质量更高.

对自己的工作要有Owner意识, 答应的事情要尽力去做到

• 什么是工作的Owner意识, 简单来说, 就是这个工作分配给你, 你就是第一负责人.
• 对于分配到自己手里的工作, 首先要有一个正确的评估. 可以简单的分为: 这个工作你能不能做, 能不能按时做完, 要怎么做, 最后能做到什么效果.
• 如果因为种种原因做不到, 需要提前预报风险, 不要等到最后一刻告诉大家, 你没做到. 任务分配给你, 是因为这是你的工作, 也有一部分信任在, 是相信你可以做好, 别去辜负别人的信任, 信任可能因为一件事就确立起来, 也可能因为一件事情就毁掉.

我不管别人摸鱼, 但不要影响到我的工作

• 工作难免偷懒, 大家都有想休息放松的时候. 我对这个事情的看法就是, 摸鱼可以, 但是不要影响别人的工作.
• 在整个项目或者需求的流程里, 产品, 后端开发, 前端开发, 测试人员都只是其中的一环. 对于各个环节的人员来说, 都是这样, 可以适当摸鱼, 但是不要压缩了别人安排好的时间.

自己的问题勇于承认, 但不是我的锅我不背

• 承认自己的问题并不是一个可耻的事情, 但是不承认被别人扒出来可是非常尴尬的.
• 如果你不能按时完成开发任务, 可以说明你的原因, 尽快的提出来, 别等到最后到了Deadline你说你做不完.
• 或者因为你的bug导致了线上事故, 也没必要遮遮掩掩. 快速的定位问题, 解决问题, 在会议上复盘问题, 最好下次发生同样的状况就好, 也没必要因此给自己很大的心理压力和负担. 常在河边走, 哪有不湿鞋.
• 但是, 对于甩锅这种问题, 没有人不反感. 我不去讨论什么叫甩锅, 我只去讨论怎么避免甩锅这种事情的发生.
  • 在对于需求, 会议, 形成良好的书面文档, 各方进行确认
  • 有问题避免天知地知你知我知, 有问题大家一起沟通, 沟通后形成相关的书面文档
  • 当出现这种问题的时候, 拿出自己的证据来证明自己, 不是老子的锅老子不背

摆正自己和领导的位置

• 对于领导, 你是他的下属, 不管你们是酒友还是烟友或者是pao友, 你对他最重要的是工作的能力和处理问题的能力. 认真对待分配的任务, 做好自己的分内工作, 让他看到你对他在工作上的价值, 才是建立你们工作关系的基础.

合理的看待别人的反对和批评

• 可能每一个参加工作的人都被批评过或者吐槽, 被领导也好, 被同事也好. 在面对批评时, 不要急于反驳. 大家作为成年人, 很少会有人毫无原因和根据的前提下去吐槽你的问题.
• 他提出的问题, 可能就是你切实存在的问题, 他不说, 下一个人也会说, 尽早了解自己的问题并及时改掉不是坏事. 不能不在意, 也不要太在意.

如果你领导或者同事是sb

• 能忍忍, 不能忍就滚. 你不能强迫别人走, 你忍不了, 你自己走.