现在已是5月，春招已经接近尾声，许多大学生已经开始踏入互联网公司进行项目开发（比如我），不得不阅读公司的文档和代码。对于搞后端开发的朋友们来说，不同的业务复杂度也各不相同。对于通信、金融和电商这类领域来说后端的业务也会相对比较复杂。刚到公司和同事们工作时，应届毕业生往往不知如何下手。目前我已经实习几个月了，整理一下这段时间的收获，希望对刚进入互联网公司实习的朋友们有所帮助。
理解业务领域模型
领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。
业务领域基础知识要先掌握，熟悉业务领域的相关概念，以及概念之间的关系。软件系统是现实生活的映射，某一个领域相关的业务代码，里面都有现实生活中概念的映射。比如电商领域有销售额、品牌、转化率等概念，他们映射到代码中的模型是怎么样的。
搜集代码相关文档
向同事索要相关的文档，包括
- 用例图、类图、时序图等UML图：这些图要会看会理解，学习过面向对象软件设计的朋友应该对这类图不陌生，如果没了解过，一定要去掌握。
- API请求响应参数及其说明的文档：知道有哪些API，各自的参数是什么。
- 项目的架构图：微服务架构？单体架构？用到哪些技术？没听说过就去了解。
- 数据库表的设计
- 其它
代码阅读
了解程序流程和总体框架
明确一些函数大概是实现什么功能就够了，不要去过多的关注和沉迷在功能模块的实现细节中。当须要定位到详细的某个功能实现模块的时候，再切换到函数实现中一点点分析代码就ok。假设对某个地方不太清楚，能够自己改动下源码，执行一下看看执行的结果如何。
第一遍乃至于第二遍一定不能钻的过深，开始的时候往往会因为一个小功能而打开了IDE十几页的标签页、如果你是这样的，那么你接下来看代码会越来越乱，心神不宁。
阅读方式一：自底向上
迅速了解这个项目是解决什么问题的，另外TA是什么技术解决这个问题的。
从一个模块开始看起，知道这个模块在干什么，提供了哪些接口，功能是什么。借助IDE，下断点，修改一些代码，看看被你修改过的代码会出现什么样的作用。
一个个模块看下来，最后再看看这些模块是怎么被组织起来的，这个项目你也就了解了。
阅读方式二：自顶向下
适合结构清晰、组织有序的项目。
阅读的时候，从一个较高的抽象层次进行阅读，看到一个函数，或者一个类，不去看里面的实现，而是从函数或类的名称推测其是做了什么。这样，很快就能看完一遍代码，然后内心想：嗯，这个东西大概就是在做xxxx事情
第二遍继续从头看代码，可以开始看里面函数的实现，同样的，遇到函数里面的函数或类的调用，通过函数名或者类名去猜测其用途。
以此类推，一层层看下去，某些不重要的部分，可以直接跳过，不要像我一样，某个函数的实现没看，心里就痒痒。其实你去看了，对你从宏观上理解项目帮助不大。
结合文档进行阅读
对照代码相关文档，看一下具体哪些文档的描述是怎么实现的。
使用UML帮助我们整理思维，使用类图来分析类与类之间的关系，使用UML里的活动图。配合IDE工具分析核心业务流程，理解软件是怎样工作的。
自我驱动看代码
比方思考某个功能是怎样实现的呢？然后推測可能是怎样实现的。然后再项目代码中一点点去跟踪源码，慢慢的剥茧抽丝，相信你会有恍然大悟的感觉。单纯的看代码真心没劲枯燥，并且效率不高。
使用强大的工具
- 利用IDE的跳转、全局搜索等功能
- 使用Understand等代码分析工具
- 思维导图工具，构建你对代码的理解
心理状态的调整
项目源码的代码量多没啥。可是我们自己心里不要着急，慢慢来。自己努力的功夫到了，多花点时间在看代码思考代码上，公司的代码会被你一点点啃透的。
沟通
与项目文档，和项目开发者（维护人员）进行沟通 ，在看代码的过程中，遇到模糊不清或者自己拿不住的代码，要及时和同事沟通，他们对代码的熟悉程度比我们强。虚心有礼貌的问人家。否则自己在那憋着瞎猜代码的含义，费时费力还得不偿失，开口求人帮忙就那么难？嘻嘻，你帮我下，我帮你下。咱俩慢慢就熟悉了嘛 。
But，问过的问题就请不要问第二遍，否则人家内心一万个草泥马奔腾而过。问问题的时候准备好纸笔记录，有问题最好马上解决，当面一次性解决所有的疑惑，效率最高，也最大程度不去打扰同事。
