这是一个创建于 420 天前的主题，其中的信息可能已经有所发展或是发生改变。
文档不全，代码看的懂，但是链路长，逻辑复杂，猜不出意图，这种大家有什么好的办法可以快速学习掌握吗
 |
1
PingAn66 2023-09-14 08:18:14 +08:00 via Android
不懂的多问问同事
|
 |
3
shortxxx 2023-09-14 08:39:16 +08:00
从业务逻辑出发 找产品聊 功能逻辑看测试
|
 |
4
linshuizhaoying 2023-09-14 08:42:43 +08:00
思维导图+架构梳理
|
 |
5
x86 2023-09-14 08:44:18 +08:00
|
 |
6
LowBi 2023-09-14 08:46:13 +08:00
debug 或者问 gpt
|
 |
7
zcf0508 2023-09-14 08:48:24 +08:00 via Android
通读代码
|
 |
8
darkengine 2023-09-14 08:51:29 +08:00  1
1 ，先在本地跑起来
2 ，在本地跑起来的代码上加日志，打断点折腾 没有捷径 |
 |
9
litchinn 2023-09-14 09:15:15 +08:00 11
作为一个新人，想迅速上手一个大型的老项目，是需要点运气的
1. 有一个优秀的领导(组长)这种角色，给你分派任务时从一些工作量不高但是能切入核心的工作开始，慢慢慢慢一个模块一个模块开始认识整个系统 2. 认真对待每次需求评审会，此时大家也是新接触功能，如果你是新人那么在评审会上你应该有很多名词不懂，记下来会后问一问，基本能搞清楚流程了 3. 看代码这东西真的很看运气，因为有时候项目的代码真的是屎山，写的人再看都不一定知道咋回事了。 4. 多去测试环境(或者其他非生产环境)的应用上点一点，看一看各个功能的用途，并尝试从接口找到对应代码(非 web 项目同理) |
 |
10
polo3584 2023-09-14 09:17:32 +08:00
先让自己本地跑起来，然后先摸清各个模块对应功能，具体到里面的细节得到改到对应的模块才会去细看。
|
 |
11
babyoung 2023-09-14 09:18:54 +08:00 via iPhone
应该是作为一个老人，如何快速上手新项目？
|
 |
12
wqhui 2023-09-14 09:24:19 +08:00
看函数名加注释能知道大概在做什么，具体细节等要改的时候再认真看吧，看了也记不住那么多，神仙命名无解
|
 |
13
my101du 2023-09-14 09:25:58 +08:00
本地 clone 一份，先跑起来。
然后添加一个 branch ，必要的地方加注释。 然后查看数据表的 Diagram 然后新建一个 markdown 文件和一个思维导图，分别记录重要的文件、代码和结构。 |
 |
14
hankai17 2023-09-14 09:26:32 +08:00
8L + 1
debug + 日志 |
 |
15
aptx4689 2023-09-14 09:26:36 +08:00
接新 feature 加功能
|
 |
16
vsitebon 2023-09-14 09:30:29 +08:00
你一个人接手的代码前提下：
1. 一般如果不是非常屎山的代码，看函数名能搞清楚这个函数是做什么的，最怕就是接手：gmCount() => 购买记录 2. 如果碰到上述的这种屎山代码，加断点然后看操作后会输入什么输出什么； 3. 如果加断点的时候碰到中间的数据出现，khdd 这种的话，估计你还得去看具体的值是什么，就怕出现一个莫名奇妙的 1 或者 ‘1’； 4. 如果以上的这些情况你都碰到了，那恭喜你，你将进入地狱级难度；接下来你如果没办法那么快实现功能，一定一定要提前跟经理说 |
 |
17
xiyou007 2023-09-14 09:33:20 +08:00 1
我一般是
1. 先了解项目背景 主要做什么用的 2. 主要功能操作步骤 3. 主要功能的接口，以及背后的数据表，表主要的字段 以及表关联关系，画图记笔记 4. 其他的话 就是接需求 边写边看 ；切记 接新的需求后 先出方案 跟老同志 请教一下； 写完 让老同志 review 一下代码 |
 |
18
shunwei 2023-09-14 09:37:34 +08:00
你做那一块, 就把这一块功能了解清楚, 慢慢的, 整个项目你就都清楚了
|
 |
19
chitanda 2023-09-14 09:37:54 +08:00
自己写个文本类的文档，看到哪写到哪，看一遍写一遍之后，丢给 ChatGPT 让它帮你画流程图
|
 |
20
yufeng0681 2023-09-14 10:14:23 +08:00
@xiyou007 思路清晰， 我补充一点，不要期望通过看代码了解项目，只有分派到你具体模块，具体 bug 修复，你才需要深入看某一部分的代码，最好还是 debug 跟踪调用的接口方式快速走读代码。
|
 |
21
placeholder 2023-09-14 10:58:32 +08:00
写笔记，真的要写笔记。光看代码是记不住的
|
 |
22
Hilong 2023-09-14 10:59:15 +08:00
只能一点点磨哦。我之前也是接了个老项目，3 个同事写了一年，让我来接手，前面一两周，真的找个功能在哪实现的都很困难，过了一两个月就好多了。基本熟悉了
|
 |
23
fredweili 2023-09-14 11:02:56 +08:00
从修简单 bug 入手，debug 走流程
|
 |
24
X90 2023-09-14 11:36:49 +08:00
8 楼+1 。看来大家的项目都没有像样的文档我就放心了。全靠传帮带交接。
|
|
25
darkengine 2023-09-14 11:57:38 +08:00
@X90 在某些项目里，有时候没文档还少走些弯路。。。
|
 |
26
yagamil 2023-09-14 12:06:21 +08:00
最近接手了一个私人的活，没有文档，没有注释，一个文件里面上万行代码，里面复制粘贴 也有不少，命名也是混乱。
主要负责后期的新增功能和修理 bug 。 1 周左右上手了。 主要代码不要动，新增的功能用已有的代码继续复制上去，根据新功能改动即可。 俗称继续堆屎山。 别考虑什么优雅，再优雅的代码，跑不起来，都是垃圾。 |
 |
27
murmur 2023-09-14 12:38:08 +08:00
不学。根本没时间。要的就是个快速改需求的能力
|
 |
28
enchilada2020 2023-09-14 12:48:34 +08:00 via Android
曾经有过同样的问题 现在已经弃疗了
|
 |
29
jones2000 2023-09-14 12:49:13 +08:00
根据前端业务，一块一块看。所有的代码基本都是围绕业务来做的。
|
 |
30
mohuani 2023-09-14 13:04:08 +08:00
@linshuizhaoying 这才是正确的方式，无论是开发，测试，还是产品。
|
 |
31
c3de3f21 2023-09-14 13:09:51 +08:00
了解了解业务，然后点一点按钮测一测数据，后台打端点，
可能是我项目经验少，主要看数据流向(因为可以看出调用过程嘛)和数据关联(连表或者 rpc 服务之类的) |
 |
32
HyperionX 2023-09-14 13:16:48 +08:00
后端业务的话，通过测试报告/技术文档/prd/产运记录的反馈整理正向&逆向业务流。代码本质上就是实现业务的手段，懂业务很快能懂代码为什么这么设计
|
|
33
X90 2023-09-14 13:29:09 +08:00
@darkengine 哈哈，本来一坨屎山就够难受了，再来一坨掺和着更难受
|
 |
35
c0nstantien 2023-09-14 15:28:29 +08:00
参与运营与一线排障
|
 |
36
coffeygao 2023-09-14 15:35:13 +08:00
简单点的项目 review 代码就行。
稍微复杂：直接运行起来，点一点，走一走业务，看看原型，设计，需求文档。 特别复杂：请教同事/项目主管运行起来项目代码，请教他们讲解业务逻辑，review 代码。 复杂像屎：跑路吧。 总结：尽量自己解决，鼻子底下就是嘴，不懂就多问。 |
 |
37
huihuiHK 2023-09-14 15:37:51 +08:00
边用边了解总结
|
 |
38
zdt3476 2023-09-14 15:54:39 +08:00
只看代码是很难记得住的，还是得有简单的工作入手
|
 |
39
overthemoon 2023-09-14 16:25:09 +08:00
该 bug 或者写新代码的时候熟悉
|
 |
40
Justin13 2023-09-14 18:20:25 +08:00 via Android
没有快速的办法，就靠时间慢慢熟悉
如果公司不给足够的时间，建议跑路 |
 |
41
vgbw 2023-09-14 19:00:25 +08:00
直接问同事，这种一般都是屎山
|
Select Language