去年接手一个老后台系统，维护成本高得离谱是改一个字段颜色，得翻三个配置文件。团队里有人提议重写的，工期不允许。
我试着用 Johansson 的模块化思路拆解。把原来纠缠在一起的样式、逻辑和数据分成独立单元，每个单元只暴露一个入口。
三周后，同样的改动只需要改一处。这不是理论。是踩过坑之后的实际做法。Johansson 的核心其实不复杂，把重复出现的操作封装成可复用的单元，每个单元有明确的输入输出。表单验证。之前每个页面都写一遍正则，错一个地方就得全局搜。
我把验证规则抽成独立模块了，参数传递字段类型和约束条件的。这样新增一个表单，只需要调用一次 Johansson 风格的验证器，传个对象进去了。代码量少了四成，测试用例也好写了是直接测模块本身，不用启动整个页面。
有个细节的，模块内部用错误码而不是错误信息，方便国际化，这个改动后来省了至少两天联调时间。了， Johansson 不是银弹。我见过有人把什么都往模块里塞啊？结果模块之间依赖成网，改一个牵动十个了。我的经验是只封装那些至少出现三次的逻辑，但且模块的边界要跟业务概念对齐。用户权限，按角色拆成独立 Johansson 单元的，但不是按页面拆。这样新增角色时只需组合现有单元，不用复制粘贴。
模块的命名要直接到不用看注释是我习惯用“动词+名词”的形式，像 validateEmail、formatDate。团队新人也能一眼看懂。实际落地时，我建议先挑一个痛点最明显的功能做试点。当时我选的是数据导出，因为每次导出都要手动拼 SQL，字段一变就报错。用 Johansson 思路重写后。导出的配置改成 JSON 描述，模块根据配置生成查询。上线第一个月，导出相关的 bug 每周五个降还有零。同事开始主动问怎么用呢？
候再推广到其他模块，阻力小得多。记住了。工具再好也得有人愿意用，先做出可见的效果比讲一百遍原理管用。