梦幻泡影Qv'Q

摘要： 学习 Java 业务开发时，排序常被当成一个很直接的需求：按照时间倒序，或者按照金额从大到小排列。然而，真正把结果展示出来以后，还会遇到一个容易遗漏的问题：两条记录的排序字段相同，应该谁在前面？今天想整理的，就是排序规则中并列情况的含义，以及为什么它会影响阅读体验和后续处理。 可以先想象一个订单列表 阅读全文

摘要： 学习 Java 业务开发时，数字看起来总是很直接。一个金额，一个等待时间，一个文件大小，都可以用一个数值传来传去。但当数字跨过方法和系统边界，最容易丢失的往往是单位。今天想整理一个很小的习惯：在命名和接口约定中保留单位，让读代码的人不必依赖记忆猜测数字代表什么。 可以先设想一个等待时间参数，名字只有 阅读全文

摘要： 学习 Java 服务开发时，把异常统一转换成“操作失败”，看起来是一种简单整齐的处理方式。调用方不用看到内部细节，接口格式也比较统一。但当所有失败都只剩下同一句话，调用方往往无法判断应该修改输入、稍后重试，还是联系维护人员。今天想整理的，是如何让错误返回既保留必要含义，又不泄漏不该暴露的信息。 可以 阅读全文

摘要： 学习 Java 业务开发时，默认值经常被当成一个很小的实现细节。字段没有传进来，就补一个零；字符串没有内容，就换成空字符串；配置没有填写，就沿用某个固定数字。这样确实能让程序继续执行，但继续执行并不代表含义正确。今天想整理的，是默认值如何改变输入的解释，以及怎样避免它悄悄隐藏本来需要处理的问题。 可 阅读全文

摘要： 学习 Java 对象建模时，布尔字段看起来是一种很直接的表达方式：是否已支付，是否已取消，是否已发货，每个问题都能回答是或否。然而，当几个字段共同描述同一个业务过程时，单独看都很清楚的答案，组合起来却可能互相矛盾。今天想整理的，就是怎样发现这些组合问题，并让对象能够表达哪些状态真实存在。 先设想一个 阅读全文

摘要： 学习 Java 时，常会听到一个建议：方法不要写得太长。这个建议有助于提醒我们关注复杂度，但如果把它理解为超过若干行就必须拆开，也可能得到另一种难读的代码：每个方法都很短，阅读一次业务却需要来回跳转很多次。今天想整理的，是怎样从职责和变化出发决定方法边界，而不是只盯着代码行数。 可以想象一个计算订单 阅读全文

摘要： 学习 Java 项目时，打开一个不熟悉的工程，经常会同时看到很多包、接口和实现类。每个名字似乎都值得研究，但如果一开始就逐个阅读，很容易记住一堆局部细节，却仍然说不清项目怎样完成一次业务。今天想整理一个更具体的阅读办法：先选择一条能够描述清楚的输入，追踪它经过哪些变化，最后去了哪里。 例如选择一个查 阅读全文

摘要： 写 Java 接口时，参数校验往往是最早补上的一段逻辑：判断必填项是否存在，检查字符串长度，再确认数字有没有超出范围。做完这些，很容易觉得请求已经被检查过，后续只需执行操作。但在订单、库存等会持续变化的场景里，输入格式正确，和操作此刻确实可以执行，是两件需要分别判断的事情。今天想整理的，就是这两类校 阅读全文

摘要： 学习 Java 服务开发时，我曾把超时理解为给某个远程调用填一个数字：超过这个时间就返回错误。可是当一次请求需要排队、访问数据库、调用其他服务，甚至进行重试时，每个环节都单独设置一个看似合理的等待时间，最后加起来却可能远远超过调用方愿意等待的上限。今天想整理的，是把超时当成整次请求的预算来考虑，而不 阅读全文

摘要： 写 Java 批量任务时，我很容易先想到一个循环：查询数据，逐条处理，全部结束后打印成功。这样的实现适合说明流程，却还没有回答真实运行中的一个问题：如果处理到一半停了，下一次从哪里继续？今天整理的这个小主题，就是怎样给批量任务留出恢复的余地，让失败之后仍能说清已经完成什么、还剩下什么。 可以想象一个 阅读全文