疯了，简直是疯了！
上周在 CodePaaS 项目做代码重构，统计工具一跑出来，整个团队都沉默了：8个模块，30+冗余类，2000+行重复代码。
更可怕的是什么？每个模块都有自己的注册方式。
打开代码库，随便翻几个模块。表单注册用 FormService.getInstance().register()，事件注册用 EventManager.register()，路由注册用 RouteRegistry.add()，数据库注册用
DatabaseManager.registerDataSource()。
统计下来，整个平台有 23种注册类型，但每种都有不同的API。每次新增一种注册类型，都要重新学习一套API。代码重复率高达30%，维护成本爆炸。
我就在想，当注册方式不统一时，代码会变成什么样子？
就像一个房子里有23个不同的入口，每个入口都有自己的钥匙，但没人记得哪把钥匙开哪扇门。
话又说回来，这个问题是怎么出现的呢？
最早的时候，平台只有表单和事件两个注册类型，大家觉得没啥问题。后来加上了路由、图标、数据源，每个开发都按自己的习惯写，还没觉得有什么不妥。
等到项目做了半年，注册类型增加到23种，问题就爆发了。
有一次要卸载一个应用，我数了数，需要调用23个不同的清理方法。FormService.getInstance().unregisterApp(appId)、
EventManager.unregisterApp(appId)、RouteRegistry.removeApp(appId)……漏掉一个，就会造成内存泄漏。
那天晚上，我跟团队说，必须得重构了。
我们提了4个核心目标。
第一，统一注册接口。所有类型的注册，都用同一套API。不管注册表单还是事件，调用方式完全一样。
第二，类型安全。编译时就能检查类型，避免运行时才发现错误。
第三，应用隔离。SOFA ARK 环境下，每个子应用独立注册，互不干扰。
第四，生命周期管理。应用卸载时，一行代码就能批量注销所有对象。
这4个目标，就是统一注册框架的设计灵魂。
核心思路其实很简单：泛型保证类型安全，枚举限制注册类型。
我们先定义了一个统一接口：
public interface UnifiedRegistry {
void register(String appId, K key, T value);
void unregister(K key);
void unregisterByApp(String appId);
T get(K key);
Map getByApp(String appId);
} 是注册对象的类型，比如 FormHandle、EventHandler。 是键的类型，比如 String。appId 用于应用隔离。
然后用枚举定义所有注册类型：
public enum RegistryType {
FORM("form", "表单"),
DATAWINDOW("datawindow", "数据视图"),
EVENT("event", "事件"),
ROUTE("route", "路由"),
DATABASE("database", "数据库"),
// ... 共23种
}这样，新增一种注册类型，只需要加一行枚举值，其他全是自动的。
最有意思的是类型安全设计。
以前没有泛型约束，什么类型都能注册，什么类型都能获取。编译时没问题，运行时才发现类型错误。
// 编译错误：String 不能转换为 FormHandle
RegistryManager.getInstance().register(
RegistryType.FORM, "myapp", "USER_FORM", "not a FormHandle"
);现在通过泛型约束，让编译器成为你的代码审查员。大部分错误在编译时就能发现，而不是等到运行时才崩溃。
这意味着什么？
意味着你可以自信地重构代码，不用担心改错地方。意味着新人上手更容易，不需要记住23种不同的API。意味着代码更简洁，可读性提升了3倍。
在 SOFA ARK 环境下，基座和子应用之间如何共享注册表？这是个关键问题。
我们用了 static 的 ConcurrentHashMap，这样在 JVM 中只有一份，基座和所有子应用都能访问。
每个注册表都有双重存储结构。应用级存储按 appId 分组，全局级存储是全局唯一索引。注册时同时写入两个存储，这样既能全局查询，又能应用级隔离。
// 卸载 appmanage 应用
RegistryManager.getInstance().unregisterAppFromAllRegistries("appmanage");
// 结果：
// 1. byApp 中的 "appmanage" 目录被删除
// 2. global 中属于 "appmanage" 的对象被删除
// 3. scheduled_tasks 的对象不受影响这就是应用隔离的魔力。
统一注册框架上线后，重构成果挺明显的。
冗余类从30+降到0，重复代码从2000+行降到0，注册方式从23种API统一到1种。类型安全从无到有，应用隔离从无到完整支持。
以前代码是这样的：
FormService.getInstance().register(formName, formHandle);
EventManager.register(eventClass, eventHandler);
RouteRegistry.add(routeConfig);
DatabaseManager.registerDataSource(appId, dataSource);现在变成了这样：
RegistryManager.getInstance().register(RegistryType.FORM, appId, formName, formHandle);
RegistryManager.getInstance().register(RegistryType.EVENT, appId, eventName, eventHandler);
RegistryManager.getInstance().register(RegistryType.ROUTE, appId, routeName, routeConfig);
RegistryManager.getInstance().register(RegistryType.DATABASE, appId, dbName, dataSource);代码量减少了一半，可读性提升了3倍。
基于实战经验，我总结了3个最佳实践。
第一，优先使用便捷方法。直接调用
RegistryManager.getInstance().register()，不要先获取注册表再注册。
第二，应用卸载记得清理。一定要调用
unregisterAppFromAllRegistries()，否则会造成内存泄漏。
第三，默认应用要设置。当某个注册类型有多个应用实现时，用 setDefaultApp() 指定默认使用的应用。
从8个模块30+冗余类，到统一注册框架，我们学到了什么？
统一接口是基础，所有注册类型用同一套API。类型安全是保障，泛型+枚举，编译时检查。应用隔离是关键，SOFA ARK 环境下的设计重点。生命周期管理是核心，应用卸载时批量清理。
好的设计，让代码会说话。
现在回头看，如果一开始就采用统一设计，就不会有那2000行重复代码了。不过话说回来，正是这些坑，让我们明白了设计的重要性。
下一篇文章，我们聊聊 23种注册类型的应用场景，每种类型什么时候用、怎么用、有什么坑。敬请期待。