被新领导约谈，我差点辞职上周五，新来的总监把我叫进会议室。聊了40分钟，核心就一句话:你的产出，我看不到价值。

上周有个网友吐槽，新领导找他聊了40分钟，说他的产出看不到价值。很多开发遇到这种反馈，第一反应都是怀疑自己是不是写代码没用。但我以前接手过类似项目，后来发现问题往往不在代码写得少，而在开发交付的东西无法被业务和团队感知。

有些后端开发每天改接口、修Bug、调SQL，看起来很忙，但一年后回头看，系统没有留下任何可复用的能力。新负责人接手后，很难判断这个人的贡献，因为大量工作停留在“处理问题”，没有沉淀成稳定的系统能力。

我遇到过一个订单系统，早期开发节奏很快，业务要求上线支付、退款、发货，大家每天追需求。订单状态直接散落在几个Service里，谁接到需求就在对应位置加一个判断。

当时这套代码能跑，而且上线速度很快。

比如最初的退款逻辑类似这样：

public void refund(Long orderId) {

  Order order = orderMapper.selectById(orderId);

  if ("PAID".equals(order.getStatus())) {

      paymentService.refund(orderId);

      order.setStatus("REFUND");

      orderMapper.updateById(order);

  }

  if ("DELIVERED".equals(order.getStatus())) {

      throw new RuntimeException("cannot refund");

  }

}

这段代码上线没有问题，业务量小时甚至很稳定。但半年后订单状态越来越多，增加“部分退款”“售后退款”“人工退款”以后，类似判断散落在十几个地方。

新人不知道哪个状态能退款，产品问规则在哪里，大家只能翻代码。

这个时候开发每天做的事情还是很多：处理线上问题、加字段、改接口。但这些工作很难体现价值，因为系统能力没有形成资产。

后来排查退款异常时，我一开始也判断错了方向，以为是支付渠道偶发失败。查日志以后发现，真正的问题是订单状态修改没有统一入口。

一次请求可能先调用支付退款，再修改订单状态，中间任何一步失败，数据就可能停在半完成状态。

后面的修改不是简单重构一个类，而是把业务规则收回来。

我们增加了状态流转控制：

public class OrderStateMachine {

  private static final Map<String, Set<String>> TRANSITIONS = Map.of(

      "PAID", Set.of("REFUNDING", "DELIVERING"),

      "REFUNDING", Set.of("REFUNDED"),

      "DELIVERING", Set.of("DELIVERED")

  );

  public void check(String from, String to) {

      Set<String> next = TRANSITIONS.get(from);

      if (next == null || !next.contains(to)) {

          throw new IllegalStateException(

              "invalid order transition"

          );

      }

  }

}

订单状态变化必须经过统一校验，业务规则从人的经验变成代码约束。

之后退款流程也调整了，不再直接修改订单：

@Transactional

public void startRefund(Long orderId) {

  Order order = orderMapper.lockById(orderId);

  stateMachine.check(

      order.getStatus(),

      "REFUNDING"

  );

  orderMapper.updateStatus(

      orderId,

      "REFUNDING"

  );

  refundTaskService.create(orderId);

}

这里有两个变化。

第一个是数据库查询增加锁，避免两个退款请求同时处理。

第二个是退款动作拆成任务，不让订单状态和外部支付调用绑死在一个事务里。

以前开发的价值体现在“今天解决了几个问题”，后来价值体现在“以后少出现多少问题”。

这类改造在日常开发里不一定马上被看到。没有明显页面，没有新增接口，甚至提交记录看起来只是改了几个类。但它解决的是系统长期维护成本。

很多开发被评价“产出低”，并不是因为写代码少，而是代码没有形成团队可以依赖的能力。比如一次线上事故后，补充了监控规则；一个重复Bug被修复后，抽成统一组件；一个靠新人记忆维护的流程，被写进状态机和测试。

这些事情不会像完成需求一样有明确的截图，但它们会改变系统质量。

后来那个订单系统再有人接手，开发新人不需要问“这个状态为什么不能改”，因为代码已经告诉他答案。

后端开发真正难的地方，不只是把需求变成接口，而是在需求不断变化的时候，让系统还能被理解、被修改、被验证。这样的产出，才不会随着某个人离开而消失。