代码锁：极简主义下的单例模式与模块化设计实践

1. 项目概述一个极简主义者的代码锁最近在GitHub上看到一个挺有意思的项目叫cdotlock/the_only。光看这个名字你可能有点摸不着头脑cdotlock是什么the_only又是什么意思这其实是一个典型的极简主义开发者思维下的产物。简单来说它不是一个功能庞大的应用而是一个高度聚焦、解决单一核心问题的“代码锁”或“代码片段管理器”。想象一下这个场景你正在开发一个项目里面有一段核心的、绝对不能出错的配置代码或者是一个需要严格保密的API密钥初始化逻辑。你希望这段代码在项目中是“唯一”且“受保护”的不能被随意修改、覆盖甚至希望它的存在形式本身就带有一种“锁”的意味提醒其他协作者“此处重要小心触碰”。cdotlock/the_only就是为了满足这种心理和工程需求而生的。它通过一种非常轻量级、近乎于约定大于配置的方式来标记和管理你项目中那些“独一无二”的代码块。这个项目适合所有对代码结构整洁、意图明确有追求的开发者尤其是那些在团队协作中苦于如何优雅地保护核心逻辑、避免误操作的工程师。它不引入复杂的依赖不改变你的构建流程仅仅是通过一个文件命名约定和简单的访问模式来达成一种“软性”的代码契约。2. 核心设计哲学与实现思路拆解2.1 “唯一性”与“锁”的概念落地cdotlock/the_only的核心思想是将“唯一”和“锁定”这两个抽象概念通过工程实践具象化。在软件工程中“唯一”通常意味着“单例”Singleton模式而“锁定”则涉及到访问控制和状态保护。但这个项目的巧妙之处在于它并没有强制你使用传统的、可能略显笨重的设计模式来实现单例也没有引入复杂的权限系统。它的实现思路极其轻巧文件即契约项目通常约定将需要被“锁定”为唯一的代码放置在一个特定命名规则的文件中例如TheOnlyConfig.js或TheOnlyDatabaseClient.ts。这个文件名本身就成为了一个强烈的信号“这是本项目中关于XXX的唯一实现”。导出即单例在该文件内部实现你的核心逻辑类、函数、配置对象并且仅导出一个实例。这个导出的实例天然就是整个应用范围内可访问的“唯一”实例。访问即锁定通过项目内部的导入规范例如禁止在其他地方实例化同类对象所有相关操作都必须从这个唯一文件导入实例实现了“软锁定”。任何开发者看到import dbClient from ‘/lib/the-only/database-client‘这样的语句都会意识到他们正在操作的是那个共享的、唯一的实例从而在心理上和代码审查层面形成一道屏障。这种设计的优势非常明显零开销、高可读性、强暗示性。它把维护“唯一性”的责任从复杂的运行时检查转移到了清晰的代码组织和团队约定上。它更像是一种开发纪律的辅助工具而不是一个重量级的框架。2.2 技术选型与项目结构考量作为一个理念先行的项目cdotlock/the_only本身的技术栈可以是无侵入的。它最初可能源于某个特定生态如Node.js/JavaScript下的实践但其模式可以平移到任何语言。以常见的Node.js项目为例一个典型的应用结构可能如下src/ ├── app/ ├── components/ └── lib/ # 核心工具与唯一实例存放处 ├── the-only/ # 集中管理所有“唯一”实体 │ ├── config.js # 唯一配置中心 │ ├── redis-client.js # 唯一的Redis连接客户端 │ ├── database.js # 唯一的数据库连接池 │ └── event-bus.js # 唯一的事件总线 └── utils/ # 普通工具函数在lib/the-only/目录下的每个文件都遵循“一个文件一个默认导出实例”的原则。例如config.js// src/lib/the-only/config.js import dotenv from ‘dotenv‘; import path from ‘path‘; dotenv.config({ path: path.resolve(process.cwd(), ‘.env.production‘) }); class AppConfig { constructor() { this.nodeEnv process.env.NODE_ENV || ‘development‘; this.apiPort parseInt(process.env.API_PORT, 10) || 3000; this.databaseUrl process.env.DATABASE_URL; this.jwtSecret process.env.JWT_SECRET; // 冻结对象防止运行时意外修改硬锁定增强 Object.freeze(this); } } // 关键创建并导出唯一实例 const configInstance new AppConfig(); export default configInstance;这样在整个应用的任何地方当你需要配置时都这样做import appConfig from ‘/lib/the-only/config‘; console.log(Server running in ${appConfig.nodeEnv} mode on port ${appConfig.apiPort});你永远无法也不应该在其他地方new AppConfig()。这种模式强制了配置来源的唯一性和一致性彻底避免了配置散落各处、不同步的问题。注意Object.freeze()在这里是一个可选的“硬锁定”增强。它能在运行时防止对象属性被意外更改但对于嵌套对象是浅冻结。对于深度冻结需要额外工具或更严谨的设计。这体现了“锁”的不同强度选择。3. 核心细节解析与实操要点3.1 如何定义“The Only”实体不是所有东西都适合放进the-only目录。滥用会破坏其语义让“唯一”变得廉价。通常符合以下特征的实体是优秀候选全局状态管理者应用配置、主题设置、国际化语言包、全局状态存储如Redux store、Vuex store的实例。外部服务连接器数据库连接池、Redis客户端、消息队列生产者/消费者、第三方API SDK的认证客户端。这些资源通常是昂贵的创建多个实例会导致连接数耗尽或资源浪费。核心事件枢纽全局事件总线Event Emitter。多个事件总线会导致消息混乱一个唯一的总线是清晰通信的基础。关键工厂或管理器日志记录器工厂确保日志格式和输出目标统一、任务调度器、连接池管理器。判断一个实体是否应为“The Only”的一个简单方法是如果它在整个应用生命周期内逻辑上只应该存在一个或者存在多个会导致严重问题如数据不一致、资源冲突那么它就适合。3.2 实现模式详解从基础到增强基础的“导出实例”模式很简单但在实际生产中我们需要考虑更多边界情况。模式一即时实例化最基础如上文的config.js在模块加载时立即创建实例。适用于初始化成本低、无异步依赖的场景。模式二延迟初始化Lazy Initialization对于初始化耗时、或依赖异步资源如数据库连接的实体我们需要延迟实例化直到第一次被请求时。// src/lib/the-only/database.js import { Sequelize } from ‘sequelize‘; class Database { constructor() { this._client null; // 初始化为null } async getClient() { if (!this._client) { // 第一次访问时才创建连接 this._client new Sequelize(process.env.DATABASE_URL, { logging: console.log, pool: { max: 5, min: 0, acquire: 30000, idle: 10000 } }); try { await this._client.authenticate(); console.log(‘Database connection established.‘); } catch (error) { console.error(‘Unable to connect to the database:‘, error); this._client null; // 连接失败重置 throw error; } } return this._client; } async close() { if (this._client) { await this._client.close(); this._client null; } } } // 导出的是类的一个实例但连接是懒加载的 const databaseInstance new Database(); export default databaseInstance;使用时import db from ‘/lib/the-only/database‘; async function getUser(id) { const client await db.getClient(); // 首次调用会触发连接建立 return client.models.User.findByPk(id); }模式三带生命周期的管理对于需要优雅关闭的资源如数据库连接、消息队列连接单一的实例导出还不够需要提供生命周期方法。// 在 database.js 基础上增加一个应用关闭钩子 // ... Database类定义 ... const databaseInstance new Database(); // 提供一个优雅关闭的钩子方便在应用退出时调用 export const gracefulShutdown async () { await databaseInstance.close(); }; export default databaseInstance;然后在你的应用主文件如server.js中监听退出信号import db, { gracefulShutdown } from ‘/lib/the-only/database‘; process.on(‘SIGTERM‘, async () { console.log(‘SIGTERM received, starting graceful shutdown...‘); await gracefulShutdown(); process.exit(0); });这种模式确保了唯一实例不仅能被安全地访问还能被安全地销毁管理了完整的生命周期。3.3 在TypeScript中的强化实践TypeScript能为“The Only”模式提供强大的类型安全支持使其意图更加明确并防止误用。// src/lib/the-only/config.ts interface AppConfig { readonly nodeEnv: ‘development‘ | ‘production‘ | ‘test‘; readonly apiPort: number; readonly databaseUrl: string; readonly jwtSecret: string; } class AppConfigImpl implements AppConfig { public readonly nodeEnv: AppConfig[‘nodeEnv‘]; public readonly apiPort: number; public readonly databaseUrl: string; public readonly jwtSecret: string; constructor() { this.nodeEnv (process.env.NODE_ENV as any) || ‘development‘; this.apiPort parseInt(process.env.API_PORT || ‘3000‘, 10); this.databaseUrl process.env.DATABASE_URL || ‘’; this.jwtSecret process.env.JWT_SECRET || ‘’; // 类型系统 编译时检查比 Object.freeze 更早发现问题 if (!this.databaseUrl) { throw new Error(‘DATABASE_URL is required‘); } } } // 使用 as const 断言和 Readonly 类型双重保障 const configInstance: ReadonlyAppConfig new AppConfigImpl(); export default configInstance;通过readonly修饰符和ReadonlyT类型你在编译阶段就无法对导出的实例属性进行赋值这比运行时的Object.freeze反馈更及时。同时清晰的接口定义AppConfig让所有使用者都知道这个唯一实例的“形状”是什么。4. 实操过程与核心环节实现4.1 在现有项目中引入“The Only”模式假设你有一个正在发展的Express.js后端项目配置管理和数据库连接有些散乱你决定引入the-only模式进行重构。步骤1创建结构与首个“唯一”实体首先在项目核心代码目录如src下创建lib/the-only目录。 创建第一个文件config.ts将散落在各处如直接使用process.env或从不同文件加载的配置逻辑集中到此。步骤2重构配置访问点全局搜索项目中直接使用process.env.XXX的地方。这不是要完全消除process.env的使用因为测试环境可能需要mock而是要将业务配置的读取集中化。 将const port process.env.PORT || 3000;替换为import appConfig from ‘/lib/the-only/config‘; const port appConfig.apiPort;这个过程可以逐步进行优先处理核心、共享的配置项。步骤3实现数据库唯一客户端创建database.ts。将原来可能在各处独立创建的数据库连接池逻辑移入并实现为懒加载单例。 检查所有模型文件或数据访问层DAO确保它们都是从‘/lib/the-only/database‘导入客户端而不是自己创建新连接。步骤4建立团队约定并更新文档在项目的README.md或架构决策记录ADR中添加一个新部分## “The Only” 模式约定 - 目的确保关键资源配置、外部连接、全局状态在应用中的唯一性避免资源浪费和数据不一致。 - 位置所有“唯一”实体置于 src/lib/the-only/ 目录下。 - 规则 1. 每个文件默认导出一个已初始化的实例或提供获取实例的方法。 2. 禁止在项目其他任何地方创建同类实体的新实例。 3. 如需扩展功能应修改源文件或通过装饰、组合模式进行。 - 示例参见 src/lib/the-only/config.ts 和 database.ts。同时在代码评审Code Review中将“是否违反The Only约定”作为一项检查点。4.2 测试策略如何测试“唯一”实体测试“The Only”实体有其特殊性因为它们通常是全局的、有状态的。关键在于隔离。1. 单元测试依赖注入与模拟即使它是单例在测试其自身逻辑时也应尽量使其可测试。对于依赖了其他“唯一”实体的类在测试时可以通过依赖注入尽管导出的是实例或使用Jest等工具的模块模拟module mocking功能。例如测试一个依赖全局配置的服务// user.service.ts import appConfig from ‘/lib/the-only/config‘; export class UserService { getDefaultRole() { // 根据配置返回默认角色 return appConfig.nodeEnv ‘production‘ ? ‘viewer‘ : ‘admin‘; } }对应的测试文件// user.service.spec.ts import { UserService } from ‘./user.service‘; // 使用Jest模拟整个模块 jest.mock(‘/lib/the-only/config‘); import appConfig from ‘/lib/the-only/config‘; describe(‘UserService‘, () { beforeEach(() { jest.clearAllMocks(); }); it(‘should return “viewer” in production‘, () { // 模拟配置实例的行为 (appConfig as any).nodeEnv ‘production‘; const service new UserService(); expect(service.getDefaultRole()).toBe(‘viewer‘); }); it(‘should return “admin” in non-production‘, () { (appConfig as any).nodeEnv ‘development‘; const service new UserService(); expect(service.getDefaultRole()).toBe(‘admin‘); }); });2. 集成测试重置状态对于测试数据库唯一客户端这类有真实外部依赖的需要在测试套件开始前建立连接在每个测试用例后清理数据而非断开连接在所有测试结束后优雅关闭连接。// database.integration.spec.ts import db from ‘/lib/the-only/database‘; describe(‘Database Integration‘, () { beforeAll(async () { // 确保连接已建立 await db.getClient(); }); afterEach(async () { // 清理测试数据保持数据库干净 const client await db.getClient(); await client.query(‘TRUNCATE TABLE test_users CASCADE;‘); }); afterAll(async () { // 所有测试结束后关闭连接 await db.close(); }); it(‘should connect to database successfully‘, async () { const client await db.getClient(); const result await client.query(‘SELECT 11 as sum‘); expect(result.rows[0].sum).toBe(2); }); });3. 契约测试确保“唯一性”可以写一个简单的测试来验证某个类在整个导入范围内确实只存在一个实例。这更像是一个架构守护测试。// uniqueness.spec.ts (可放在e2e或架构测试目录) import configInstance1 from ‘/lib/the-only/config‘; import configInstance2 from ‘/lib/the-only/config‘; import * as configModule from ‘/lib/the-only/config‘; describe(‘The Only Contract‘, () { it(‘config should be the same instance across imports‘, () { // 验证两次导入的是同一个对象 expect(configInstance1).toBe(configInstance2); // 验证默认导出和模块的默认导出是同一个引用 expect(configInstance1).toBe(configModule.default); }); });4.3 与依赖注入DI容器的协同你可能会问在现代框架如NestJS、Angular中已经有了强大的依赖注入容器来管理单例还需要the-only模式吗答案是模式可以融合思想可以借鉴。在DI容器中“单例”是托管在容器中的。the-only模式可以视为一种在纯模块化无DI容器环境下的轻量级DI实践。即使在使用DI容器的项目中the-only的思想依然有价值目录结构即文档你仍然可以创建一个the-only目录里面存放那些被设计为单例的服务的实现类。然后在模块的providers数组中使用useClass并提供这个类同时设置scope: Scope.DEFAULT在NestJS中默认就是单例。// src/lib/the-only/event-bus.ts export class EventBus { /* ... */ } // src/app.module.ts import { EventBus } from ‘./lib/the-only/event-bus‘; Module({ providers: [ { provide: EventBus, useClass: EventBus, // 默认就是单例无需额外配置 }, ], }) export class AppModule {}这样the-only目录清晰地标明了这些类的设计意图而DI容器负责其生命周期管理。配置对象的特殊处理对于纯配置对象有时不适合用类来表示。你仍然可以沿用the-only模式导出一个冻结的配置对象然后在DI容器中将其作为一个Value Provider注入。// src/lib/the-only/config.ts const appConfig Object.freeze({ /* ... */ }); export default appConfig; // src/app.module.ts import appConfig from ‘./lib/the-only/config‘; Module({ providers: [ { provide: ‘APP_CONFIG‘, useValue: appConfig, // 直接注入这个唯一实例 }, ], })关键在于the-only是一种设计意图的声明而DI容器是实现和管理这种意图的工具之一。两者并不冲突而是可以从代码组织层面到运行时层面形成互补。5. 常见问题与排查技巧实录在实际引入和应用the-only模式的过程中你肯定会遇到一些典型问题和困惑。下面是我在实践中总结的一些坑和解决思路。5.1 循环依赖Circular Dependency陷阱这是模块化系统中使用单例或集中式管理时最常见的问题。例如你的Logger唯一实例需要在初始化时读取Config而Config在加载过程中可能需要记录一些日志到Logger这就形成了死循环。问题表象应用启动失败错误信息可能指向某个导入的模块为undefined或者栈溢出。解决方案解耦初始化逻辑确保模块的“实例化”和“初始化”分离。Config可以立即实例化并导出因为它只读取环境变量。Logger也可以立即实例化但它的内部组件如文件写入器、网络发送器的配置可以延迟到第一次使用前通过调用一个init(config)方法来设置。// logger.ts class Logger { private transport: Transport | null null; init(config: AppConfig) { this.transport new FileTransport(config.logPath); } log(message: string) { if (!this.transport) { throw new Error(‘Logger not initialized. Call init(config) first.‘); } this.transport.write(message); } } export const loggerInstance new Logger(); // 在主应用启动文件中 import config from ‘./config‘; import { loggerInstance } from ‘./logger‘; loggerInstance.init(config); // 手动初始化打破循环依赖注入如果架构允许考虑引入一个简单的依赖注入机制或使用工厂模式。Logger不直接导入Config而是在创建时由外部传入配置。使用设置函数而非导入对于简单的配置Logger可以提供一个setConfig函数而不是在模块层面导入Config。排查技巧遇到启动时的undefined错误首先检查模块导入图。可以使用工具如madge(npx madge --circular src/) 来可视化并找出项目中的循环依赖。the-only目录下的模块是循环依赖的高发区需要精心设计。5.2 热重载Hot Module Replacement, HMR下的状态丢失在开发环境尤其是前端项目使用Webpack HMR或Vite时模块可能会被重新执行。如果你的唯一实例内部维护了运行时状态如缓存、连接池状态热重载会导致这个状态丢失而其他未被重载的模块可能还在引用旧的实例造成不一致。问题表象开发时修改并保存一个the-only模块的文件后应用行为异常例如缓存失效、连接中断、事件监听丢失。解决方案状态外置将易变的运行时状态与“唯一”的实例定义分离。实例只提供方法和一个指向外部状态的引用。状态可以存放在模块外的变量、闭包中或者更推荐的是存放在专门的状态管理容器即使是简单的WeakMap里。// event-bus.ts const _listenersMap new WeakMapEventBus, Mapstring, Function[](); class EventBus { constructor() { _listenersMap.set(this, new Map()); } on(event: string, fn: Function) { const listeners _listenersMap.get(this)!; if (!listeners.has(event)) listeners.set(event, []); listeners.get(event)!.push(fn); } // ... emit 等方法 } export default new EventBus();这样即使模块重新执行新的EventBus实例被创建但由于_listenersMap是模块级变量它依然存在只是与新实例的关联需要重建通过构造函数。这比状态完全丢失要好但问题依然存在。更好的办法是…拥抱HMR API如果你的构建工具支持如Vite可以为这些有状态的单例模块编写HMR接受逻辑。// database-client.ts const state { connection: null as Connection | null, // 其他状态... }; class DatabaseClient { /* 使用 state.connection */ } const instance new DatabaseClient(); // Vite HMR 接受 if (import.meta.hot) { import.meta.hot.accept((newModule) { // 可以尝试将旧实例的状态迁移到新实例 console.log(‘DatabaseClient module updated, state may be lost.‘); }); } export default instance;开发与生产差异化最简单直接的办法是在开发环境接受状态丢失并做好快速重建的准备例如提供一键重连的调试按钮。或者对于关键状态在开发时将其持久化到localStorage或开发服务器的内存中。排查技巧在开发环境如果遇到修改代码后功能异常首先怀疑HMR导致的状态不一致。尝试完全刷新页面而非热更新看问题是否消失。在代码中添加简单的日志记录实例的创建和销毁时间可以帮助确认。5.3 类型定义与动态扩展的冲突在TypeScript项目中我们导出的唯一实例通常有一个明确的类型。但有时我们可能希望在某些特定条件下如插件系统、动态加载模块为这个实例动态添加方法或属性。问题表象TypeScript编译报错提示“属性 ‘xxx‘ 在类型 ‘X‘ 上不存在”。解决方案声明合并Declaration Merging如果扩展是发生在同一源码控制下的、有计划的扩展可以使用TypeScript的声明合并。为原类创建一个同名的接口声明并在其中添加新的方法/属性。// original-event-bus.ts export class EventBus { on(event: string, handler: Function) { /* ... */ } emit(event: string, data: any) { /* ... */ } } export default new EventBus(); // extended-features.d.ts (或在一个后续的.ts文件中) import { EventBus } from ‘./original-event-bus‘; // 声明合并 declare module ‘./original-event-bus‘ { interface EventBus { // 添加一个新方法 off(event: string, handler: Function): void; // 添加一个新属性 maxListeners: number; } } // 实际实现扩展需要保证在实例上添加 import eventBus from ‘./original-event-bus‘; (eventBus as any).off function(event, handler) { /* ... */ }; (eventBus as any).maxListeners 10;这种方式类型安全但扩展逻辑分散且需要确保扩展代码在实例使用前执行。适配器模式Adapter Pattern更清洁的做法是不直接扩展原实例而是创建一个新的“增强型”包装器。import originalEventBus, { EventBus as OriginalEventBus } from ‘./original-event-bus‘; interface EnhancedEventBus extends OriginalEventBus { off(event: string, handler: Function): void; maxListeners: number; } const enhancedEventBus: EnhancedEventBus { ...originalEventBus, off(event, handler) { /* 实现 */ }, maxListeners: 10, }; // 在插件或特定模块中使用 enhancedEventBus export default enhancedEventBus;这样不会污染原始的唯一实例并且类型清晰。接受类型断言如果动态扩展是临时的、或范围很小的直接使用类型断言(instance as any).newMethod ...是最快的方式但牺牲了类型安全需谨慎使用并添加详细注释。排查技巧当遇到动态扩展的类型错误时先问“这个扩展是否真的必须直接挂在核心唯一实例上” 很多时候通过组合、包装或依赖注入来引入新功能是更清晰、更可维护的选择。5.4 多线程/Worker环境下的挑战在Node.js的Cluster模式或Worker Threads中每个进程/线程有自己独立的内存空间。通过模块导出的“唯一”实例在每个Worker中都是独立的副本并不是真正跨进程/线程的“唯一”。这可能导致数据库连接数翻倍、内存缓存不一致等问题。问题表象使用Cluster或Worker Threads后数据库连接数达到预期值的数倍或者缓存命中率异常。解决方案区分进程内唯一与跨进程唯一首先要明确the-only模式保证的是“在同一Node.js进程内唯一”。对于需要跨进程共享的状态或连接必须使用外部服务。连接池的外部化管理对于数据库、Redis等客户端库通常自己会维护一个进程内的连接池。在Cluster模式下每个Worker进程拥有独立的连接池是正常且合理的因为操作系统进程是隔离的。你需要确保的是数据库服务器端的最大连接数配置足以支撑(Worker数量) * (每个Worker的连接池最大大小)。如果连接数成为瓶颈可以考虑减少每个Worker的连接池大小或者使用像PgBouncer这样的连接池管理器。共享状态的转移对于需要跨Worker共享的业务状态如全局计数器、会话缓存the-only模式下的内存对象不再适用。必须将其转移到真正的共享存储中内存存储使用像Redis或Memcached这样的外部内存数据库。消息总线使用像RabbitMQ、Kafka或Redis Pub/Sub进行跨进程通信。专用共享库在Node.js中可以通过SharedArrayBuffer和AtomicsAPI在主线程和Worker线程间共享少量二进制数据但这非常底层且复杂不适用于一般业务状态。实践建议在设计the-only实体时就要考虑其适用范围。对于纯进程内、无状态或状态可重建的服务如配置、工具函数库可以放心使用。对于有状态且状态需要跨进程共享的服务其“唯一”实例应该是一个访问外部共享资源的代理。例如一个GlobalCache的唯一实例其内部实现是去读写Redis那么它在每个Worker中虽然是不同的JavaScript对象但背后操作的是同一个Redis从而在逻辑上实现了“全局唯一”。// global-cache.ts - 每个Worker有自己的实例但都指向同一个Redis import Redis from ‘ioredis‘; class GlobalCache { private client: Redis; constructor() { // 每个Worker都会创建自己的Redis连接但连接到同一个服务器 this.client new Redis(process.env.REDIS_URL); } async set(key: string, value: any) { await this.client.set(key, JSON.stringify(value)); } async get(key: string): Promiseany { const data await this.client.get(key); return data ? JSON.parse(data) : null; } } // 在每个Worker内部它是唯一的。但从整个应用看状态在Redis中共享。 export default new GlobalCache();引入the-only模式本质上是在代码架构层面引入了一种强约束和清晰约定。它带来的最大好处是“心智模型的一致性”和“代码组织的清晰度”。初期可能会遇到一些适应性问题比如觉得“多导入一个文件麻烦”或者需要改变原有的即时创建对象的习惯。但一旦团队适应它能显著减少因重复实例化导致的bug让代码的依赖关系变得更加明确。我个人的体会是它特别适合在中小型项目或大型项目中的独立模块内率先推行作为一种低成本的架构治理手段。当你看到代码库中散乱的new DatabaseClient()被统一的import db from ‘/lib/the-only/database‘替代时那种整洁和有序感本身就是对代码质量的一次显著提升。