【研发笔记20260120】值得记录：靠谱程序员的回聘

【研发笔记20260120】

🖊️ 应对变化

今天我在审批一个MR。从下面截图中的代码可知，这是在控制返回数据列表的排序——根据状态值进行排序。
页面截图见下方，更直观。

显然，这种实现方式，每当排序发生变化、或者新增状态码的时候，都要改这段代码。耗费开发、测试、发版等人力成本。我找开发者，问他有什么更好的方案。
方案：
方案1：将状态值与排序序号的关系维护到Apollo中。——实时生效，无需发版。适用于经常变化。
方案2：将排序序号维护到AccountOpenStatusEnum枚举中。——代码简洁易读，但这种方式需要依靠程序发版才能生效。变化不经常发生，可以这么做。

✍️ 己所不能反求诸人

服务商报税需求中，有一个功能是每月14号定时触发生成个税汇总数据。

这个功能涉及到我们的两个系统：服务商系统 (SP)、统一计税服务 (TS)。 其中，TS为多个 SP提供计税服务。

我们的开发方案是，定时任务由 SP触发，生成个税汇总由 TS来负责。考虑到数据处理量大，当 SP调用 TS后，TS以异步的方式进行处理。

昨天，TS的开发者找我汇报沟通：为减轻计税服务的压力，他计划让每个 SP错开时间段调用，例如 SP_A0:00触发、SP_B0:10触发、SP_C0:20触发。

己所不能反求诸人。

将系统压力转移给调用方(服务商系统)违背了「接口提供方应对服务质量负责」的原则。

SP_A、SP_B、SP_C是同一套程序代码，虽然可以通过property进行区分，但是，当出现新成员 SP_D的时候，开发者还会想到这个细节吗？即使想到了，他还知道设置成哪个时间点吗？

如果碰巧 SP_D也设置在0:00触发，导致 TS系统出现压力，是谁之过呢？
方案：TS使用 juc.Executors#singleThreadExecutor实现顺序处理。当然，集群模式下，可借助redis自旋锁或消息中间件。

✍️ 值得记录：靠谱的程序员的回聘

经过努力，zaizhou这小伙终于回聘成功了！
刚刚他发微信告诉我，春节后就入职了。
zaizhou同学在当时号称“文档小王子”。他不仅具备清晰的程序设计能力和简洁的代码风格，更难得的是，他输出的技术文档脉络清晰、详尽完整。在那个需求密集、系统整合、框架加固的关键时期，他承担了大量核心开发任务，贡献了智慧、付出了精力。确是个难得的小伙。
阔别3年之久的得力干将重新归来，对我而言，无疑是好消息。
有了zaizhou，一些事情、一些想法更容易落地和实现。
话说回聘，让我想到一个挺有意思的案例。彼年，我们做支付项目，也有回聘一个90年小伙，我们曾经与这小伙一起做过商旅项目。意料之外的是，这小伙的沉稳、踏实、能干的优势却消失殆尽。取而代之的是拖拖拉拉、有事没事下楼抽烟、工作未完成时则嘿嘿了之。这小伙不久后，3个月吧，就被离开了。

环境的变化会改变一部分人，环境的变化也许，会让另一部分人的品质历久弥坚。