想必在很多程序员的职业生涯中，都有过一种难以避免的状况，即接下别人的代码。而这是种怎样的体验？有人说，接手别人的代码之后我也想辞职；有人说，一个连注释都没有的代码有何灵魂可言；更有网友说，如果你恨一个人，就让他接手别人的代码吧......

因此，在我们面对别人遗留下来的代码时，究竟该如何处理？

作者 | Eric Stiens

译文

最近，我找到了一份新工作，结果却发现自己又一次身处相同的漩涡：接手一个陌生的大型代码库，我不知道这些代码建立的初衷，也不明白编写代码的背景。

我不知道哪些代码存在已知的问题，团队中的其他开发掌管哪些代码，哪些代码需要重构，而哪些代码可能永远也不会被触碰。这完全是一个未知的领域，而且四周危机四伏。

在本文中，我将分享一些关于如何接手一个陌生代码库，并为团队做出贡献的经验。

01

搭建开发环境

首先搭建好应用程序的开发环境：安装依赖项，初始化数据库、配置网络连接等。一般来说，这些工作都不会一帆风顺。每个应用的背后都有一群开发人员，他们很难把每一个小窍门都烂熟于心。所以要注意做好笔记。你需要把一切不能按预期工作的问题都记录下来。无法正确地安装代码库的依赖项？记录下来。无法初始化数据库？记录下来。初始化的用户都密码跟README中的密码不一致？记录下来。这是你发挥作用的第一步！缺乏知识就是你的优势，因为这些问题都凸显了文档和构建脚本的缺陷。所以抓住这次机会。对于开发团队来说，能够通过可靠的手段搭建应用程序环境也是一项艰巨的任务，虽然这项任务经常被人忽略。你可以让团队再次注意到这些问题。

02

保持谦虚

毫无疑问，你会觉得有些代码写得很糟糕。有些代码太过于取巧或太简单。有些代码没有经过充分的测试。有些代码过于冗长。有些代码有严重的耦合。你可能想立即重构。

几个月后，你看自己的代码时也会有同样的感受。

人们在重重约束下，尽其所能编写了这些代码。想必这些代码完成了一些功能，而且现在你接手了这些代码。有一天，有人会在不了解上下文的情况下看到你写的代码，他们可能也会觉得你的代码很糟。

所以，你不应该这样想。你应该用初学者的心态，想法改进这些代码，就像我们在第1条中提到的那样，缺乏知识就是你的优势。你不像其他的团队成员，他们在这个应用程序上工作了数月或数年，所以你没有他们那样的偏见，也没有盲点。对你来说，一切都很新鲜。但是你也没有足够的背景知识下结论，所以不要总觉得自己能够写出更好的代码！ 

03

黄金通道

找到应用程序中关键的一个功能。只需一个。这可以是关键的索引视图或API端点。也可以是一个能完成很多功能的函数。然后，你需要找到一个测试，测试通往端点的黄金通道（在这个过程中，请暂时忽略其他干扰因素，比如辅助函数、错误处理、语法等）。如果没有这样的测试，你可以自己写一个（请参照第4条）。

接下来，运行这个测试，并反向追踪。找到输出，通过阅读代码和调试技术找到输入。然后将这些输入作为输出，再找下一个输入，以此类推。提醒自己这只是一道非常复杂的逻辑难题。这中间没有任何神秘的事情发生。一切都按部就班。任何输出都不会凭空产生（请忽略库、元编程、以及大量的依赖关系……这些只会让手头的代码更为复杂，但它们也只是更多的代码而已……）

04

写测试

在了解现有代码库时，不引入任何错误，同时还能帮助你学习的一个好办法就是测试文档记载的现有功能。测试覆盖范围因具体情况而异。对于大多数开发团队来说，单元测试是理想的选择，但随着你深入了解更高层的抽象，覆盖范围会变得更加模糊。你可以通过编写良好的集成规范来简单记录已经完成的工作。在搞清楚你测试的这些行为背后的驱动因素后，就可以了解到大量的代码。你可以帮助自己和其他人今后更容易地重构代码，而且你不会破坏任何代码，除了可能会改动部分测试代码之外！

05

大量阅读

大量阅读。不仅仅是代码——你迟早都要熟知代码。阅读Slack过往的聊天记录。阅读提交消息。阅读PR中的注释。阅读数据库结构。阅读事故报告。阅读文档以及文档的修改记录。不要认为这些工作没有意义。你应该像一块海绵，吸收所有的背景知识，即便目前你一头雾水，也无需担心。你还没有正式开始工作，所以只需不断收集零落在各个角落的故事，坚持一周或一个月你就会有所眉目。用直觉去感受大量的上下文，稍后就会有所帮助。

06

结对编程

请求别人和你结对编程。即便没有人结对。即便你害怕结对。即便只有20分钟。当别人在编写代码的时候，坐在一旁观看，即便这些代码目前你还用不到。要求与别人结对编程，即便他们不太了解你需要修改的那部分代码。团队中的每个人都积攒了大量的重要知识。这一个阶段的工作是让他们尽可能地将这知识传输给你。通常，你只需坐在一旁看他们写代码以及浏览代码，就可以吸收大量信息，同时还可以帮助别人找出代码中的拼写错误。

07

提问

积极提问。不要在乎哪些问题太白痴。你的问题很重要，因为这些问题可能揭示了当前团队没有意识到的一些问题。你的问题很重要，因为你不必知道一切。既然你已经被录取了，面试已经结束了，那么你就是团队的一员，优秀的开发团队应该互相帮助，没有人会有优越感。

08

一位优秀的经理/项目经理

这一点上你可能无能为力（除非你本人就是经理），但如果你的确是团队经理的话，则需要分配给新来的开发人员一些简单的任务。一般来说，这些都不是关键性的任务，而且也许新成员会犯错。这些任务应该是简单的功能或改bug，而且还应该让新成员接触到尽可能多的代码。理想情况下，你应该确切地知道这些任务需要修改哪部分代码，但你只能给出一些提示，比如：

“我感觉有一些奇怪的nil值以某种方式传递到了这个方法中，你可以看看X类和Y类，我感觉这两个类可能漏掉了某处错误，然后不知怎地传递了错误的数据。”

09

澄清需求并寻求帮助

在第一次修改代码的时候，你需要搞清楚具体的需求。首先应该确保大家的理解没有偏差。如果你在某个任务上花费的时间超出了预想，则应该立即重新讨论。寻求帮助，你没有责任理解所有的代码，每个人都有责任帮助你步入正常的工作。

“我认为我应该修改这个视图，所以整个下午我都在看X和Y，但还是没搞清楚这个值从哪儿来的，你可不可以花半个小时看看这段代码，然后帮我搞清楚问题所在？”

你可以表现出自己的弱势，在团队成员的帮助下学习，这有助于提高团队的指导水平，而且教学互长，在向你解释代码的过程，他们也可以加深对代码的理解。

在向别人解释代码的时候，你完全可以说：“我……不太清楚这个方法，但我们应该修复这个问题。”

10

放松心情

有人雇佣你或让你参与某个项目，是因为人们相信你，而不是为了考验的你的编程技术有多烂。适应陌生的代码库需要一定的时间。有时候，还需要很多时间。但说到底也只是一些代码，而作为开发你自然很懂代码。虽然你可能还不熟悉眼前的代码，但你也可以利用适应的过程为团队创造价值。你要保持耐心、谦虚，同时还要密切关注大局，不要害怕花时间深入了解某个特定的功能。

原文：

https://medium.com/@ericstiens/10-thoughts-on-orienting-yourself-in-a-new-codebase-2c2e9f443de2

本文为CSDN翻译

作者 | Eric Stiens

译者 | 弯月