假设让你接手一个中小规模的软件项目，你该如何入手

[leiuu]

RT.

项目规模可能是之前一个 4-5 人左右的前后端团队开发，涉及前端、后端、数据等，框架有 10 余种。

例如最基本的，可能需要熟悉系统的人，提供部署图、目前的整体架构图、git 地址列表等。

除此之外，交接人提供什么样的图表或者资料，可以供快速熟悉系统？

对了时间不宜过长，一般是在一个月内。

感觉是个通用问题，请教大家了。

[bootvue]

不该跑路吗

[4ark]

这种时候就体现文档的重要性了

[westoy]

如果能跑， 就别去动它

[Cielsky]

文档详细：尽量不动原代码
文档不全 /没有：趁早跑路

[gotounix]

关键是工作内容，是新功能开发还是老功能维护。功能维护也分很多种情况，负责几个模块还是整个系统。

我觉得，最重要的还是熟悉业务。建设的比较完善的项目，可能你上面列的那些都有。但是很多情况下，可能只是给你个 git 地址，什么部署图、架构图可能都没有。而且，有可能文档（详设、概设、数据库设计）跟实际代码不一致，或者年久失修。

只要业务熟悉，碰到问题解决问题，很快就能熟悉代码。

[seakingii]

1 所有源码编译一次
2 在新的测试环境搭建一次所有的模块
3 所有的文档过一遍
4 所有的源代码看一遍(至少每个文件打开看看)

[janus77]

4-人 5 团队的东西让一个人去做，这什么通用问题啊

[pupboss]

这种事我干的多了，让交接给你的人，手把手带你从零搭建起来一套环境，只要能跑起来，以后一切好说

设计文档作用很小，没人老老实实照着规范写代码，后期 debug 主要靠自己一点一点熟悉

[leiuu]

@gotounix 同意熟悉业务是个很重要的角度，请教这个实践当中对应什么类型的文档比较好

[leiuu]

@seakingii 编译一次，部署一次！同意。

[leiuu]

@janus77 单人接手，后续不一定是单人开发。

[leiuu]

@pupboss 搭建蛮重要的 但可能只是一个辅助视角 必要的文档对理解系统会更有帮助
中小规模的系统 逐行读代码的效率会比较差一些 假设有多语言的话 读起来可能会更费劲
所以可能想着从规范文档的角度 来加速理解系统 以及方便系统传承

[liangkang1436]

让你一个人接手四五个人做的项目，是一个已经成熟的项目你只负责后期维护，还是只开发到一半让你接着开发？你的领导是不是告诉你，这是个机遇同时也是个挑战？哈哈哈哈

[liangkang1436]

涉及到的技术栈那么多，你一个人全部啃下来一个月估计够呛，我建议你扛两天之后就跟领导要人，如果实在要不到，就要点工资涨幅，如果这些都没有，让你硬扛，那你就得考虑跑路了

[leiuu]

@liangkang1436 哈哈哈 兄弟 你太坏了 我是负责人 只是想看看大家对类似很常见的场景下 如何做更加有效率 感觉传统的工作交接并不一定是最佳实践
所以想软件工程角度看看 从文档下手 能不能提高交接效率 为后期大家维护和参与开发遗留系统做好铺垫工作

[liangkang1436]

我之前待过的公司就干过这种事，不过当事人不是我，是我前同事，他硬扛了一个月，客户不停地发邮件催，他刚入职，不熟悉，确实搞不定，天天加班也搞不定，压力大到流眼泪，领导什么都不管，就让他自己这么扛，最后他跑路了，这种状况下，人是不会有成长的，还会打击你的信心，让你更加害怕困难和挑战

[liangkang1436]

@leiuu 哈哈哈，不好意思，那我分享的例子就不适合这个帖子了

[leiuu]

@liangkang1436
真实例子对分析也是有帮助的 ！
如果不是候选人本身能力问题的话
这个我感觉是前领导问题 新人上来接项目是不合适的 负责人起码前期做一些铺垫的 简单系统还好 如果新人面临业务不熟悉、技术栈有偏差的情况下 激进推进是不合适的

[jones2000]

首先看这个项目是否是公司重要的项目，是否是公司盈利项目， 如果是就硬抗了，文档， 代码，调试，业务逻辑都看， 不知道的问团队的人。 如果是无关紧要，或内部工具， 那就自己了。

[tedding]

vue2 迁移 到 angular 12 ， 没有文档 纯代码手工迁移 6 个周才搞定所有功能，包括所有 ts 类型