Unity 开发高级/资深 02：工程规范与可维护性

返回总览

工程规范

• 目录规范：Scripts、Art、Prefabs、Scenes、UI、Audio、VFX、Configs、Editor、Tests 边界清晰。
• 命名规范：类名、接口、枚举、Prefab、材质、贴图、动画、配置表、资源 ID 保持一致。
• Assembly 规范：业务、框架、编辑器、测试、热更代码分别放在合适的程序集。
• 代码风格：缩进、括号、访问修饰符、字段前缀、事件命名、异步命名统一。
• 注释规范：解释意图、边界和风险，不重复描述显而易见的代码。
• 提交规范：一个提交只解决一个主题，提交信息能说明原因和影响。
• 分支规范：主干、开发、发布、热修、功能分支的合并规则清楚。
• 资源提交规范：大资源锁定、Meta 文件保留、Prefab 冲突处理、图集变更说明。

需要掌握的工具

• Git：分支、合并、rebase、cherry-pick、tag、submodule、大文件冲突处理。
• GitHub/GitLab/Bitbucket：代码评审、保护分支、CI 状态、合并策略。
• UnityYAMLMerge：处理 Unity Scene、Prefab、Asset 的文本合并冲突。
• EditorConfig、Rider Code Style、Roslyn Analyzer：统一代码风格和静态检查。
• StyleCop 或自定义 Analyzer：规范命名、注释、API 使用和风险写法。
• Jira、TAPD、禅道、飞书项目：任务、缺陷、版本和里程碑追踪。
• Confluence、Notion、飞书文档：沉淀模块说明、接入文档和排障手册。

可继续细分方向

• 代码规范与代码评审。
• 资源目录、命名和 Meta 文件规范。
• 技术债治理。
• 模块文档、接入文档和排障文档。

可维护性

• 模块职责：每个模块有负责人、入口、生命周期、依赖和对外接口。
• 错误处理：统一日志、错误码、用户提示、重试、降级和上报字段。
• 可测试性：核心逻辑尽量从 MonoBehaviour 中剥离，方便单元测试。
• 可替换性：平台 SDK、网络层、资源层、日志层应能通过接口替换实现。
• 可观测性：关键链路必须有日志、耗时、状态和失败原因。
• 可配置性：策划可改的数据进配置，程序硬编码只保留真正稳定的常量。
• 可回滚性：新功能应有开关，资源和配置应能退回旧版本。

Review 重点

• 生命周期是否正确，是否访问了已销毁对象。
• 异步回调是否考虑取消、超时、重复触发。
• 是否引入 GC、反射、频繁 Find、频繁 GetComponent。
• 是否存在跨模块强耦合、循环依赖、静态状态污染。
• 是否缺少失败处理、日志、错误码或用户提示。
• 是否影响包体、加载时长、内存、同屏性能。
• 是否破坏已有配置、资源路径、协议兼容。
• 是否有测试、调试入口或 QA 可验证方式。

技术债治理

• 给技术债分级：线上风险、迭代阻塞、性能隐患、可读性问题。
• 给技术债归属：明确负责人、影响范围、修复窗口和回归方式。
• 不把所有问题都塞进重构，优先修复会阻碍交付和稳定性的部分。
• 临时方案必须写清楚过期条件，例如版本号、活动结束时间或替代方案。
• 定期维护技术债清单，避免“大家都知道有问题”但没人真正负责。

文档要求

• 模块文档：职责、入口、生命周期、依赖、主要接口、常见问题。
• 接入文档：新功能如何接入、配置怎么填、资源怎么放、测试怎么跑。
• 排障文档：常见错误日志、定位步骤、相关工具、回滚方式。
• 发版文档：构建步骤、参数、渠道差异、检查项、产物位置。
• 复盘文档：事故时间线、影响范围、根因、修复、预防措施。