模块可以单独编译吗：理清依赖边界与独立构建的工程实践

有朋友在群里发来一个问题:模块可以单独编译吗。我盯着屏幕想了半天,决定反问他:你说的“模块”,到底是硬件模块、固件模块,还是Maven里的一个子模块?这三者的答案完全不同。而更有意思的是,这个问题本身,往往暴露了工程组织方式里最容易被忽略的一环——你到底有没有把项目拆到“可以独立构建”的程度。

很多人把写代码做成一个大文件包,嘴上说着模块化,实际只是按目录塞了几个文件夹。真正遇到“模块可以单独编译吗”这个问题时,第一反应不是答不上来,而是发现自己的工程根本经不起这么一问。这篇内容不打算只给一个“能”或者“不能”的结论,而是把软件、嵌入式、硬件这几个领域里的“模块编译”全部摊开聊一遍,结合我在实际项目里踩过的坑,帮你看清楚各自的边界、条件和常规做法。

1. 先把概念摊开:不同领域的“模块”,编译含义完全不同

我这些年见过太多提问翻车现场,根本原因就是把几个行业里的“模块”当成同一个词来用。软件工程师说的模块,通常是Maven/Gradle里的一个子工程,或者是Java 9之后的module;嵌入式工程师说的模块,既可能是芯片厂商的驱动代码,也可能是树莓派摄像头那类硬件外设;而纯硬件领域里说的模块,比如光模块、IGBT模块、TB6612电机驱动模块,压根就没有“编译”这个动作,只有选型、接线、调试。

所以在回答“能不能单独编译”之前,先把对象定义清楚,后面才有得聊。

上面这张表是我后来经常拿来做科普的。真正卡住新手的,往往不是技术操作,而是没分清楚“模块能独立编译”和“模块能独立运行”这两个问题。能单独编译,只代表这个模块的源码在给定依赖条件下可以通过编译;能不能单独运行,取决于它依赖的外部环境、接口、硬件是否齐备。很多人编译一个驱动模块成功了,兴奋地拿到板子上跑,发现毫无反应,然后怀疑编译命令有问题——其实问题出在硬件链路上,这跟编译的关系不大。

1.1 硬件模块为什么没有“编译”这个概念

拿TB6612电机驱动模块来说,它是一块物理电路板,上面有电源接口、逻辑输入引脚、电机输出引脚。你问“TB6612模块可以单独编译吗”,这个问题在纯硬件语境下是不成立的,因为它没有可编译的代码。真正需要编译的,是你在单片机工程里为它写的驱动文件,比如tb6612.c。如果你的工程能单独编译tb6612.o,说明驱动代码本身素质不错,但和那块绿色电路板能不能跑起来是两码事。

同样的例子还有树莓派OV5647摄像头模块。这个传感器上电之后,能不能出图,取决于三件事:内核里有没有对应的驱动、设备树配置是否正确、硬件排线有没有插好。哪怕你把驱动文件编译得再干净,排线松了照样没有图像。这也是我特别想提醒新手的一点:硬件模块领域的“编译”,对象永远是软件,不是硬件本身。

1.2 软件模块又分项目级、语言级和代码级

软件开发里的“模块”至少有三种层次。第一层是项目结构上的模块,比如IDEA里创建的一个多模块Maven工程,user-service、order-service是不同子模块;第二层是语言层面提供的模块机制,比如Java 9之后的module-info.java,它能在编译期限制包之间的访问;第三层则是大家口头说的“代码模块”,可能只是把相关的几个类放进同一个包。

这三种层次里,能直接回答“可以单独编译吗”的,其实是第一层。IDEA里右键一个子模块,选择Build Module,IDE会只编译这个模块。但要注意,IDE做这件事时,如果模块之间没有依赖关系,自然很顺利;一旦模块A依赖模块B,而模块B没有先安装到本地仓库,那么A的单独编译照样会报错。后面我会专门讲这个场景。

2. 单独编译的底层逻辑:编译单元、依赖边界和产物管理

我们经常会遇到一个诡异现象:单独编译某个模块,能过;整个项目一起编译,却挂了。或者反过来,整个项目构建没问题,单独编译其中一个模块,一直找不到依赖。这背后的核心是“编译单元”和“依赖边界”不匹配。

单个源文件(比如Java的一个.java文件、C的一个.c文件)是最小编译单元。如果你只写了这一个文件,内容再复杂,编译器也能直接处理。但项目一旦开始分模块,编译单元就从“文件”升级成了“模块”。这时,编译器要正确编译模块A,不只是看A自己的源码,还要能解析出A引用的外部类、函数、宏定义在哪儿。这些外部依赖有的来自同一个仓库里的另一个模块,有的来自第三方库,有的甚至是本机环境变量。

我习惯用一个比喻来解释:单独编译一个模块,就像你想单独装修大楼里的一个房间。房间里面的墙纸、地板当然可以自己做;但你计划在墙上新开一扇门,这就要考虑楼体的承重结构;你想接独立空调,得看大楼有没有预留外机位。源码写成什么样只是房间内部的事,依赖关系才是大楼的总管。很多模块拆完依然编不动,就是因为这个模块的“房间”开了一堆墙洞,每一处都依赖别人。

2.1 编译期依赖比运行期依赖更容易让人抓狂

依赖有两种:编译期依赖和运行期依赖。编译期依赖的意思是,编译模块A时,必须要能找到模块B里定义的某个类或者函数;运行期依赖则是程序跑起来之后,需要从某个地方加载模块B的实现。很多人以为把模块B的jar包放进classpath就能单独编译A,结果确实编译过了;但部署运行时忘了把B的jar带上,程序启动直接报ClassNotFoundException。这就是编译期依赖和运行期依赖没对齐。

在C/C++里同理。头文件声明了函数,编译当前.c文件时只需要头文件;但链接成可执行文件时,需要有函数的实现。所以我说CMake里add_library比直接把所有源文件扔进一个可执行文件里更符合模块化精神,因为库类型的目标天然支持“独立编译+最后链接”,而单一可执行文件目标一旦源文件多了,每次构建都要把所有文件重新过一遍。

2.2 单独编译的真正价值是“独立替换”

有人可能会问:既然整个项目一起编译也能出结果,为什么非要追求单独编译?原因是,大型工程根本消耗不起全量构建。我待过的项目里,前端十几个子应用、后端几十个Spring Boot服务,如果每次改动都要全量打包,一次CI跑下来少说半小时。模块可以单独编译之后,开发者在本地只编译自己负责的那个模块,几十秒就能验证;CI里也只构建发生变更的模块,发布效率完全不同。

更重要的是,能单独编译的模块,才有资格谈“独立替换”。你修好了一个支付模块的Bug,只需要把支付模块的新产物单独发布出去,其他模块不用跟着动。反过来,如果模块之间耦合严重,一处改动牵扯十处重编,那这个模块即使代码上分了目录,也没有获得模块化的好处。这个问题在架构评审时我会反复问:这个模块脱离系统主体之后,换一个环境能不能自己编译起来?能,才算边界划对了。

3. 软件工程里“怎么单独编译一个模块”的常规答案

先说高频场景:基于IDEA的Java多模块项目。很多人从Git上拉下一个工程,里面十几个子模块,同事说“你只需要跑user-service”,结果一编译,user-service找不到order-api里的类。还没开始干活,先被依赖折磨一轮。下面我按构建工具分别说。

3.1 Maven多模块:记住-pl和-am这对组合

Maven官方对多模块项目的支持很成熟。假设工程结构是:

text复制parent-pom
├── module-common
├── module-dao
├── module-service
└── module-web

每个子模块都有自己的pom.xml,父pom通过<modules>声明它们。你站在父工程目录下,想只构建module-web,并让Maven自动把module-web依赖的module-common和module-service一起构建,命令是:

bash复制mvn -pl module-web -am clean package

-pl是--projects的缩写,指定要构建的模块;-am是--also-make的缩写,意思是把指定模块依赖的其他模块也加到本次构建里。如果不加-am,只执行:

bash复制mvn -pl module-web clean package

Maven在解析module-web的依赖时,会优先在本地仓库里找module-common和module-service的jar包。如果这两个模块此前从来没有mvn install过,本地仓库里没有,构建就会报错,提示找不到依赖。

所以我的建议是:开发初期先把公共模块install一次,让它们躺进本地仓库,之后就可以放心地用-pl单独构建任意叶子模块。公共模块一旦更新,记得重新install。社区里很多人管这个叫“先上车后补票”——你直接让叶子模块单编,等于没买票就要上车。

3.2 Gradle子工程:用冒号路径定位模块

Gradle多模块工程里,模块通常也叫子工程(subproject)。在settings.gradle中用include声明,比如:

groovy复制include 'module-common', 'module-service', 'module-web'

根目录下执行:

bash复制gradle :module-web:build

如果module-web依赖module-common,Gradle会自动找出这个依赖并先构建module-common。Gradle的依赖分析比Maven更“懒”,它会在任务图里自动加入依赖项目必要的任务。实际体验下来,只要子工程之间的依赖用api或implementation声明正确,单独构建某个子工程很少出幺蛾子。

3.3 CMake/Make环境:把每个模块编成库目标

C/C++工程里,我推荐用CMake把每个模块建成一个库目标,然后再用一个可执行目标把库链接起来。

cmake复制cmake_minimum_required(VERSION 3.16)
project(ModuleDemo)

add_library(module_common STATIC common/logger.c common/utils.c)
target_include_directories(module_common PUBLIC common)

add_library(module_service STATIC service/order_service.c)
target_link_libraries(module_service PUBLIC module_common)
target_include_directories(module_service PUBLIC service)

add_executable(app main.c)
target_link_libraries(app PRIVATE module_service)

这样配置之后,单独编译module_service:

bash复制cmake --build build --target module_service

CMake会自动判断module_service依赖module_common,先把module_common编译出来。如果你真的想把某个模块从默认构建里摘掉,只让它按需编译,可以在add_library时加EXCLUDE_FROM_ALL选项。不过这个选项要慎用,因为默认构建不会生成它,最后链接可执行文件时会发现少东西。

Makefile场景更直接,你可以在子目录里为驱动模块各写一个Makefile,然后在顶层用subdirs统一调度。只想编译某个模块时,进入对应子目录执行make,或者用顶层Makefile里的target调用子目录。嵌入式IDE里的增量编译,底层原理也差不多。

3.4 IDEA构建单个模块的右键操作

IDEA用户最简单的方式,是在Project窗口找到对应模块,右键选择Build Module 'module-web'。这个操作只会编译你选中的模块。但请注意,IDEA的Build Module并不等同于Maven的mvn package,它不会执行打包、测试、代码检查等完整生命周期,只是把源码编译成class并放进out目录。如果你要的是最终可发布的jar包,还是得走Maven/Gradle任务。

还有一个容易被忽略的坑:IDEA的缓存。有时你明明改过公共模块的代码,单独编译另一个模块时,IDEA用的还是旧的编译输出,导致找不到新方法或新类。我处理这类问题一般用File -> Invalidate Caches刷新缓存,或者执行一次全量Rebuild Project。

3.5 有些“模块”虽然叫模块,但不需要传统编译

Python里的subprocess、易语言里的hook模块,这些词也被叫做“模块”,但它们走的是解释执行或专用语言运行时,没有传统意义上“编译成机器码”的过程。比如Python的一个.py文件可以直接被import,你说它“单独编译”吗?最多用py_compile把它变成.pyc字节码,但大部分时候没必要。如果你问的是这类模块,问题本身就偏了——你想做的应该只是引用它、调用它,而不是编译它。

4. 嵌入式与硬件侧:“模块编译”的真实战场

嵌入式这块特别有意思。很多人拿STM32写外设驱动,问“按键模块能不能单独编译”“DS3231模块能不能单独编译”“HC05蓝牙模块能不能单独编译”。实际上,你用的是Keil、IAR或者STM32CubeIDE这种IDE,工程里有一个个的group(分组),每个group下面挂源文件。所谓的“单独编译”,通常就是只编译某一个.c文件,生成对应的.o文件,其他文件不动。这是IDE增量编译的基本功能,按一下编译,它会自动判断哪些文件改了、哪些没改。

但要注意,即使单独编译某个驱动文件成功了,最终还是要链接成一个完整的固件烧进MCU。因为STM32里没有操作系统帮你动态加载驱动,所有代码必须整体链接成bin/hex才有意义。所以嵌入式里的“单独编译”更多是“单独重编译这一个模块”,而不是“输出一个可单独运行的东西”。

4.1 树莓派摄像头OV5647这类场景到底在编译什么

树莓派Camera Module上的传感器就是OV5647。如果你用的是官方系统,驱动早就编进内核或者作为模块加载了,你不需要为它单独编译任何东西,插上排线改一下config,txt或者设备树就能用。真正需要单独编译的,是你自己修改了驱动源码,或者交叉编译一个外部内核模块,想生成一个ov5647.ko之类的文件。

编译树莓派摄像头驱动这类内核模块,前提是要有对应的内核头文件。如果你直接用官方内核,可以先用uname -r确认版本,再安装匹配的内核头文件包。编译外部模块时,Makefile通常长这样:

makefile复制obj-m += ov5647_test.o

all:
    make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:
    make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

执行make之后,如果顺利,目录下会出现ov5647_test.ko。这个.ko才是真正的内核模块产物,可以用insmod或者modprobe加载。很多从没编过内核模块的人第一次看到“编译成功但不生效”,大概率是内核配置里驱动的状态不是m(模块),而是y(内建),或者设备树里没有把摄像头节点使能。这个问题和编译命令本身没关系,排查方向要往硬件和配置上走。

4.2 STM32里把驱动文件拆成可独立编译小组的工程组织

给STM32写代码时,我习惯把每个外设模块拆成一个文件夹,比如port/、driver/、app/。driver下每个传感器一个子目录,里面是.c和.h。Keil工程里这些源文件天然会单独编译,但你真正要关注的“模块边界”,是头文件的包含关系。

有些同事写驱动,头文件动不动就#include整个工程的头文件,导致改一个全局配置,所有模块都得重编。模块化做得好的工程,每个驱动模块对外暴露的头文件应该尽量少,能用前置声明解决的就不include进来。比如DS3231模块头文件里,只需要依赖I2C接口的抽象类型,不需要知道具体是硬件I2C还是软件模拟I2C。这样模块代码可以在不同板子上复用,也更容易拍着胸脯说“我这个模块在哪都能单独编译”。

4.3 纯硬件模块的“选型与调试”视角

光模块、IGBT模块、AD9833模块、INA226模块这类纯硬件模块,跟“编译”二字基本绝缘。以IGBT模块为例,大家讨论的是开通时间、关断时间、散热、驱动电阻这些跟电路参数有关的东西,没有源码参与。AD9833模块虽然是可编程DDS信号发生器,但你要做的是用SPI向它的寄存器写配置,而不是编译它。INA226是I2C电流/电压监控芯片,开发时同样只需要写主机端的驱动。

如果把“单独编译”延展成“单独调试”,那硬件模块反而天生适合单独调试。买一块AD9833模块、一块STM32最小系统板、一个INA226模块,把它们用杜邦线连起来,先单独让STM32通过SPI给AD9833输出正弦波,再单独读INA226的寄存器,最后拼到一起。这种“先各自验证,再整机联调”的思路,和软件模块化里的“单独编译、独立替换”哲学是完全一致的。硬件工程师虽然不说“编译”,但他们在做的同样是通过边界隔离来降低联调复杂度。

4.4 配置类工具里的“模块编译”又是另一回事

还有一类提问来自工具链,比如Autosar的ECUC模块、Simulink的一阶滤波模块。Autosar开发里,ECUC负责ECU配置,里面的模块配置项可以按模块生成代码。这里所谓的“单独编译”,其实是代码生成步骤的粒度。你可以在配置工具里只生成某一个组件的代码,但最终ECU的集成还是要把所有生成代码放进统一工程编译。

Simulink里的模块不一样,它是图形化的功能模块。一阶滤波模块并不是“编译”出来的,而是你在模型库里拖出来的算子。只有在使用Embedded Coder做代码生成时,Simulink才会把模型转换成C代码,这时候才谈得上编译。所以这类问题,答案不是简单的能或不能,而要看工具链是否把“模型模块”映射成了独立代码单元。我的建议是,遇到这类问题别凭直觉回答,先去查清楚工具链的生成配置和依赖顺序。

5. 完整实操:把真实工程里的一个模块单独拎出来编译

这一节我给一个可以照着敲的Maven示例。假设你要基于IDEA创建一个新的多模块项目,其中有一个公共模块module-common和一个业务模块module-service,单独编译module-service时自动带上module-common。

5.1 从IDEA创建父工程开始

第一步,在IDEA里新建一个空的Maven工程作为父工程。父工程只负责聚合和管理版本,不写业务代码。建好之后,把src目录删除,只保留pom.xml。父pom大概长这样:

xml复制<project>
    <groupId>com.demo</groupId>
    <artifactId>parent-project</artifactId>
    <version>1.0.0-SNAPSHOT</version>
    <packaging>pom</packaging>

    <modules>
        <module>module-common</module>
        <module>module-service</module>
    </modules>
</project>

关键点:packaging必须是pom,Maven才会把它当聚合工程。

第二步,在父工程上右键New -> Module,创建一个Maven子模块,artifactId填module-common。子模块里写一个普通的工具类,比如:

java复制package com.demo.common;

public class StringUtils {
    public static boolean isEmpty(String s) {
        return s == null || s.length() == 0;
    }
}

第三步,再创建一个module-service子模块,并在它的pom.xml中加入对module-common的依赖:

xml复制<dependencies>
    <dependency>
        <groupId>com.demo</groupId>
        <artifactId>module-common</artifactId>
        <version>1.0.0-SNAPSHOT</version>
    </dependency>
</dependencies>

5.2 用命令行单独编译业务模块

现在打开终端,进入父工程根目录,执行:

bash复制mvn -pl module-service -am clean compile

注意我加了-am。Maven解析module-service的pom时,发现它依赖com.demo:module-common,而这个依赖在本地仓库还不存在。加上-am之后,Maven会返回父pom的modules列表,找到module-common,把它一并纳入本次reactor构建。执行日志里你会看到两个模块都被编译了,先是module-common,然后是module-service。

如果你分别进入module-service目录,直接执行mvn compile,会发生什么?Maven会去本地仓库找module-common的jar。因为还没install过,编译报错。想解决,先到父工程目录执行:

bash复制mvn -pl module-common -am install

或者在父工程根目录执行mvn install,把module-common安装到本地仓库。之后,你才可以在module-service目录里单独执行mvn compile或者mvn package,享受“远程依赖已就绪”的快感。

5.3 验证产物和依赖关系

模块单独编译成功后,module-service/target/classes下会有编译好的.class文件。执行mvn package并跳过测试(测试代码还没写,没必要跑):

bash复制mvn -pl module-service -am package -DskipTests

这会在module-service/target下生成jar包。此时查看jar内容,你会发现它里面只有module-service自己的类,不会包含module-common的类。原因是Maven默认打的是普通jar,不会把依赖打进包内。如果你需要可执行jar,还要配置spring-boot-maven-plugin或者shade插件把依赖合进来。这个细节经常有新手搞混:单独编译成功后,以为jar包可以独立运行,结果java -jar一执行,直接ClassNotFoundException。

5.4 CMake版实操:把模块建成独立库目标

如果你维护的是C/C++工程,也可以用CMake把模块变成独立的库。顶层CMakeLists.txt写:

cmake复制cmake_minimum_required(VERSION 3.16)
project(ModuleDemo C)

add_subdirectory(module_common)
add_subdirectory(module_service)
add_subdirectory(app)

module_common/CMakeLists.txt:

cmake复制add_library(module_common STATIC logger.c utils.c)
target_include_directories(module_common PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})

module_service/CMakeLists.txt里依赖module_common:

cmake复制add_library(module_service STATIC order_service.c)
target_link_libraries(module_service PUBLIC module_common)

app/CMakeLists.txt:

cmake复制add_executable(demo main.c)
target_link_libraries(demo PRIVATE module_service)

然后依次执行:

bash复制cmake -B build
cmake --build build --target module_service

第一次执行cmake -B build会生成构建系统。第二次执行时,构建系统会先构建module_common再构建module_service,即使你只指定了module_service目标。因为CMake知道module_service依赖module_common的静态库。

有时你想让某一个模块不参与默认全量构建,可以加EXCLUDE_FROM_ALL:

cmake复制add_library(module_extra STATIC extra.c)
target_include_directories(module_extra PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})
set_target_properties(module_extra PROPERTIES EXCLUDE_FROM_ALL TRUE)

这样直接cmake --build build不会构建module_extra,只有显式指定--target module_extra时它才会编译。这种技巧适合那种“备用模块”,平时不参与主产品构建,需要时单独出包,非常契合“模块可以单独编译吗”这个场景。

6. 常见问题与排查技巧实录

下面这些问题是过去三年里我被问得最多的,每一条背后都是一次真实的“白屏十分钟”。

6.1 单模块编译成功,整包构建反而失败

这个问题最常见的原因是“只单编,不安装”。很多人在IDEA里直接执行了module-service的mvn install,结果它依赖的module-common还是老版本,module-service引用了一个公共模块新加的类,编译自然过不去。单独编译能过,通常是IDE自动帮你做了模块间依赖的编译,或者在当前reactor里包含了module-common;执行整包mvn install时,如果模块间版本没对齐,照样会失败。

我处理这类问题的顺序是:

1. 先确认改动范围:这次改动只在module-service,还是也动了module-common。
2. 动了公共模块,就先把公共模块install,再编译依赖方。
3. 如果还报找不到符号,去本地仓库看公共模块jar的时间戳,确认install是否真的成功。

6.2 依赖版本冲突,编译通过但运行期行为诡异

这个问题隐蔽性很高。模块A依赖模块B的1.0版本,模块C依赖模块B的2.0版本,单独编译A和C都没问题,但合到一起时,Maven/Gradle会仲裁出一个版本。如果仲裁结果不对,你在模块A里调用的一个方法可能在新版本里已经改过签名,编译期也许还不会立刻暴露,运行期就会出现各种奇怪行为。

排查思路是看依赖树。Maven用:

bash复制mvn dependency:tree

Gradle用:

bash复制gradle :module-service:dependencies

看到两次不同版本的B模块出现在依赖树里,就要考虑在父pom或settings.gradle里显式统一版本。这算是我日常最常用的排障命令之一。

6.3 硬件侧“编译通过但没反应”的排查顺序

嵌入式里“单独编译成功”和“板上功能正常”之间差了十万八千里。以DS3231模块为例,你写了I2C驱动,编译没问题,但读不到时间。排查顺序应该是:

• 先确认模块供电电压。DS3231一般支持2.3V到5.5V,但有些模块背面带了充电电路,接法有讲究。
• 再查I2C地址。DS3231的默认地址是0x68,如果你的驱动里写成了0x57,编译照样通过,读出来全是错数据。
• 最后查上拉电阻。I2C总线需要上拉,如果你的模块不带,而主控内部上拉没开启,通信大概率失败。

这些全和“编译”没有关系,但恰好是“模块可以单独编译吗”这个问题在硬件领域最容易踩的坑。很多新手把编译成功当成了万事大吉,真正有经验的工程师会在编译之外建立一整套自检流程:查供电、查引脚、查地址、查波形。

6.4 缓存和旧包问题

这种问题最容易消磨耐心,因为代码明明改对了,构建结果就是不对。Maven本地仓库里的SNAPSHOT包可能被CI重复覆盖,Gradle daemon可能缓存了旧配置,IDE的增量编译也可能漏编文件。

我的处理习惯是三步走:

1. 先把对应模块clean,再做一次编译,排除无效class残留。
2. Maven项目可以在命令行加-U强制刷新快照。
3. 再不行,直接删掉本地仓库里对应模块的目录,重新install一次。

IDEA用户可以顺手执行一次Build -> Rebuild Project,很多时候莫名其妙的问题就没了。你要理解,编译器本身很诚实,问题往往出在你给了它一份旧代码或旧依赖。

6.5 “问错对象”的问题怎么答

最后一种情况,提问的人根本不在写代码。比如有人问“下载到模块HMI_RT_1时出错”,这听起来像组态软件或者PLC场景里的通信问题,而不是编译问题。还有“西门子S7-1500的TM Timer模块右侧能另外连接模块吗”,这是硬件扩展的问题,跟编译一点关系都没有。

我现在的习惯是,遇到“XX模块能单独编译吗”,先判断对方讲的是哪种模块,再决定回答方向。如果是硬件模块,我会告诉他不需要编译;如果是驱动代码模块,我会问他用的什么IDE和工具链;如果是Maven/Gradle模块,我会让他把父pom和依赖关系发出来。先把概念对齐,问题已经解决一半。

回到我自己的习惯:现在每接手一个新项目,我做的第一件事不是急着写业务代码,而是先把模块边界和构建方式定下来。模块能单独编译,应该作为一条默认标准写进项目的开发规范里。每次提交代码之前,我会在命令行手动执行一次目标模块的独立构建,而不是只依赖IDE的编译按钮。CI里也会把“模块级构建”作为流水线的一个阶段。坚持这样做之后,我很少再遇到“发布前全量构建炸掉”的情况——因为每一个零件在出厂前都已经单独检验过了,最后整机装配自然顺畅得多。

如果你现在维护的工程还不能单独编译某个模块,我建议你从最小的非业务公共模块开始试。先把它的依赖理清,把它做成一个可以被上层模块依赖的独立产物,再逐步往业务模块推广。这个过程会很痛苦,甚至会让你想把之前随手写的意大利面条式依赖全部推翻重来。但只要熬过第一轮拆分,后面新写的模块都会下意识遵循同样的边界规则,整个工程的构建体验会越来越轻快。下次再有人问你模块可以单独编译吗,你就可以直接回答:可以,但前提是,你愿不愿意把依赖边界和构建计划交给工具,而不是靠脑补。