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