private plot

在早期 Markdown 的语境中，符号 > 是引用（Blockquote） 的标记，用来表示这段文字不是作者原文，而是引用他人或前文的内容。

然而，随着 Markdown 在文档与知识写作领域的广泛使用，这个符号逐渐演化为一种语义块的载体——它不仅能表达“引用”，还承担“提示”“结论”“说明”等作用。

在分层架构中，清晰一致的命名能显著提升代码的可读性和可维护性。
本文总结了 Controller / Service / DAO 三层在实际项目中的命名规范与语义边界。

学习 Program Development by Stepwise Refinement 时，我发现自己对排列与组合的理解还停留在直观的乘法原理上，甚至容易混淆两者。

“软件工程的目标是掌握复杂性，而非制造复杂性。”
—— Niklaus Wirth

尼古拉斯·维尔特（Niklaus Wirth，1934–2023）是计算机科学界的先驱之一，他的思想奠定了现代软件工程和编程语言设计的基础。
他以极强的系统思维与简洁美学著称，其核心理念可概括为：简单、高效、系统化。

从 JDK 8 升级到 JDK 17，带来了大量语言级改进。本文整理了一份 语法糖速查表，方便迁移和日常开发时快速参考。

在项目中，我们常常会遇到 Entity → VO 转换 的场景。除了 VO 和 Assembler 的取舍，另一个经常讨论的问题是：查询逻辑应该放在哪里？
这篇文章记录了完整的思考过程。

目标：用 抽象语法树（AST） 的方式剖析英语句子，训练 结构化理解 与 可复用模板化 能力。

快速、可复用的 SQL 与 Excel 批量处理技巧集合，覆盖：关联更新、拼接更新、替换更新、拼接查询以生成初始化 SQL、Excel 自动生成建表语句与 IN 列表。

摘要
在多业务统一入口的场景中，业务类型动态分发与公共逻辑复用是核心挑战。本文总结一种优雅且高扩展的解决方案，涵盖两个重点：

1. 基于自定义注解 + Spring容器 Bean 管理 + 代理兼容实现的策略模式
2. 接口与抽象类配合，定义契约并复用公共实现，实现解耦和结构清晰

1. 注解驱动的策略注册机制（伪代码）

自定义注解

1
2
3
4
5

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
public @interface BizModel {
    String value();
}

策略工厂

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

@Component
public class StrategyFactory {

    private Map<String, StrategyInterface> strategyMap = new HashMap<>();

    public StrategyFactory(Map<String, StrategyInterface> strategies) {
        for (StrategyInterface strategy : strategies.values()) {
            Class<?> realClass = SpringAopUtils.getTargetClass(strategy);
            BizModel annotation = realClass.getAnnotation(BizModel.class);
            if (annotation != null) {
                strategyMap.put(annotation.value(), strategy);
            }
        }
    }

    public StrategyInterface getStrategy(String key) {
        StrategyInterface strategy = strategyMap.get(key);
        if (strategy == null) throw new RuntimeException("未找到策略：" + key);
        return strategy;
    }
}

策略实现示例

1
2
3
4
5
6
7
8
9

@Service
@BizModel("业务标识1")
public class ConcreteStrategyA extends AbstractStrategyBase {

    @Override
    protected void doBusinessLogic(DTO dto) {
        // 业务特有逻辑实现
    }
}

2. 接口 + 抽象类的协同设计（伪代码）

定义接口（契约）

1
2
3

public interface StrategyInterface {
    void execute(DTO dto);
}

抽象类（公共流程模板）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

public abstract class AbstractStrategyBase implements StrategyInterface {

    @Override
    public void execute(DTO dto) {
        validate(dto);
        preProcess(dto);

        doBusinessLogic(dto);  // 子类实现差异化

        postProcess(dto);
    }

    protected abstract void doBusinessLogic(DTO dto);

    private void validate(DTO dto) {
        // 公共校验逻辑
    }

    private void preProcess(DTO dto) {
        // 公共预处理
    }

    private void postProcess(DTO dto) {
        // 公共后处理
    }
}

3. 运行时调用示意（伪代码）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

@RestController
public class Controller {

    private final StrategyFactory factory;

    public Controller(StrategyFactory factory) {
        this.factory = factory;
    }

    public Response handleRequest(RequestDTO dto) {
        StrategyInterface strategy = factory.getStrategy(dto.getBizModel());
        strategy.execute(dto);
        return Response.success();
    }
}

总结

利用注解驱动 + Spring自动装配实现业务类型到策略实现的动态路由，方便扩展。
通过接口定义契约，抽象类封装公共流程，实现代码复用与解耦。
设计既减少重复代码，又保证系统灵活性和维护便利。

摘要
这是一篇对自己的复盘文章，从职业习惯、思维模式和生活方式三个角度，总结了我的优势与不足，并提出了具体的改进方法。核心关注点是如何在保持专业与细节追求的同时，降低完美主义带来的成本、提高沟通效率、减少任务切换的损耗。

前言

这篇文章是一次对自己的回顾与整理，结合近期的工作习惯、技术思路以及生活节奏，总结我是什么样的人、有哪些不足，以及针对不足的改进方向。

我的特点

1. 专业能力强
   作为一名 Java 后端开发者，我在业务实现中注重代码质量，熟悉 Clean Code 原则，能写出简洁、易测、结构清晰的代码。对 SICP 这类计算机科学经典思想也有一定的理解，并在实践中贯彻。

2. 逻辑严谨
   处理问题时习惯从原理层面切入，比较不同方案的优劣，而不是仅停留在能用的层面。

3. 学习驱动
   主动钻研 SQL、网络、编译原理等底层知识，保持对技术细节的敏感。

4. 生活有节奏
   饮食、作息相对稳定，有长期健康意识。

5. 审美有取向
   偏好含蓄的东方美学，这种审美观也影响了我对代码和设计风格的追求——克制、简洁、有韵味。

我的不足

1. 完美主义倾向
   常常在功能已可用的情况下，花额外精力去打磨细节。例如，在简单的字符串拼接中犹豫要不要用 String.format，或者在 Maven 打包已正常完成的情况下，仍想验证编译警告是否影响速度。这种追求虽然保证了质量，但容易在非关键环节投入过多时间。

2. 信息密度过高
   在沟通时倾向一次性提供大量上下文与技术细节。虽然信息完整，但接收方需要先拆解再理解，降低了沟通效率。

3. 任务切换成本高
   在深入一个任务后切换到另一任务时，需要花时间恢复思路。这与记忆力关系不大，更多是处理问题方式造成的：我倾向长时间深度专注，但缺少任务切换前的“外部缓存”动作。

改进方向

1. 优先级分层

• 方法：使用“30 秒优先级评估法”快速判断当前优化是否影响核心功能或交付时间。
• 目标：每天至少推迟 1 个非关键优化任务，观察是否对结果造成实际影响。

2. 降低信息密度

• 方法：采用“3 段式提问法”——背景一句话、问题一句话、补充信息按需提供。
• 目标：每天至少用一次 3 段式提问，评估反馈速度。

3. 减少切换损耗

• 方法：切任务前，用 1-2 句话记录当前进度与下一步动作，作为外部缓存。
• 目标：每天记录 3 次切换笔记，确保切回任务时能在 2 分钟内进入状态。

结语

这不是一次对自己的苛责，而是一次客观的整理与优化。
优势要保持，不足要改进，习惯要固化。
持续的小改进，会带来长期的大变化。