何时在Databricks笔记本中进行代码模块化？

问题描述 #

我了解可通过%run命令在Databricks笔记本中实现代码模块化，但不确定具体何时（在什么阶段）这么做。目前我有一个完成特定任务的笔记本（拆分该笔记本并无意义），但其中包含大量函数，导致笔记本篇幅过长，阅读起来有些混乱。我不确定是否应该将这些函数拆分到另一笔记本中，再通过%run调用。请问这种做法何时是最佳实践，何时不适用？

当前笔记本代码示例：

def funct1():
    ...
def funct2():
    ...
# -- kind of main --
# code where I run the functions.

目标拆分后的实现方式：

%run notebook_where_I_have_the_functions.py
# code where I run the functions
funct1()
funct2() 

最佳实践场景：应该拆分函数到独立笔记本 #

• 函数存在跨笔记本复用需求：如果这些函数会被其他任务的笔记本调用，拆分后通过%run引入，能彻底避免重复编写相同代码，提升维护效率。
• 主逻辑被辅助函数淹没：当大量通用函数让当前笔记本的核心业务流程变得模糊时，拆分后主笔记本只保留业务执行代码，可读性和可理解性会显著提升。
• 函数需要独立迭代或测试：如果这些函数有单独的更新需求，或者需要编写针对性的测试用例，拆分到独立笔记本后，修改和验证都不会干扰主业务代码。
• 团队协作场景：多人协作开发时，抽离通用函数为独立模块，不同成员可以专注于各自负责的部分，减少同一长笔记本内的代码冲突。

不适用场景：无需拆分函数 #

• 函数仅服务于当前笔记本：如果这些函数是为当前任务量身定制的，没有任何复用价值，拆分反而会增加文件数量，徒增管理成本。
• 函数与主逻辑耦合度极高：如果函数和主代码之间存在大量紧密依赖（比如频繁共享变量、修改同一数据集状态），拆分后会大幅提升调试难度，不如保留在同一笔记本中更直观。
• 小型任务场景：如果整个笔记本代码量不大，只是多了几个简单函数，拆分反而会让简单问题复杂化，完全没有必要。

内容的提问来源于stack exchange，提问作者Enrique Benito Casado