请教：刚进部门，是否有必要把未来要负责的产品的代码通读一遍？

[Franklinpw2600]

背景

各位大佬，我不是计算机专业，是电气工程专业毕业，在从事电气领域的软件产品开发工作。

刚进部门不久，被领导安排学习某产品的 c++开发工作。

我们的产品中不涉及什么高深的代码，代码中更多体现的是一些工程经验和电气业务相关的知识和逻辑。

困惑

部门人少事儿多，用户霸道难搞，代码中涵盖的功能很杂，特殊需求、定制化功能很多。未来我很可能要主负责这个产品的开发、运维和技术支持。是否有必要把这个产品的代码通读一遍？了解一些需求细节和当时开发该功能的背景？

我已经在尝试阅读某些功能模块，但不得不说，效率很低，而产品规模又很庞大，所以特来请教，想听听大佬前辈们的经验。

感谢您的分享！ Thanks♪(･ω･)ﾉ

[irisfor]

有具体任务再具体看呗，太闲了就尝试魔改一些功能，改着改着就知道从哪儿看了

[jydeng]

应该先看文档

[heyli]

看文档 了解业务 理清关系人 再看代码

[passon]

如果刚工作 1 ，2 年看看还是有必要的，工作 7 ，8 年就没必要了

[corningsun]

@irisfor 可以看，但是千万别改。 一行注释都不要动！

[Orenoid]

能通读的话肯定是最好的，但通常时间上是不允许的，而且性价比可能也不高。
如果有文档（还在维护的）的话，可以先看文档。如果同事愿意的话，可以请他帮你梳理下系统的大致框架结构。
这些都没有的话，那就先理解业务，然后从两个点切入去看代码：1. 用户频繁使用的功能模块 2.BUG 比较多的功能模块。

[PickOne]

魔法！勿动！

[abc500]

职场三步曲。 遇到问题。你的流程应该是这样
1 能不能不干 否
2 能不能晚点干 否
3 能不能让别人来干 nice
说句实在的 活只会越干越多

[eastjoehan]

看主要模块的，细节不要深入，只追踪流程。
然后再看自己需求涉及到的那部分，细看。

[pipixiadexiapi]

没必要，屎山里也学不到什么技巧。还是先懂业务再了解逻辑最后再去看实现

[tonytonychopper]

可以看有没有现成的文档，没有的话就多找同事请教一下，然后自己梳理一份文档

[gimp]

没必要、读不完

[fighte97]

屎山的定义不就是没有有效文档 混乱没法看的代码
正常人都是在工期催促下往上糊

[murmur]

看一个模块，看看别人是怎么屙屎的，学学人家的姿势就行，最悲哀的是屎山你也要模仿

[dswyzx]

如果自己能做主,有新功能的时候进行缓慢的重构,但做好随时回滚的准备.如果就是大头兵.就像楼上兄弟说的,连一行注释都别动

[thetbw]

确定看的懂？

[xingchenxf]

工作这么多年，我还从来没有把接手的任何项目代码看完过。
正常面向用户的代码，哪个工程不是 10 万行代码量以上的，这咋看的完？

[Sigrdirfa]

先认识人，知道如果现在出问题了搞不定应该找谁，然后是谁会给你提需求，谁管理你的 KPI/OKR ，谁是你的上下游。

[irisfor]

@corningsun 改完别提交呀 随便动~

[zeroDev]

通读毫无意义，摆烂睡觉

[chenyu0532]

有文档先看文档，千万不要通读，以后搞哪块再看，没有目的的读极其容易让人绝望。。

[Franklinpw2600]

@chenyu0532 嗯嗯，这也是我工作中的感受，没有目的的阅读就像大海捞针，很难获得有用的信息。

[Franklinpw2600]

@Sigrdirfa 感谢，这也是部门前辈建议我的，先搞清楚工作中人与人的关系，遇到问题先找人对接是最快速和高效的。

[Franklinpw2600]

@murmur 是啊，有些无奈