摘要：以此类推，有同学可能想到mq，并称使用mq能规避”服务故障“、”服务重启“等某些不稳定因素。 还有同学可能想到分布式锁，在付款请求时加锁，在处理回调时判断锁，使用同步锁机制实现串行处理。 我认为没什么必要，有些小题大做，越简单越好。毕竟，付款终态的变更，不是只靠这次的回调。 看似简单的问题，考验的是综合能力。 阅读全文

摘要：走查我们zhongtai-task（中台的task服务，注意，这个task不是Spring/Java里的task，而是我司业务中的企业用工任务）代码时发现一个问题。 先看下面的方法调用关系 ① TaskJobProxy#updateTaskStatus ② TaskLevyReviewService 阅读全文

摘要：定义明确的参数名/变量名，是软件开发中的一个重要准则。但是，总这么强调，起的作用似乎并不大。许多时候，授人以渔还真不如直接授人以鱼。 阅读全文

摘要：我们所使用的各种编程范式和设计方法，本质上都是围绕这三个方面展开工作。 阅读全文

摘要：本文介绍了公司短信平台聚合系统中，短信通道回调的业务处理方法。文章详细描述了如何通过统一回调接口与合理分层设计优化代码结构，避免烟囱式代码堆砌，提高扩展性和维护性。 阅读全文

摘要：每天所参与的设计沟通、设计评审，有代表性的，我会抽时间记录下来进行分享。在此，也分享给园子里的开发者朋友。 对企业侧，开发人员参考了银行的方式——>让接入方先提交申请，再根据一个申请单号请求下载。 内部呢，则是谁申请就给谁生成（“谁”指的是企业），不申请就不生成。 另外，生成的账单直接作为文件放到了 阅读全文

摘要：统一系统的邮件发送功能。有两个核心数据表：`mail` 表用于存储邮件基本信息，`mail_receiver` 表记录邮件接收者信息。为了优化查询性能，建议创建`Email_Content`表，将大字段分离，以减少主表大小，并可通过定期的数据结转策略，确保热表只存储最近的数据。 阅读全文

摘要：变换一下思路，我们来看看更好的实现方式，让开票与订单彻底解耦。 阅读全文

摘要：表示“待Xx”我们就用to-来表示吧。 阅读全文

摘要：对比来看，升级的技术方案更具有设计感！ 阅读全文

摘要：优秀的程序应该尽可能地规避问题。因此，以后在服务商系统里，当定义包含汉字的字段时，使用 nvarchar2，而非 varchar2。 因此，在服务商系统作为我司系统的小众系统的背景下，Oracle的技术特性我们不一一晓知是可以理解和接受的。而如何在不一一晓知这些技术特性的情况下，能够规避这些技术特性带来的bug，需要我们引起思考和实践摸索。 阅读全文

摘要：“他急急忙忙的跑来了” 可以简写成“他跑来了”，可以简写成“他来了”。但是，不能简写成“跑来了”、“来了”。 阅读全文

摘要：当我们正确理解需求和工作任务，无论使用人类语言，亦或计算机语言，呈现出来时都明确。用人类语言，沟通表达出来时就不会有歧义，用计算机语言，程序实现出来就易读易维护。 阅读全文

摘要：如何保证对账的及时性？ 阅读全文

摘要：用户输入手机号获取验证码时，是先校验手机号是否存在，还是先发验证码？靠谱的程序员一定有答案。 阅读全文

摘要：大家可能迷糊了，你到底要说什么呢？嘿嘿，我其实是想分享我们的一个最佳实践。 阅读全文

摘要：接口幂等性和业务防重复处理是两个事情，是程序防重复执行必须要考虑的两个因素。很多时候，我们要同时结合两者来使用，这就是所谓的双重检查。 阅读全文

摘要：同样表示失败，一些数据状态是FAIL，一些数据状态是FAILED，一些数据状态是FAILURE，一些数据状态还加个前缀如PAY_FAILED/PAY_FAIL，千人千面，这太考验人的记忆力了。 阅读全文

摘要：重复记账会产生什么后果呢？ 阅读全文

摘要：这是典型的程序业务处理的方式。——接收到请求入参后，先进行前置校验，如果校验失败直接中止返回，否则才走后续的业务处理流程。 阅读全文