如何熟悉⼀个新项⽬
  很多新⼈进⼊⼀家新公司后，最头疼的就是如何快速了解公司的业务和项⽬架构。或者说不要求快速，给你⾜够的时间，也很难在庞⼤的业务中整理出思绪。当然，如果你碰到⼀个特别热⼼的⽼员⼯，事⽆巨细地给你讲，随时在你⾝边答疑解惑，那可能还好。但很可惜，我没有碰到这样的⼈，在加⼊新公司后，带我的⼈⼏乎没有花时间给我讲项⽬，也没有给我安排⼀些可以熟悉项⽬的需求。就这样的⼀个多⽉时间⾥，我慢慢开始靠⾃⼰的⼒量熟悉⼤概⼗个项⽬，并在过程中总结了⼀些⽅法，借此机会记录⼀下，并分享给⼤家。
  这⾥强调⼀点，我的策略并不是快速了解⼀个项⽬的具体业务，这个不同项⽬也不⼀样，⽆法总结。我的策略是⼤体了解整个业务线上的所有项⽬，⼤概摸清楚每个项⽬都是⼲嘛的，他们之间的关系如何，以便以后不论具体负责任何项⽬不⾄于不到⽅向，具体到细节的业务，虽然需要花时间，但相⽐对整体上的⼀头雾⽔，还是简单许多的。
⼀. 必要条件
  我们⾸先要想的是，有了哪些必要条件后，只要给你⾜够的时间，你总是能够完全了解整个项⽬的？这⾥说的必要条件不是“项⽬⾯对的客户是谁”，“项⽬⽤的框架是什么”这种，⽽是真真正正的必要条件，就好⽐⽤⼏条数学公理能推出整个数学体系⼀样。这⾥我总结的真正的必要条件只有这两点：
  源码位置（gitlab或svn），部署环境（dev/test/online）
  所谓项⽬，其实就是⼀堆代码放在了⼀堆机器上⽽已，所以这些就⾜够了。当然，为了更加节约时间，最好还要到wiki、jenkins、页⾯访问路径、数据库地址，我之所以说那两个必要条件，是想说其实项⽬本质上就是这么简单的⼀个事，你千万不要想的太复杂。它的业务可以⽆限复杂，但它的本质却逃不出这些，你千万不可以糊涂。当你⽆从下⼿或者什么都不清楚的时候，那么就主要把源码和环境弄清楚吧，其它的都是附属品。
⼆. 从页⾯到数据库的线
  有了上⾯的必要条件后，我们就开始了解项⽬了。由于不只是⼀个项⽬，所以千万不能深⼊具体代码，否则你就越来越烦直到放弃，也不会有好的效果。对某个具体项⽬的了解，⼀定要建⽴在对整体了解的基础上。这时我们⾸先为各个项⽬画出⼀条线，并标明每⼀个节点的信息，就像下⾯的样⼦：
  页⾯访问路径--前端项⽬--后台服务--数据库地址
  这⾥的⼀个前端项⽬可能对应多个后台服务，所以最终的图应该差不多是这样：
  这个整理的过程，主要是让⾃⼰梳理清楚，⼀共有哪些项⽬，哪些是前端可视的，哪些是后台提供服务的。并且，⼤致了解到了前端项⽬分别调⽤了哪些后台服务，通过后台服务和数据库的名称，我们能
从本质上了解到这条业务线提供了什么功能，从前端项⽬和页⾯路径，我们能了解到我们需要给⽤户展⽰什么。注意，这个阶段我们只是见名知意，即使点开页⾯，连接上数据库看看，也千万别花过多的时间，这个阶段的重点就是仅仅知道，这条业务线提的整体内容。
  在此基础之上，这个图可以不断细化，⽐如项⽬部署的机器，我们可以标注在项⽬旁边，或者保存在xshell⾥。此外所有⾮业务相关的，能查到的尽量都记录下来，这个真的为以后各种东西⽅便太多了，否则别看你现在节约了时间，把以后查相关东西的时间加起来，将会是天⽂数字了。
  这⾥关于整理项⽬部署的机器还有个⼩插曲，跟⼤家分享⼀下。由于这部分的信息没⼈会⼀个⼀个地告诉你，就算有也不可能说的特别全。所以我是借助jenkins来整理的。项⽬部署都需要⽤到jenkins，只要查看jenkins配置的命令，就可以把部署环境⼀⼀整理出来，这个我认为是最全⽽且最新的。不要和我说查wiki，如果公司wiki都写的这么全，我估计就没这篇⽂章什么事了。当时我的jenkins权限特别少，只能看⼀部分项⽬，⽽且还只能执⾏，不能看配置，带我的⼈也是抠门，每次问他都给我开通所需要的项⽬的执⾏权限，多⼀点都不给。后来我也懒得问了，由于jenkins机器⼤家都可以⽤root权限登陆，所以我进⼊jenkins的配置⽂件l，给我⾃⼰添加了⼀个admin权限，重启jenkins，再打开之后屏幕满满的项⽬都出来了，⽽且都可以查看和修改，畅通⽆阻。我就这样通过⼀个个jenkins的配置，整理了部署
的机器，也看了下启动的逻辑。
三. 了解项⽬间的关系
  这部分如果有⽼员⼯愿意和你说说，那最好还是了解⼀下。如果没有也没关系，先跳过这段，以后慢慢了解也是可以的。
四. 整理数据库表
  我们上⾯都是整理项⽬的⼤体框架，还没有涉及到具体的项⽬细节。这⼀部分，仍然不去涉及。如果说站在整个业务的本质上看，业务⽆⾮就是⼀堆代码运⾏在⼀堆机器上。那么站在单个项⽬来看，⼀个项⽬⽆⾮就是对数据库的增删改查操作⽽已，或者从使⽤者的⾓度看，⼀个项⽬就是输⼊⼀些参数得到⼀些返回结果。所以接下来我们要做两件事，⼀个是整理数据库表，⼀个是整理Controller层的所有接⼝。
  这⾥⾸先要选择⼀个核⼼项⽬去看，众多项⽬中⼀定有⼀个是核⼼项⽬，先从这个开始看起。
  如果数据库的表⽐较少，那我们拿⼯具导出来表结构，⼀个个看就⾏了，这个不难。但如果数据库表特别多，我们⾸先要将表名全部导出，筛选出那些核⼼的表。这⾥导出表名、筛选表以及后⾯的分析表字段，不妨给⾃⼰做个⼯具，我在遇到⼀些很⿇烦的或者感觉以后还可以通⽤的事情时，就会做成⼀个⼩⼯具，放在⼀个我给⾃⼰起名为javamate的程序中，这些⼩⼯具逐渐积累起来你会发现今后有意想不
到的⽅便。话说回来，如何判断哪些是核⼼表呢，不要着急，我们⾸先排除掉⼀些没⽤的。拿我在公司分析的系统来说，⼀共150多个表，其中有好多copy结尾的是备份，flow结尾的是流⽔，rel结尾的是中间关联表，statistics结尾的是数据统计表，log结尾的是⽇志表，config结尾的是配置表。等等。排除掉这些对核⼼业务理解⽆影响的表之后，所剩的也就20来张表，再根据他们的名字，可以看出好多表是属于⼀类的，⽐如order表就有各种order，按类别再分出来也就四五类，再分析起来就不难了。当然如果是更⼤的体系结构，那就要再不断做拆解。
  再具体分析这些核⼼表字段之前，还要做⼀件事就是出表中间的关系。如果表b中有个字段叫⽐如a.id，那么b和a就是⼀对多的关系，如果两个表有rel中间表，那⼆者就是多对多的关系，起码从逻辑上讲是这样的。这个分析过程我也是做了个⼩⼯具，通过程序来判断的。
  到此，你就对整体的数据库结构有所了解了。根据表名也能对表的⼤致内容有所了解，接下来就是针对具体的表，看⾥⾯具体的字段和前⼈给出的备注，这个过程就没有技巧了，要耐⼼，要慢慢熬。
五. 深⼊代码层
  当你对数据库表做了以上到了解后，你基本上对这个系统能提供什么服务了解到差不多了。这个不论你的代码长什么样⼦，数据库摆在那⾥，其实能提供的服务就已经差不多出来了，对于有经验的⼈来讲，代码的业务逻辑也⼤致能猜到个⼋九分。
  我认为⼀个业务相关的项⽬代码只分三个部分：
  1. 通过交互对⾃⾝数据库进⾏增删改查操作
  2. 通过定时任务或服务器脚本对⾃⾝数据库进⾏增删改查操作
  3. 调⽤或通知其他服务做⼀些事情
  如果只是单⼀项⽬，⽆⾮就是通过各种途径去玩⾃⼰的数据库⽽已，前两点⾜够了。⽽如果是微服务部署，那么加⼀个第三点⾜矣。我们将代码逻辑分成这三个部分看，快速了解⼀个项⽬就不成问题，甚⾄在你没有看过某⼀项⽬⽽突然有⼀个bug要你解决时，你也可以按照这种⽅式去快速定问问题。
  通过交互对⾃⾝数据库进⾏增删改查操作：这个⽆⾮是最简单的⼀部分，即使复杂也是代码较长，表较多⽽已。所谓的交互，或许是Controller暴露给前端⽤户的接⼝，或许是开⼀个rpc端⼝暴露给其他微服务的接⼝，总之是第三⽅去触发的。这⾥我也给⾃⼰做了个⼩⼯具，扫描出所有的暴露服务的接⼝，展⽰出⽅法名，路径名，参数列表和返回值等。和数据库⼀样，如果接⼝很少那么⼀个个看，如果特别多，还是先出⽐较核⼼的⼏个⽅法研究。这⾥我⽤的是postman，把要研究的接⼝访问保存起来，并且添加访问成功和失败的Example。这⾥我推荐⾃⼰开发的时候也把postman⽤起来，越详细越好，postman不只是可以简简单单访问你的接⼝，还能做批量测试，还可以⽣成api⽂档⽤于和前端交互。这
样你不但测试了⾃⼰的接⼝，还省的写⽂档了。⽽且postman还有个好处就是可以给⾃⼰的接⼝mock⼀个服务，这样即使你的接⼝挂了，或者你的接⼝根本就没写好，你可以让前端⼈员先访问你的mock，完全不影响前端边测试边开发，这才是真正的前后端分离嘛。整理出所有接⼝后，肯定⼤部分是很简单的，⼀看就懂，⼀层⼀层点进去直到数据库层的sql语句，该接⼝最本质的东西就出来了。如果是复杂的，那就⼀步⼀步debug，花时间总是可以分析的。如果再复杂的，你可以画流程图（这⾥我⽐较推荐⽤processon）。甚⾄⼏个接⼝围绕⼀个功能的，你可以画状态流转图。⽐如我之前看我们公司处理订单业务这块，逻辑确实⽐较复杂，我就画了类似如下的具有程序员视⾓的状态流转图（这⾥只是⽰例图）：
  状态流转图：横轴代表order_status字段的状态，纵轴代表当order_status是以上状态时，触发该接⼝操作会使该字段发⽣什么变化）
订单表 order_status 状态流转
0-待⽀付1-已⽀付2-已取消3-退款中4-已退款5-退款失败
⽀付成功异步通知来了-->1报错报错报错报错报错
⽤户发起退款报错-->3报错报错报错报错
退款成功异步通知来了报错报错报错-->4报错报错
退款失败异步通知来了报错报错报错-->4报错报错
  接⼝对表的影响图：这⾥你可以把所有涉及到的表以及表中的关键字段列举出来，然后看分别调⽤接⼝后对各个表字段的影响，变化的就⽤红⾊标出
有了这两种维度的视⾓，我相信再复杂的业务都能很理清楚，也能发现某些bug最本质的问题。我正是通过这样的⽅式，把⼀个本来不属于我的项⽬短时间内了解清楚，快速准确地修复了好多顽固的bug。虽然项⽬很烂，业务逻辑⼗分混乱，但正是这样⼀段时间锻炼了我深⼊代码理清逻辑的能⼒，也有了⾃⼰独特的⼀套⽅法。
  通过定时任务或服务器脚本对⾃⾝数据库进⾏增删改查操作：这个和第⼀种类型⼀样，只不过换了个⼊⼝。如果有些问题你发现并不是交互⽽产⽣的，那你就要寻其他⼊⼝。⽐如定时任务，或者启动的时候就开启的⼀些线程。寻这些⼊⼝的确不是特别容易，⽐较头疼，但也只是⼊⼝⽐较隐蔽⽽已。到他，记下来，具体分析过程还是按照上述⽅法去分析，就可以了。
  调⽤或通知其他服务做⼀些事情：上述两种代码如果你都摸得差不多了，整个项⽬对⾃⾝的玩法基本你已经摸透了，那还剩⼀⼩部分就是它和其他服务之间的交互。代码中⼀定有通过mq给其他服务发消息，
或者直接调⽤其他服务的接⼝，或者调⽤类似云推送的接⼝让它去帮忙像mq发消息。总之不管形式如何，都只是为了rpc其他服务⽽已。这部分代码可能更加隐蔽，但数量少，逻辑也简单，你需要做的仍然只是到它们。这部分也是为了解项⽬之间的关系打下伏笔。
  这三种类型的代码研究清楚后，对于⼀个业务型的项⽬来说，已经基本⾜够了。对于⼀些基础服务和中间件类型的服务，还是得慢慢积累技术深度才⾏，了解过程仍然也是可以有规律的，只不过需要更底层的⽅式去分类，⽐如将代码分成资源的加载，模式的匹配，等等。由于本篇⽂章是快速了解⼀个业务型的项⽬，所以就不展开叙述了。
六. 重新理清项⽬间的关系
  好了，这时候每个项⽬你已经⼤致了解，最起码调⽤的效果，数据库所能提供的服务，甚⾄某些关键部分的本质逻辑，你是清楚的。这个时候，要重新整理下项⽬之间的关系。
1. 根据之前的接⼝名称，详细了解下项⽬间的调⽤关系。理不清的部分去问⽼员⼯，这时候你带着⾃⼰的了解问，他们也能给出更多的
信息。
2. 看看每个项⽬中⽤到的中间件，主要是mq服务，看看谁是⽣产者，谁是消费者，以此来了解关系
3. 这时你应该已经开了好⼏轮的周会了，接下来的周会你应该能听懂部分内容。根据每个⼈的描述和最新的⼏组需求，逐渐摸清楚现在
怎么看项目是什么框架项⽬⾯临的问题，以及哪个项⽬是核⼼，哪个项⽬是辅助，哪个项⽬是以稳定安全为主的
  到此为⽌，整条业务线你就有了⼤致的了解，接下来就要结合你具体负责的内容，领导安排你做的⽅向，去看具体的业务代码了。深⼊其中，事⽆巨细地了解。但此时，你通过前⾯的努⼒，你已经可以站在⼀定的⾼度看每⼀个项⽬了，虽然你细节上还是不了解，但这是完全不同的。在研究具体业务代码的同时，不断地跳出来看整条业务线的框架，修正之前由于不了解具体业务⽽理解错误的架构。长此以往，你⼀定会在某个项⽬中脱颖⽽出，让⼤家认识到你的全局视野，这也是⾛出⽼是写增删改查代码怪圈的⼀个途径。慢慢会有⼈意识到，你对项⽬的理解总能站在全局的视野，很多需要跨项⽬去做的业务，也会⾃然⽽然想到你，慢慢地，你会接触到更为核⼼的东西，成为架构师，或者去转向产品，转向管理。
  这就是我总结的了解项⽬的过程，希望⼤佬们多多留⾔指点，提出问题，共同进步。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。