如何快速读懂公司给的原码

我刚开始在一家软件公司上班

公司原来有一个软件代码，我如何去读懂？

运行结果及报错内容

我的解答思路和尝试过的方法

我想要达到的结果

如果有人熟悉软件，先让同事给你讲解一下，梳理出业务脉络，然后去再去读代码。如果没人带，就自己先把软件功能熟悉，根据功能去找代码，一般公司软件多少都会有注释，根据功能去理解代码会事半功倍。
读代码的建议：

（1）先读懂整体框架，框架不一样，代码结构有差别，也就是首先得知道前端代码在哪、后端代码在哪、数据访问代码在哪等等。
（2）熟悉业务功能，根据业务功能找对应的代码，先看代码的骨架，最后再去看细枝末节，把一条业务理清后，再去看别的业务流程。
熟悉架构后，能帮助你知道去哪个目录层级下找代码；了解软件功能，能帮助你熟悉代码的主要逻辑，根据逻辑再去看代码，效果会比较好一些。

我觉得可以从以下几点入手（前提是你对软件相关的开发技术都有一些基础，否则先去把相关技术的前几节入门知识先了解一下）：
1、根据软件的功能使用说明书先了解软件的功能，先梳理一下软件大致分为哪几个功能模块
2、了解软件开发过程中是否使用了某些框架，如果有，那么去熟悉框架的基本结构，比如一个web框架，你得知道项目的基本结构组成，前端在哪，后端在哪，前后端如何交互等
3、软件是否用到数据库，如果有，了解一下数据库结构，从数据库结构上也能看出一些软件开发的脉络
4、然后就是从功能对应实现去对照着看业务逻辑代码了
5、这一点很重要，如果你拿到的软件有详尽的开发文档，那可以自己看，如果只有软件源码，注释还不够完善，那么找熟悉的同事在人家不是很忙的情况下，给大致讲一下吧，不要觉得不好意思，因为软件开发也是一个团体活动，交流很重要（当然，不要拿太小白的问题出来问，特别小白的问题，问度娘就好了）

走一遍业务流程，不懂的地方可以调试跟踪的同时，加上自己的注释。

如果公司沉淀好，直接看文档
如果公司沉淀差，只能人传人

虽说看文档更加直接，但是没有文档的话，更加会锻炼人，你可以尝试自己去多问，多了解业务，形成自己的文档，很多代码看不懂，有经验不足的因素，但是更多是业务不明白，业务一旦明白，代码能看懂很多。

我的经验：
1、先把代码拉下来（工作首先要把环境搭好）
2、看下pom文件引入了哪些依赖，大致就能知道项目是什么样子了（有没见过的包赶紧学习下，不然用到的时候尴尬）
3、复杂的项目找个人把业务给你讲下，简单业务自己点着看（了解下业务）
4、熟悉业务流程后按F12看下接口，对着接口看后台代码（熟悉接口）

技术角度：看项目的依赖和配置文件和项目中的config类型配置，了解技术栈和框架的应用；
业务角度：
1、如果有产品文档先看产品文档；
2、如果有api文档再看api文档；
3、使用idea的RESTful Web Services插件预览所有接口，然后自己根据注释和代码自己归类并记录；
经过这个过程，项目的功能宏观上就掌握了，然后就是看代码细节了，当然这个过程还是要和同事多沟通，产品，开发，测试都要沟通，初来乍到谦虚为主主动出击才能更快融入图案段

1、理清楚该软件的业务需求；
2、查看该软件已实现的功能；
3、查看该软件所用到的编程语言；
4、搭建开发环境；
5、先编译测试看是否能成功运行；
6、如果有软件文档可以根据文档理清程序逻辑，如果没有文档就从程序入口一步一步理清程序逻辑；
7、更具需求编写或修改程序；

1、找熟悉业务的人了解系统源码的业务流程；
2、尽量找系统设计文档、接口文档等资料进一步了解；
3、初略过一遍代码，原开发者是否有注释习惯。

1 先找说明书，看有没有技术文档
2 看有没有基本的框架模型代码
3 对照之前的代码框架和不断迭代的代码框架，找到不同点，然后仿照
4 我也是小白，这是我最近总结的经验，还有就是问度娘

读代码最重要有以下几点：1.了解整个项目的方向、需求，如果不去关注这一点，就无法真正认识项目本身。
2.等你接触到源码的时候，首先要分析框架，做出具体分析，把握住代码逻辑结构，这样理解起来会快很多！
3.具备扎实的语言基础，这是最关键的，读懂代码，最重要的就是自己的阅读水平。
4.参考前辈给的注释以及各种测试用例，能有机会询问创作者就更好了。
以上就是个人见解，不喜勿喷。

1、找熟悉的人按照业务流程演示一遍，了解系统的功能和主要逻辑；
2、看系统设计文档等资料验证自己的认识，了解系统架构，搞清楚技术选型；
3、编译并运行代码，顺着业务逻辑走一遍。

补基础，熟系业务，每天都跑程序，读程序，做一些小的修改，剩下交给时间，水到渠成。

个人经验你可以借鉴一下：

不要一开始一头扎进代码里，试图通读项目源码，这绝对会陷入无止境的细节，公司肯定不会给你那么多时间。
建议先找项目的架构设计和整体流程框架的文档来看，在顶层设计、数据流、业务流程等方面有个初步的了解。
代码run 起来，搭建跑起来的环境这个过程也是会让你熟悉这个项目所依赖一些东西。
调试（打断点、打日志）。
尝试去了解下某个功能或模块实现的整个流程，保证自己接到开发任务后，能在模仿的基础上，完成大部分开发，给自己争取更多的熟悉项目架构设计方面的时间，对后期个人提升也是会有很大帮助的。

1、如果你是新手，让你的leader安排一个老手讲解一下，并同步录制音频或者桌面操作视频。
2、如果你是老手，直接看api文档，上手项目操作即可。

建议你不要着急的快速读懂公司的代码，也许你快速的读懂了代码，但是如果不了解代码所处的背景，工艺，运行机制，工作流程，现状，以及公司的情况等条件，只是单纯从技术角度去考虑代码，那么很多时候你在处理问题时可能会处处受限制，甚至不断碰壁。公司招你进去是为了解决问题，但不是只为了解决一时的问题，需要从公司长远发展和客户的角度去解读并根据实际情况编写代码。

首先你要熟悉软件的一些功能，然后就想一下，如果你要去设计这些功能，你会用什么样的一个思路，然后询问公司的其他员工同事，来验证以及改正你之前的一些思路，完善一下再利用这个正确的思路去读源码

先确认功能需求

找到程序执行的入口
尽量找到相关的文档
通过代码，找到代码的执行流程

功能拆解

可以使用git 管理起来，一步步注释与运行部分代码，不断熟悉整个功能
大的功能，可以先拆解成小部分

画程序流程图

掌握整个程序的脉络

写文档与笔记

方便后期的个人搭建

最小系统环境搭建

整个代码的运行

重构

可以从如下几个步骤入手：
1、看看公司是否有需求文档、原型图、接口设计文档、数据库设计文档等相关资料
2、熟悉项目框架，比如哪些是业务相关的包，哪些是工具类，哪些是通用类等
3、启动项目，然后通过浏览器，按f12快捷键，然后点击页面中菜单，看下请求接口名称，然后复制，在开发软件快速搜索找到对应位置
4、通过项目中配置文件找到数据库信息，可以先熟悉下表结构
5、结合自己的理解，可以与老员工沟通下项目背景及架构，一定要带着自己的理解和问题，不要不经思考的问问题

1.根据业务逻辑了解源码各个模块的关系
2.针对性阅读关键模块代码，写测试用例调试源码，阅读源码过程详细备注
3.模块代码阅读懂后，根据业务关系，了解模块之间跳转关系。
4.在这个过程中，注意知识积累，技术文档积累

先了解软件的具体功能和模块（可能是模仿的哪个软件）
看文档，问问同事（要是是使用期公司的测评，就别问了，自己搞）

建议先找项目的架构设计和整体流程框架的文档来看，先从顶层设计入手，掌握这个软件整体结构，它有哪些功能特性，它涉及到的关键技术、实现原理等。

接下来才是逐渐厘清模块、函数之间关系，调用图。

这个时候不建议深入看每个函数，只需要做到对整体流程有所把控即可。

这个可以先让老员工讲解一下，然后看看一些文档，把业务走一遍，没事就debugger一下，大概了解一下

1、理清主线，建立架构的概念，千万不要急于查看代码细节，陷入局部泥沼；
2、多请教老员工，解决思路上的疑问；
3、多看多调试，熟悉代码，通过解决问题或者新增完善功能介入，调试代码会快速熟悉代码逻辑；

1.首先，源码所使用的语言语法你都要懂，这是根本。
2.明确一段代码的功能、作用是啥，知道这段代码大概实现了什么功能，是做了个查询，还是修改了数据等等
3.了解全局业务，如果你了解当前代码所处的业务背景，那么当你知道了一段代码的大概功能后，你自己就可以先设想，这个功能它应该需要哪些参数，返回什么东西。
4.带着自己的角度去看具体源码，你一边开始看具体代码，一边思考如果是自己，自己是不是也这样写？同时，要勇于产生质疑，因为如果你完全顺着老代码去思考，你很容易被绕进去，最后就是强行去分析他这样写的意义，极其难受。
5.总结：不要一上来就漫无目的的去看代码，要先思考分析了解代码结构和业务背景，最后以审查的角度去看代码，发现亮点了，那就是经验，发先槽点了，就要想：这段明明可以那样写...

看上面各位大佬答的都很好,我就说个我遇到的.
拿到的代码先不论有没有文档,连有没有注释都不好说,没有注释的情况下只能通过看类,函数,变量的名称来确认某个函数到底是干嘛的.
如果名字也是随便取,基本只能当成黑箱代码来运行了.
没多少时间给你从底层代码一行一行研究是干嘛用的.

首先，阅读需求文档。根据功能点去测试相应的功能点。

其他，浏览设计文档，并尝试了解代码的运行方式。一旦掌握了这一点，理解代码就变得容易了很多。查看类图，数据库设计文档，接口文档，架构文档，等就能更好地了解整体布局。

然后，要做的是编译并运行它。根据项目及其文档循序渐进，这可能很简单也可能很困难。
现在是时候打开你喜欢的 IDE 并开始探索了。一个好的探索起点是，尝试一步步浏览你熟悉的功能的代码。这样一来，你可以遍历各个层和子系统，并了解它们之间的关联。

最后，尝试为代码编写测试用例以完全理解它，这是理解代码不同部分之间的依赖关系的一种非常有用的方法。写测试用例之前，首先需要满足所有的依赖。

首选要大致清楚公司所使用的架构设计和使用的技术也方便查漏补缺
其次熟悉公司的产品，要知道这个产品是干什么的外包公司或者项目外包除外这种不多讲都挣钱不磕碜
最后熟悉项目的代码个人介意从表结构入手梳理表关系然后再结合他人的讲解去熟悉主要业务没必要消耗太多时间去消化分支业务
通过后续分配的任务来慢慢熟悉代码首先要明白垃圾代码一定少看甚至不看

自己先看一下源码虚心请教一下同事然后看看是否相应的文档还有框架有时间下来网上找找教程和视频学习一下

首先部署环境，将项目运行起来
可以的话，让同事帮忙讲解一下
熟悉项目使用的技术框架，明确前端代码在哪，后端代码在哪，数据库设计思路；
将项目跑起来，先熟悉业务功能，再结合debugger熟悉代码

1、认真阅读需求文档和设计说明书；
2、请教做过该项目的同事；
3、学会分析报错内容，会搜索问题，做好错误笔记
4、勇敢的尝试吧，每个人都是从小白走过来的，如果步子都不敢卖，在公司只剩害怕被炒了。

看编译配置，然后查看tree -L 3 看看其是怎么生成库怎么运行的，然后去根据顺序鲁代码，代码理清了去看LOG是从那边吐出来的。

最简单高效的方法就是从改bug开始，然后是新加功能，改几个bug或者完成一项新功能就能了解了。当然最总要的是有耐心和多请教。

从业务入手，公司的项目代码一定是为了解决公司现有的某些业务而存在，不会独立存在，所以要先了解清楚这个项目的需求，至少需求文档，原型图，设计稿你要先搞懂。
去使用这个系统，把自己当做一个测试工程师，摸透整个业务流走向，可以做笔记，文档，思维导图，流程图。
到这里才是去把代码仓库clone到自己电脑，然后在本地搭建起能够跑通业务的测试环境，数据库，后端服务，前端服务（以及配套的一些服务，缓存，消息队列，分布式）等等。
熟悉整个项目的代码结构，每家公司的代码结构可能不尽相同；从整体上把握下整个项目的架构（如果有架构的话，有些公司根本毫无架构可言），借助前人留下的技术文档，架构图，ER图等。
针对某一模块梳理，下断点，打日志，看看这个API到底是怎么进行数据流转的，都是用了哪些类的哪些方法，是如何实现的，如果让你去实现，你会怎么实现。
写代码，让你的前辈分一些不是很紧急或者是以前遗留下来的bug，一次为切入点更加深层次的了解项目，因为bug往往都是多个业务掺杂了以后出现的，当你修复了这个项目的所有bug，我不得不说，你已经是这个项目的最佳维护人了。

1、第一步先把程序跑起来
2、第二步找到程序入口，多看几眼

1.公司原来有一个软件代码，我如何去读懂？

首先最好不是先看代码，而是看代码运行的页面具有哪些功能，在了解了项目的主体具备的功能后，PC端浏览器上F12查看相关的请求后端的接口、手机移动端vConsole查看相关的请求后端的接口，本地开发工具ideal全局搜索F12查的接口，一层一层的往下走业务逻辑，看相关代码，即使可能原开发写的会让你摸不着头脑，但大部分的接口逻辑你是能看懂的。对于特殊的接口，复杂的业务逻辑的功能，可以放最后相关的逻辑只需要看大概的主题功能，细节的处理可以不用太去关注，除非此接口有问题，你不得不去细细研究。如果运气好的话，好心人的代码写了注释（特别详细），那会减少阅读代码的难度和时间。

2.运行结果及报错内容
首先明确本地环境ok，数据库连接各方面没有问题，若是此方面数据库连接失败或者是环境的原因造成的报错，在日志里面会显示jdbc的错误，或者连接失败等等；其次环境数据库没有问题出现的报错信息，看日志中灰记录报错信息例如常见的空指针异常、数组下标越界、参数错误等等此类的错误在日志中会显示大致到具体的某个代码类某个具体的行数，在通过这些报错去排查问题；最后不常见的报错信息，复制粘贴到百度找度娘靠广大的群众力量去解决了，毕竟百分之八九十的错误百度都可以替我们解决。尝试过的方法就是我上述所说的定位是什么情况的出错，定位到具体的出错行，做一些逻辑处理或者百度看看其他人的东西，在重新运行看是否继续报错。最终满足实现功能的正常使用，或者优化了代码使得速度得到了提高。

首先需要了解开发所使用的语言。如果是c++，或者java。都是有一个main函数的，java的叫mainactivity。然后从main入手，看看使用的是哪一个类。类里面会有很多的方法。如果有注释就能知道这个方法是干什么的。如果没有注释。要么自己去了解他。要么就是看上一个人留下的开发文档。
不过打铁还需自生硬。自身过硬的技术才是关键。都说读懂别人的代码才是牛逼。所以还是需要慢慢探索。公司也会给你时间去把整个代码框架了解清楚

先在自己电脑跑起来熟悉熟悉功能再去找相应的方法干就完了！！！！！！

履历新职，部门老大都会让我们花几天时间把上一个人的代码熟悉下。
跟着代码流程走一遍，了解其书写特点，毕竟每个人书写特点不一样。
跟着流程走一遍，基本上没啥大问题的。

最有效的办法是做该软件的售后支持，通过定位解决问题去读懂源码，带着问题去读源码永远比探索性的读源码效率高

会debug吗？

把程序跑起来
熟悉下各个模块的功能和逻辑
打开浏览器控制台，找到接口，一步步的跟下去。

感觉上面的回答都太书面化了
根据我自身的经验
你接触到公司项目源码后
从整体框架入手的话如果项目比较大点代码多，很难短期理清楚整个框架是怎样的
应该选择一个功能模块着重理解这个功能模块先整体理解模块中各方法的大致作用，然后理清楚这个模块的流程
理清流程后再进一步看每个方法的细节
最后自己参照这个功能模块实现一个相似的功能
你可以询问下主程帮你选择一个功能模块然后自己按照上面方法了解这个模块，期间有不明白的直接问就好了，等基本了解后，可以找主程给你一个相似功能的单子或者你注释这个功能模块再自己重新写一遍中间有问题都可以去问主程或者同事
通常第一个功能的时候会比较难一点但是只要第一个功能完成了后面就慢慢会熟练起来的

先看看大概，知道有哪些功能，不用太具体，具体的也看不懂。然后就是先挑能懂一点的试着改一改。千万记得留着原文件备份。后边就是慢慢试错了，我可以不懂他是怎么跑起来的，能跑就行。试功能可以分模块逐步调试，一点点改，最终让他变成你的模样。一点点改的时候记得每改一块都新建一个新的文件夹把之前的文件复制过来，不然改着改着就不知道之前改了什么了。

首先，你要先懂这个软件的业务逻辑，是怎么去运行的。然后再去熟悉所选用的技术框架，再去按业务逻辑去懂代码的逻辑和实现原理

这边建议先明白是什么框架然后去翻技术文档

1.分项目进行观看
2.例如web 就体验一下流程后面跟着流程去梳理代码逻辑一步步深入
3.像前端通过路由模块去弄每个功能路由 ajax 工具类等
4.通篇看完了基本就了解代码了
5.有什么问题可以私信找我哦

建议先了解业务，在了解公司整体框架，然后进入项目分功能模块读代码，理解代码

如果公司有需求,设计文档,且代码有注释,哪怕不是很详细你也可以通过下面步骤进行快速熟悉
1.大致浏览需求文档,看项目大概方向
2.浏览设计文档,看使用了什么技术框架,结构
3.运行项目,查看功能与源码一一对应起来,这样过一遍差不多就能将一个项目快速熟悉,掌握大部分内容
如果没有需求设计文档,且代码很少有注释,代码步规范,你可以从下面入手
1.运行并调试项目
2.查看每个功能的代码逻辑,使用调试步骤一点点熟悉项目代码

最后,才上面的;流程走完一遍,按照自己对项目的理解,写出对应的测试用例,当测试用例完全通过后,那么恭喜你,你已经理解完成代码了
有帮助请采纳,谢谢

你应该把错误贴出来，大家才能看到问题，如果时springboot的话，运行的时候要看下错误日志，百度去查一下报错原因

最快速的办法就是找熟悉这个软件的人给你讲解，你给公司领导反映，让公司安排一个人来带带你，如果完全靠自己，那不可能快速，如果没有熟悉代码的人，那就找熟悉使用软件的人，先了解功能，再去读代码，也可以很大程度上加速

看框架，逻辑结构，模块

主要搞清楚业务逻辑，读的过程中自己多写注释

望采纳！谢谢

大概熟悉流程：
1、安装开发环境以及相关软件
2、拉取代码，配置相关服务，运行
3、看一些常用的模块功能代码，从接口层到数据层代码。(没必要看所有代码,每个人开发逻辑不一样)
4、熟悉一些工具封装代码，方便开发。
5、了解公司业务，阅读相关文档。再去走几遍代码流程。

兄弟，我是96年的，目前也是在实习，在一家软件研发公司，公司是做血液透析机器的，代码将近五十多万行，有嵌入式方面的，比如：驱动程序，汇编语言，C/C++。也有应用层的例如：QT上位机代码编写的ui界面，还有测试的脚本编程shell语言。

每天我都在看代码，和处理代码逻辑，看的真的相当难受，有一些根本没有注释，函数名字也不是真正的英文，很是头疼。

自从，我用nodepad++和source insght看代码对照起来，把调用和关联性大的整理在一起，确实逻辑清晰了不少，看代码要有针对性。

一定要从main.c看，看他是怎么调用其他函数的，把整个先后，层次整理清楚，对整个框架也就有所了解了，总之，如果代码很多，还是要慢慢看，注重标志位和函数，如果觉得我说的不错的，请采纳，也可以哎特我，相互学习嘛

通常情况下，要想能够快速了解代码并融入到开发团队中，应该做好以下几件事：

第一：从功能入手。不少公司的代码都是经过多个程序员的编写，难免在书写的过程中存在一些不规范的情况，要想了解这些代码最直接的方式就是从功能入手，根据功能的执行过程来梳理代码结构。不少程序员在半路接手别人代码的时候，通常都是采用类似的方案，这样也不会影响新功能的开发。

第二：做好标注。有的程序员在看代码的过程中会对代码进行一定的标注，标注的过程一方面可以梳理代码的功能，另一方面也方便回头再看。不少初级程序员采用标注代码的方式是比较适合的，因为标注代码的过程也是学习的过程。

第三：注重交流。不同团队往往都有较为统一的编码规则，所以对于初入团队的新人来说，应该多找机会与团队中的主力程序员进行交流，在交流的过程中往往就能了解到一些编码的结构和规则，这对于阅读代码是有较大帮助的。另外，遇到比较棘手的问题时，也不要一味的自己思考，完全可以通过交流得到答案。作为新人来说，一定不要不好意思，因为这也是为了工作能够顺利开展。目前不少科技公司也会为新人配备一名主力程序员，这样会提升新人的成长速度。
对于初入职场的程序员来说，一方面要多读代码，另一方面也要多动手敲代码，随着自身编程能力的提升，阅读代码的能力也会随之提高
有什么问题，可以经常在社区多交流交流

多问多说没事请技术领导喝酒撸串这样他不但会给你讲源码还会对你照顾一下没事还替你背个锅啥的。。。

分析框架、熟悉项目架构、软件流程图

debug或者打印日志

先熟悉业务流程，然后让原来负责的手把手讲解最好，后面就看你自己按流程运行代码碰到问题不懂就问这快没有捷径

熟悉框架，找原参与开发着讲解需求，具体问题具体分析

我觉得可以遵循以下几个步骤：

获取项目相关信息
进入一家新公司后，如果遇到不负责任的同事呢，可能直接甩给你项目地址，然后就让你自己研究了。这就好比产品经理直接甩给你一个需求让你直接上线一样，怎么实现我不管。

这种情况下，我们首先要做的事情是尽可能多地获取项目相关信息，来帮助自己了解项目。比如项目介绍文档、项目功能说明文档、业务流程图、项目历史迭代情况、项目架构文档、技术选型背景等等。

像我的话，就会询问同事：这个项目背景是什么呀？这个项目有没有啥文档呀？之类的。

不过有些公司或项目可能过于敏捷，平时光做需求，不写文档，逻辑全靠口口相传！
也没关系，请同事给你介绍一下项目的业务和技术信息就好。

刚进公司有问题一定不能憋着，要多问，让自己尽可能多地了解项目代码之外的东西。

了解业务流程
技术是为业务服务的，千万不要连自己项目是干嘛的、有什么功能、为什么要做这个功能都不知道，就去看代码、想着快速把需求完成。最好不要把自己当成临时工，而是要当成项目的负责人。

我的话一般会先阅读文档或者请同事来给我介绍项目的背景，即为什么要做这个东西；然后对着产品本身（可能是网页或者 APP）来体验项目的功能；最后再重点关注自己要做的业务、负责的功能模块，了解它的历史、业务逻辑等。

整体的思想就是从整体到局部，由大到小吧。

这里为什么我反复强调要了解项目的背景呢？聪明的朋友一定能想到。因为你刚进一家新公司或者一个新项目，如果自己啥都不懂，别人说啥你就做啥，就很有可能出现这个项目 / 功能本身根本没有任何意义、你只是帮忙收拾了个烂摊子的情况。。。
3. 阅读项目文档
阅读公司的项目过程其实和阅读开源项目是一样的，基本上项目的代码仓库都会有一个 README.md 文件。

这个文件往往会介绍项目的背景、功能、技术栈、如何启动、如何贡献代码等等。

我会先整体扫一遍文档的目录，然后优先关注项目的技术栈以及如何启动。

一般 GitHub 等项目平台都会帮你生成文档目录，可以很快地跳转。也可以把文档下载到本地，用 Typora 之类的 Markdown 编辑器打开，从而清晰地看到文档的目录。

因为如果你了解了项目用到的技术，而你正好会用这个技术的话，心里就多了几分底气，项目的架构也能大致了解了，后面再去看代码就轻松地一批。

举个例子，看到技术栈中出现了 Ant Design Pro，我正好用过！我就知道这个项目大概率使用了 React、Ant Design、Webpack、Dva、Umi 等技术了，它的代码结构如何、配置文件在哪里、页面文件在哪里、如何启动也差不多能 get 到。
像我平时在 GitHub 上找开源项目时，除了功能外，就是关注技术栈，如果项目文档中提到的技术我都会用，那么我就很有自信这个项目我肯定能学的动、学得懂。

所以这也是为什么要多了解和积累一些技术。

补充一下，如果作者没在文档中写明技术栈怎么办？这里有个小技巧，去看项目的依赖管理文件，比如前端的 package.json 、Java 的 pom.xml 或 build.gradle 等。

在公司里那肯定是找同事，最好是之前干这个活的，一个人虚心请教的人，大家都会回答的。公司里面学习语言这些真的方便，毕竟同事教你的就是能胜任这个公司的工作的，不像我们在学校，只能靠自己自学，害。

最快速的方法当然是负责开发某个模块的人对你讲解。
如果代码有注释，可以自己看。
即使你运行了整个软件，你需要一个一个去了解，哪个菜单对应哪个Form

建议参与项目维护，在这个过程中慢慢熟悉，总之，你不会很快熟悉代码，公司也不可能让你熟悉所有代码。

1.了解一下整个系统的业务
2.找一个简单的功能，代码单步调试，熟悉整个框架的调用逻辑，知道后期做的时候需要添加或修改那些地方，做那些配置。
3.结合功能看数据库的一些文档，方便知道每个操作处理的数据

1.有信心，毕竟写比读难多了。
2.少问同事，要靠自己。
3.实测结合阅读，可以事半功倍。

确实就是用软件逆推就行

获取项目相关信息
进入一家新公司后，如果遇到不负责任的同事呢，可能直接甩给你项目地址，然后就让你自己研究了。这就好比产品经理直接甩给你一个需求让你直接上线一样，怎么实现我不管。

像我的话，就会询问同事：这个项目背景是什么呀？这个项目有没有啥文档呀？之类的。

不过有些公司或项目可能过于敏捷，平时光做需求，不写文档，逻辑全靠口口相传！

也没关系，请同事给你介绍一下项目的业务和技术信息就好。

刚进公司有问题一定不能憋着，要多问，让自己尽可能多地了解项目代码之外的东西。

了解业务流程
技术是为业务服务的，千万不要连自己项目是干嘛的、有什么功能、为什么要做这个功能都不知道，就去看代码、想着快速把需求完成。最好不要把自己当成临时工，而是要当成项目的负责人。

整体的思想就是从整体到局部，由大到小吧。

这里为什么我反复强调要了解项目的背景呢？聪明的朋友一定能想到。因为你刚进一家新公司或者一个新项目，如果自己啥都不懂，别人说啥你就做啥，就很有可能出现这个项目 / 功能本身根本没有任何意义、你只是帮忙收拾了个烂摊子的情况。。。

阅读项目文档
阅读公司的项目过程其实和阅读开源项目是一样的，基本上项目的代码仓库都会有一个 README.md 文件。

这个文件往往会介绍项目的背景、功能、技术栈、如何启动、如何贡献代码等等。

我会先整体扫一遍文档的目录，然后优先关注项目的技术栈以及如何启动。

项目文档目录

因为如果你了解了项目用到的技术，而你正好会用这个技术的话，心里就多了几分底气，项目的架构也能大致了解了，后面再去看代码就轻松地一批。

举个例子，看到技术栈中出现了 Ant Design Pro，我正好用过！我就知道这个项目大概率使用了 React、Ant Design、Webpack、Dva、Umi 等技术了，它的代码结构如何、配置文件在哪里、页面文件在哪里、如何启动也差不多能 get 到。

Ant Design Pro

像我平时在 GitHub 上找开源项目时，除了功能外，就是关注技术栈，如果项目文档中提到的技术我都会用，那么我就很有自信这个项目我肯定能学的动、学得懂。

所以这也是为什么要多了解和积累一些技术。

先把项目跑起来
关于这点没什么好说的，先把代码拉下来、安装依赖、按照文档把项目跑起来，才能更好地了解和调试项目。

比较麻烦的点可能就是环境的搭建，比如本地安装 MySQL、Nginx 代理之类的。不过现在很多公司也会采用开发机、或者远程开发环境的模式，直接连接某个远程库就好了，能省很多事儿，也可以请教一下同事怎么搭建环境比较方便。

阅读代码
终于到了读代码的环节，建议大家遵循两个原则：

由整体到局部：先了解整个项目的目录结构，每个目录都是做什么的，比如在哪里写页面？在哪里改配置？在哪里改接口？怎么切换环境等。还要了解项目的模块划分，比如哪些代码是用户模块、哪些代码是订单模块，可以通过 JetBrains 等开发工具来自动生成 UML 类图，更清晰地了解。
结合业务：读代码的时候尽量不要裸读、按顺序读，而是可以配合系统去定位代码。比如阅读用户登录功能的后端代码时，可以在前端执行一次登录，然后在浏览器 F12 网络请求中找到登录对应的后端请求，再到代码中全局搜索这个请求即可。阅读用户下订单的代码时，可以先在前端模拟一次下单操作，了解整个过程，从而更好地理解请求之间的顺序和依赖关系。
6. 上手开发
最后也是最关键的一点，读代码不能只读代码，一定要多上手去写、去执行、去调试。

必要时可以专门新建一个分支，在这个分支里无论怎么 “为所欲为” 都不会影响到正常已上线的代码。可以自己复制代码去执行一遍、自己给代码流程加上一些日志来帮助理解数据流转过程、或者 Debug 调试等。

其实刚进一家新公司时通常不会给你安排太复杂的工作，基本就是增删改查、或者给你一个小页面小功能去做，帮助你熟悉代码。有些时候，哪怕你不理解整个项目的架构，通过复制同事已经写过的代码也能完成工作。不过还是建议大家，为了长远的发展，不要只局限于自己负责的小功能，可以多了解系统的上下游和整体架构，提高自己的全局观。

拿着酬金骗人的吧

https://baijiahao.baidu.com/s?id=1726595001368417944&wfr=spider&for=pc

可以请教之前参与这个源码开发的同事
让熟悉的人给你讲解
找相关人员要到源码相关的文档资料
根据源码找到数据库配置，然后用工具连数据库，查看库表结构设计以及数据，方便理解代码功能
通过源码识别出依赖的所有中间件
找出源码依赖的所有第三方服务，给比sso等其它业务系统

如有帮助，请采纳，十分感谢！
也可以把源码发给我，我看懂后给你讲解。

1、阅读源代码的说明文档，比如本例中的README, 作者写的非常的详细，仔细读过之后，在阅读程序的时候往往能够从README文件中找到相应的说明，从而简化了源程序的阅读工作。

2、如果源代码有文档目录，一般为doc或者docs，最好也在阅读源程序之前仔细阅读，因为这些文档同样起了很好的说明注释作用。

3、在阅读程序的同时，最好能够把程序存入到cvs之类的版本控制器中去，在需要的时候可以对源代码做一些修改试验，因为动手修改是比仅仅是阅读要好得多的读程序的方法。在你修改运行程序的时候，可以从cvs中把原来的代码调出来与你改动的部分进行比较(diff命令), 可以看出一些源代码的优缺点并且能够实际的练习自己的编程技术。

4、从makefile文件入手，分析源代码的层次结构，找出哪个是主程序，哪些是函数包。这对于快速把握程序结构有很大帮助。

5、分析函数包(针对C程序)，要注意哪些是全局函数，哪些是内部使用的函数，注意extern关键字。对于变量，也需要同样注意。先分析清楚内部函数，再来分析外部函数，因为内部函数肯定是在外部函数中被调用的。

6、需要说明的是数据结构的重要性：对于一个C程序来说，所有的函数都是在操作同一些数据，而由于没有较好的封装性，这些数据可能出现在程序的任何地方，被任何函数修改，所以一定要注意这些数据的定义和意义，也要注意是哪些函数在对它们进行操作，做了哪些改变。

7、从main函数入手，一步一步往下阅读，遇到可以猜测出意思来的简单的函数，可以跳过。但是一定要注意程序中使用的全局变量(如果是C程序)，可以把关键的数据结构说明拷贝到一个文本编辑器中以便随时查找。

8、阅读程序的同时，要注意一些小工具的使用，能够提高速度，比如vi中的查找功能，模式匹配查找，做标记，还有grep，find这两个最强大最常用的文本搜索工具的使用。

首先要了解系统的框架设计，需求，数据库设计关系，再根据出现的问题，跟踪到对应的代码。