这是一个创建于 3258 天前的主题，其中的信息可能已经有所发展或是发生改变。
你们是怎么快速熟悉新项目（ 10 万行+）的代码的？
 |
1
kaedea 2015-12-23 17:23:27 +08:00
大改乱改
|
 |
2
pyengwoei OP 技术主管走人了，现在他的一个项目丢给我，让我来维护，看了几周了 感觉还是没有一点头绪，也没有一个技术文档，只是把业务大概给我说了一下。。。。现在老大要求我 需要熟悉每一行每一个量。。。。。
|
|
4
kaedea 2015-12-23 17:28:15 +08:00
把项目按业务或者功能分成小块，试着重构某些小块，很快就变成你是最熟悉的人了。
|
 |
5
wenmingvs 2015-12-23 17:31:16 +08:00
楼上的头像让人浮想联翩
|
|
7
kaedea 2015-12-23 18:01:32 +08:00  1
一年下来我把公司项目大大小小的模块都拆过了，最近更是把整个架构都改了。
这么做有个坏处就是，每天都会有一堆人跑来问你“那个谁，这里要怎么处理才好……” |
 |
8
naiyu 2015-12-23 18:30:34 +08:00
我是这样的，先熟悉业务，然后走一下流程，接着走到程序入口，然后一步步来看
|
 |
9
h1029306 2015-12-23 18:44:21 +08:00
先编译，再运行看看，然后加 log ，看 log 日志，哪里不会加哪里
|
 |
10
timothyye 2015-12-23 19:03:08 +08:00 via Android
一边看一边吐槽，然后就看懂了
|
 |
12
Felldeadbird 2015-12-23 21:24:13 +08:00 via iPhone
有需求自然慢慢懂的了
|
 |
13
sfree2005 2015-12-23 21:27:15 +08:00
1. 大概了解项目干什么的，知道最主要的几个 use case 是什么
2. 修改些小 bug 3. 增加些小功能 4. 修改大一些的 bug 5. 增加大功能 之后就基本上了解了~~ |
 |
14
Valyrian 2015-12-23 21:31:40 +08:00
主要靠 git grep
|
 |
15
loading 2015-12-23 21:33:41 +08:00 via Android
遇到有 bug 的地方就重构哪个地方。
|
 |
16
iMouseWu 2015-12-23 21:52:31 +08:00
一个人想一下子搞明白 10W 行代码。。。有点吃力呀。。。
可以先画流程图理清业务,debug 一些核心模块,接下来就是修 bug 熟悉流程 |
 |
17
decaywood 2015-12-23 22:38:58 +08:00 3
1 、 UML 工具、思维导图先备好。
2 、把包理一遍，尽量从包名获取足够的信息。 3 、找到入口函数，分析里面的类，如果有超类，先从超类分析。 4 、慢慢构建 UML 图和思维导图，不断回顾，总结。 5 、试着运行代码，断点调试。 6 、继承核心类，尝试修改逻辑。 大概差不多了 |
 |
18
Light3 2015-12-23 23:59:03 +08:00
不知道是什么语言。边改边吐槽这是真的。适当的记一下因为很多的时候看着看着就忘了。下次再找只是有模糊的印象。再其次没有文档自己慢慢把自己维护过的 总结下写一个。
|
 |
19
KentY 2015-12-24 05:33:16 +08:00
如果最熟悉的人走了, 那就很难了.
如果人家还在, 可以通过做小的 bugfixing and CR 开始. |
 |
20
hqs123 2015-12-24 08:06:53 +08:00
有哪个需求变动就改哪一块，其它简单看看就行，以不变应万变。
|
 |
21
l1905 2015-12-24 08:07:54 +08:00 via Android
写单元测试
|
 |
22
nellace 2015-12-24 08:29:27 +08:00
无他 唯改代码时候会去熟悉
|
 |
23
ichanne 2015-12-24 09:07:11 +08:00
我最近正在接收一个 23w 行代码的 iOS 项目。。。赶紧收藏帖子
|
 |
24
mko0okmko0 2015-12-24 09:30:00 +08:00
告诉老板功能太多吃不消.
问老板那些功能是想留下的. 然后直接做新的,旧的当参考. 我只能说,能接手别人没留下技术说明与注解的万行代码, 这种人我佩服,但绝对不想变这种人 |
 |
25
shakoon 2015-12-24 09:36:23 +08:00 1
如果是标准的 mvc 模式写的代码，那分功能模块一层一层看。
如果是乱成一团的，那就先自己把它分段，按照你熟悉的方式做“段落整理”，然后再去看具体的代码。 |
 |
26
moe3000 2015-12-24 09:38:31 +08:00
业务 走流程 边走边看代码 代码再联系数据表
|
 |
27
spacewander 2015-12-24 09:43:58 +08:00 via Android
改 bug 的时候渐渐就熟悉了
|
 |
28
zhuangzhuang1988 2015-12-24 09:50:21 +08:00
使用最强 IDE, visual studio 或者 jetbrains 家族.
然后下个断点, 调试 |
 |
29
thinkmore 2015-12-24 09:54:20 +08:00
一个模块一个模块来，然后自己整理画类图
|
 |
30
binjoo 2015-12-24 09:57:28 +08:00 1
直接丢给我一个项目让我熟悉是不可能的。。
除非丢给我 BUG ，让我去改，才能熟悉项目。 |
 |
31
cnbiglee 2015-12-24 10:03:36 +08:00 1
我认为只需要熟悉业务流程及代码的架构。然后需要修改的时候就可以大概知道上哪改就行了。不可能去熟悉每行代码的，没必要。
|
 |
32
songco 2015-12-24 11:36:00 +08:00 1
1. 按 usecase 的流程读代码, 花时序图 /流程图之类的(一定要有记录)
2. 改 bug 其实 2 效率比较高. 没有 bug 你可以考虑模拟在原有的业务上增加点功能. |
 |
33
wizardoz 2015-12-24 12:00:12 +08:00 1
熟悉每一行……这种要求也是醉了。
这种略大的程序，还是搞清楚整体结构就行了，然后哪里出问题看哪里，或者需要调整哪里看哪里。毕竟生命是有限的。 我不是说 10 万行代码看不完，只是过多的精力投入到细节上完全没必要，毕竟细节太多了。 |
 |
34
caixiexin 2015-12-24 12:06:33 +08:00 via Android
帮忙修一个月 bug 。。。
|
 |
35
xiaoshenke 2015-12-24 13:04:32 +08:00 1
从项目结构猜，从类名猜用途，运行打 log 。证实猜想是否正确。
找关键结点 比如入口函数 跳转函数等。 |
 |
36
sumuu 2015-12-24 13:32:37 +08:00 1
分享下我熟悉一个上 10W 行(伪)代码的当时做法.
1. 熟悉业务,分析业务,把关键业务入口找出来,然后跟踪代码执行流程. 2. 整理外部依赖,把数据库连接,缓存系统,第三方请求等等记录下来. 3. 非到必要时候,别瞎改代码,否则到处冒烟,不骗你. |
 |
37
huijiewei 2015-12-24 16:59:54 +08:00 1
1 、整理全局流程图，标注好注意点，打印出来
2 、整理模块划分，打印出来 3 、根据模块整理单独接口，打印出来 4 、整理公共服务模块，把公共服务模块都独立出来 做完这些对系统也了解的差不多了。 |
 |
38
oska874 2015-12-24 17:09:37 +08:00
多加班。
|
 |
39
sun2920989 2015-12-24 17:11:09 +08:00
边看边在心里骂,顺便做好记录和结构
词穷的时候基本上就理解了 |
 |
40
ragnaroks 2015-12-24 19:34:03 +08:00
重构
|
 |
49
dalang 2015-12-25 12:04:03 +08:00
从 api 层入手，了解重要的几个 api 的 workflow
|
|
50
pyengwoei OP @mko0okmko0 为了 RMB
|
 |
51
kaka8wp 2015-12-25 14:29:59 +08:00
先找找资料，改改小的模块，看看流程
|
|
52
pyengwoei OP 我准备这样做了，把功能都拆分出来，做成一个一个的小程序，一个程序实现一个功能，不知道这样怎么样
|
 |
53
cxbig 2015-12-25 16:20:20 +08:00
按功能拆分成小块，哪块要改就先搞清楚那一块。
能落实到文档的就尽快落实，这样后面的人也容易上手。 项目上了规模都不是轻而易举就能全通的。 |
 |
54
WendellSun 2015-12-27 01:59:11 +08:00
改 bug 。
|
Select Language