各位大佬,我不是计算机专业,是电气工程专业毕业,在从事电气领域的软件产品开发工作。
刚进部门不久,被领导安排学习某产品的 c++开发工作。
我们的产品中不涉及什么高深的代码,代码中更多体现的是一些工程经验和电气业务相关的知识和逻辑。
部门人少事儿多,用户霸道难搞,代码中涵盖的功能很杂,特殊需求、定制化功能很多。未来我很可能要主负责这个产品的开发、运维和技术支持。是否有必要把这个产品的代码通读一遍?了解一些需求细节和当时开发该功能的背景?
我已经在尝试阅读某些功能模块,但不得不说,效率很低,而产品规模又很庞大,所以特来请教,想听听大佬前辈们的经验。
感谢您的分享! Thanks♪(・ω・)ノ
1
irisfor 287 天前
有具体任务再具体看呗,太闲了就尝试魔改一些功能,改着改着就知道从哪儿看了
|
2
jydeng 287 天前
应该先看文档
|
3
heyli 287 天前 1
看文档 了解业务 理清关系人 再看代码
|
4
passon 287 天前
如果刚工作 1 ,2 年看看还是有必要的,工作 7 ,8 年就没必要了
|
5
corningsun 287 天前
@irisfor 可以看,但是千万别改。 一行注释都不要动!
|
6
Orenoid 287 天前 1
能通读的话肯定是最好的,但通常时间上是不允许的,而且性价比可能也不高。
如果有文档(还在维护的)的话,可以先看文档。如果同事愿意的话,可以请他帮你梳理下系统的大致框架结构。 这些都没有的话,那就先理解业务,然后从两个点切入去看代码:1. 用户频繁使用的功能模块 2.BUG 比较多的功能模块。 |
7
PickOne 287 天前
魔法!勿动!
|
8
abc500 287 天前 1
职场三步曲。 遇到问题。你的流程应该是这样
1 能不能不干 否 2 能不能晚点干 否 3 能不能让别人来干 nice 说句实在的 活只会越干越多 |
9
JoeDH 287 天前 via Android
看主要模块的,细节不要深入,只追踪流程。
然后再看自己需求涉及到的那部分,细看。 |
10
pipixiadexiapi 287 天前 1
没必要,屎山里也学不到什么技巧。还是先懂业务再了解逻辑最后再去看实现
|
11
tonytonychopper 287 天前 1
可以看有没有现成的文档,没有的话就多找同事请教一下,然后自己梳理一份文档
|
12
gimp 287 天前
没必要、读不完
|
13
fighte97 287 天前
屎山的定义不就是没有有效文档 混乱没法看的代码
正常人都是在工期催促下往上糊 |
14
murmur 287 天前
看一个模块,看看别人是怎么屙屎的,学学人家的姿势就行,最悲哀的是屎山你也要模仿
|
15
dswyzx 287 天前 1
如果自己能做主,有新功能的时候进行缓慢的重构,但做好随时回滚的准备.如果就是大头兵.就像楼上兄弟说的,连一行注释都别动
|
16
thetbw 287 天前
确定看的懂?
|
17
xingchenxf 287 天前
工作这么多年,我还从来没有把接手的任何项目代码看完过。
正常面向用户的代码,哪个工程不是 10 万行代码量以上的,这咋看的完? |
18
Sigrdirfa 287 天前 via Android 1
先认识人,知道如果现在出问题了搞不定应该找谁,然后是谁会给你提需求,谁管理你的 KPI/OKR ,谁是你的上下游。
|
19
irisfor 287 天前
@corningsun 改完别提交呀 随便动~
|
20
zeroDev 287 天前 via Android
通读毫无意义,摆烂睡觉
|
21
chenyu0532 287 天前 1
有文档先看文档,千万不要通读,以后搞哪块再看,没有目的的读极其容易让人绝望。。
|
22
Franklinpw2600 OP @chenyu0532 嗯嗯,这也是我工作中的感受,没有目的的阅读就像大海捞针,很难获得有用的信息。
|
23
Franklinpw2600 OP @Sigrdirfa 感谢,这也是部门前辈建议我的,先搞清楚工作中人与人的关系,遇到问题先找人对接是最快速和高效的。
|
24
Franklinpw2600 OP @murmur 是啊,有些无奈
|