项目由他人接手
负责人已经变更，文档不完整，实际依赖关系也不清晰。
20–40h典型首次评估
先完成构建先看证据，再谈承诺
NDA访问保密资料之前
亲自实施可进行修复
何时从这里开始
项目还在，信心却不在。
需要决定下一步修复或开发什么，却尚未可靠了解项目状况时，检查会有所帮助。
构建脆弱
它在一台机器上可运行，却在 CI 中失败，或依赖未记录的本地配置和手动步骤。
性能问题阻碍发布
帧耗时、内存、加载、崩溃或特定设备行为，都需要以证据为依据进行诊断。
集成反复失效
准备更新时，与服务器服务、第三方工具、手机功能、Steam 或 VR 设备的连接反复出问题。
改动的影响难以预测
紧密耦合的系统使小修复也代价高昂，且容易引发回归。
路线图建立在猜测之上
扩大投入之前，团队需要有充分依据地决定完成、重构还是重建。
具体交付物
了解哪些部分运作正常，决定哪些需要修复。
评估围绕产品所有者需要决定什么，以及工程团队下一步需要执行什么展开。
- 01
哪些部分可用，什么阻碍了项目运行
构建状态、环境说明和清晰记录的阻碍。
- 02
架构图
核心系统、依赖项、责任边界与关键耦合关系。
- 03
按优先级排序的风险清单
按影响、发生可能性和交付紧迫性排列评估发现。
- 04
性能与集成评估发现
来自相应平台、设备或头显的实测证据。
- 05
技术方向
有依据地建议完成、重构或重建，而不是下意识地重写。
- 06
分成清楚阶段的修复计划
里程碑、验收标准、依赖项，以及有用的后续决策。
检查重点是我们约定的最重要问题。20–40 小时无法找出大型现有项目中的每一个问题，因此报告也会说明检查了什么，以及哪些仍不确定。
评估如何开展
投入修复前，先了解需要做的工作。
- 01
简述与访问权限
明确产品、目标平台、当前阻碍和成功标准。必要时，在访问代码仓库之前签署 NDA。
- 02
检查项目能否运行
先运行项目、复现问题，并记录实际构建路径，再作出交付承诺。
- 03
检查与测量
在相应目标环境中追踪架构、依赖项、数据流、集成和性能。
- 04
决策与排序
根据检查结果，建议先修复什么，解释可选方案，并提出范围适当的第一项工作。
核心决策
完成、重构还是重建？
答案应依据产品约束和证据，而不是偏好、恐慌或沉没成本。
完成01
保留可运行的核心。
当架构仍可使用时，将精力集中于阻碍、验证和发布关键缺口。
重构02
改进造成问题的部分。
当特定模块产生风险时，隔离并修复它们，避免破坏整个产品的稳定性。
重建03
仅在证据支持时采用。
只有当前结构无法满足产品所需结果时，重写才有充分依据。
相关证据
支撑评估的交付经验。
架构决策建立在亲自交付已发布 PCVR、生产级移动软件和复杂系统游戏的实践之上。
已发布 Steam PCVR
Reach The Beat
唯一 Unity 工程师和技术负责人，负责架构、玩法与 XR 系统、工具、构建、硬件验证和发布。
查看 Steam 发布证据生产级 Android / iOS
保密移动产品
唯一的 Unity 客户端工程师和移动架构师，负责复杂 UI、依赖后端的流程、设备验证和原生集成。
产品身份不公开 · 遵守 NDA
多系统游戏
相互关联的产品系统
涵盖成长、存档、本地化、分析和数据驱动内容系统的架构与实现。
5 年以上商业 Unity 开发经验 · Upwork 公开评分 5.0
访问前的问题
清晰的第一步。
01你能接手现有或已放弃的 Unity 项目吗？
可以。我先检查项目能否运行、查看代码，并确定哪些部分可以修复或复用。在估算较大的开发工作前，先建议第一步。
02你需要哪些访问权限？
评估本身通常需要代码仓库、Unity 版本、代表性构建、现有文档，以及目标平台访问或硬件环境信息。可以先从概述开始。在分享敏感细节或授予仓库访问权限前，可以先签署 NDA。
03评估会告诉我们应该完成、重构还是重建吗？
这是它的主要目的之一。建议基于证据、产品约束、交付风险和成功定义，而不是一概偏好重写。
04审计后可以由你实施路线图吗？
可以。您的团队可以使用报告，也可以与我另行约定问题修复、部分代码改进、性能、服务连接或发布准备。接受检查并不要求您继续委托后续工作。
05首次合作规模有多大？
我们从付费检查开始。对于接手的项目或问题不明确的项目，20–40 小时可能合适。开始前，我们会约定工时、费用、主要问题和报告。您会收到可用部分或运行障碍的记录、最重要的风险，以及第一阶段修复建议。开发另行估算。
从阻碍入手
告诉我什么在反复出问题。
预算有限？告诉我最重要的问题和您能接受的预算范围，我会明确说明怎样的第一步切实可行。
从第一次交流起为您保密
我仅汇总统计联系操作，不收集访客标识符或消息内容。