工程之道

现象

在实际工程中，很多项目最终走向大规模重构，甚至推倒重来。

原因往往不是技术选型错误。

而是在长期迭代过程中，混乱不断累积，最终达到不重构就无法继续演进的程度。

工程混乱

• 主页 ViewModel 等核心类沦为万能容器，堆积跨界面业务，代码野蛮膨胀至数千行。
• 核心业务方法动辄好几百行，充斥着流水账式的逻辑堆砌，缺乏函数抽象，改动犹如乱麻引线。
• 单个 XML 布局突破两千行且深层嵌套，渲染性能劣化，导致界面重构与复用完全瘫痪。
• 泛滥使用 LiveData，多处改动同一数据源、观察者散落各处，甚至在回调中层层嵌套触发其他数据源，导致数据流向沦为彻底不可逆向溯源的黑洞。
• 缺乏统一数据层抽象，接口响应与原始解析无序混在业务层，动一发而引全身。
• 随手 new Thread 或无节制滥用全局线程池，导致内存泄漏、死锁与任务断流频发。
• 变量与常量充斥着 a、temp、it1、it2、data1 等无意义符号。如不费神摸索，几乎无法理解用途。
• 控制流层层嵌套，if 套 if，switch 套 if，改一个逻辑先滚半天滚动条，搞得眼花缭乱。
• 模块间通过强引用跨界绑定，缺乏接口隔离，追踪一个功能需要点开十几个模块的文件。
• 相同逻辑多处复制粘贴，修改一个 Bug 需要全工程搜索，漏改一个即成线上隐患。
• 分支管理缺乏规范，feature、release、hotfix 混在一起，甚至根本就没有这些分支，版本状态无人说得清。

后果

这些代码通常都能运行，甚至已经在线上稳定运行了很久。

但是，真正的危机往往在变更发生的那一刻瞬间爆发！

修改一个功能

需要先阅读几百行甚至上千行毫无章法的历史代码。

很多时间并没有花在编写核心业务上，

而是花在寻找入口、理解历史逻辑和确认影响范围上。

修复一个 Bug

由于职责混乱、耦合严重，无法快速、精准地评估改动的影响范围。

在线上修复一个 Bug，极易引发难以预料的级联崩溃。

最终形成：修一个 Bug -> 带出两个 Bug -> 再修两个 Bug，简直改之不尽 ！

新增一个需求

历史代码之间已形成了大量脆弱的隐式依赖，

导致改动一个看似独立的边缘模块，却能在蝴蝶效应下，直接击穿完全不相关的核心业务线。

代价

混乱带来的成本不会一次性显现，而是潜伏在每一次需求变更与线上故障中，并加速项目走向不可逆的 “技术债崩盘”。

项目劣化指标

• 新功能开发越来越慢，交付速度呈断崖式下跌。
• Bug 数量越来越多，线上故障率居高不下。
• 任何微小的改动都可能演变为高风险的 “排雷” 行动，开发人员开始害怕并避免修改历史代码。
• 代码彻底天书化，新成员接手时面临极高的认知成本与劝退率。

这一切，皆是混乱吞噬工程秩序的必然结果。

项目最危险的状态也就此来临，不是运行不了，而是虽然还能运行，却已经没人愿意主动继续维护。

目的

规范无法消灭复杂度，但可以阻止复杂度走向失控。

引入本套工程规范的核心目的，就是给项目建立一道防线，让混乱不要轻易蔓延。

规范落地的核心铁律

• 可读性优先：今天写下的每一行代码，未来都需要有人阅读，必须降低后人的认知成本。
• 设计留白：今天做出的每一个关键设计，未来可能要被扩展，必须保持接口的弹性。
• 不留技术债：今天为了赶进度留下的每一个临时补丁，未来都需要有人加倍偿还，必须杜绝短视的特例代码
• 知识内聚：所有的奇葩 Bug 修复、特殊的兼容逻辑，必须沉淀到关键行注释或文档中。

结尾

本开发规范不讨论某种具体技术是否足够先进，也不争辩某种架构是否绝对正确。

因为技术会更新，框架会迭代，工具会淘汰。

但混乱带来的代价始终存在。

因此，这里只关注一件事情：如何减少混乱，建立秩序。