程序员吐槽：入职3个月了，还在看祖传代码！

很多人认为程序员的工作只有敲代码，其实，敲代码只是程序员工作中的一个重要组成部分。在敲代码之外，他们还有着很多其他工作内容。

比如：看别人的代码

很多程序员进入公司的第一件事不是敲代码，而是先熟读前辈留下来的代码，了解项目逻辑、系统架构、功能模块，对系统有一个大致的认识，各个功能能找到相应代码实现的位置。

有程序员就曾吐槽，自己刚到公司，连续看了3个月的祖传代码。还有的程序员还在看2012年的代码！

比如：了解需求+写文档+无限沟通

这可以说是程序员在敲代码之前的必备工作。

如果不认真看需求文档，可能会让自己敲很多无用代码，最后浪费了时间和精力，还没有正常完成需求。

所以，有程序员调侃：代码之外，便是文档。自己不是在了解需求文档的路上，就是在写文档。

在了解需求文档的过程中，还需要不断的和产品经理、前端或后端、领导或客户沟通，而这些都需要花费不少时间

除了要了解需求文档之外，程序员还会自己写文档，因为很多程序员喜欢用文档来沉淀自己的工作，也为方便其他同事利用。

比如：开会、汇报工作

很多程序员说，美好的一天从开会开始。有时候一个上午都在会议中度过，有时下午还要开会。甚至是晚上加班可能也是因为在开会。

对接需求开会、临时改需求开会、修复bug开会、产品上线开会、汇报工作还要开会……

当然汇报工作的方式不仅仅是开会，还有写日报、周报和月报。

不管一天干了多少活，报告必须写好。如果当日代码质量不过关，那就论行数，反正没有功劳也要凸显出自己的苦劳。

另外，字数上也不能输，写了技术再来点心得感悟，凑个上千字应该不成问题。

如果给我一个新项目，我会怎么看？

如何快速上手新项目？

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

1.  获取项目相关信息

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

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

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

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

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

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

2. 了解业务流程

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

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

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

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

3. 阅读项目文档

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

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

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

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

项目文档目录

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

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

Ant Design Pro

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

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

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

4. 先把项目跑起来

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

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

5. 阅读代码

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

• 由整体到局部：先了解整个项目的目录结构，每个目录都是做什么的，比如在哪里写页面？在哪里改配置？在哪里改接口？怎么切换环境等。

  还要了解项目的模块划分，比如哪些代码是用户模块、哪些代码是订单模块，可以通过 JetBrains 等开发工具来自动生成 UML 类图，更清晰地了解。

• 结合业务：读代码的时候尽量不要裸读、按顺序读，而是可以配合系统去定位代码。比如阅读用户登录功能的后端代码时，可以在前端执行一次登录，然后在浏览器 F12 网络请求中找到登录对应的后端请求，再到代码中全局搜索这个请求即可。阅读用户下订单的代码时，可以先在前端模拟一次下单操作，了解整个过程，从而更好地理解请求之间的顺序和依赖关系。

6. 上手开发

最后也是最关键的一点，读代码不能只读代码，一定要多上手去写、去执行、去调试。

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

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