开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
今日推荐开源项目:《新年初战 interview》
今日推荐英文原文:《A guide to tackling huge codebases》
2019年2月2日:开源日报第331期
今日推荐开源项目:《新年初战 interview》传送门:GitHub链接
推荐理由:项目作者的亲身面试经历,包括各种各样的细节和面试问题,如果希望感受一下真实面试是什么样的问法的话可以来看一看。当然了,看完之后发现自己还需要更加努力的话,就在新的一年里打起精神来努力学习刷经验吧。
今日推荐英文原文:《A guide to tackling huge codebases》作者:Cyril Pillai
原文链接:https://blog.gojekengineering.com/a-guide-to-tackling-huge-codebases-326977406abf
推荐理由:兴许有一天当你加入别的项目的时候,你也会看到巨大的代码库

A guide to tackling huge codebases

I recently joined GOJEK as a Product Engineer as part of the GO-LOGISTICS team. I’ve been doing Android Development for over four years, but when I first ‘git pulled’ GoHost (the monorepo for the Android consumer app), I was intimidated by the codebase. I have worked with codebases that had four to five contributors, but this was a different beast altogether.

80+ modules, 20+ active contributors, ~20 mins for a clean build, and different coding styles/architectures in different modules. Product modules are owned by the respective teams and thus they have the liberty to choose what works best for them.

On an unrelated note, codebases are the stuff of folklore at GOJEK. When we launched our app in 2015, all our backend services depended on a legacy codebase named after a South Park character, Stan Marsh. As GOJEK grew, Stan Marsh buckled under the strain. We eventually pulled all its functionality into discrete microservices. Nevertheless, the legacy of Stan Marsh lives on.

I was lucky enough to have access to some of the developers who oversaw the transition from Stan Marsh, and gained a lot of insights. This post pens down my learnings from the last few months on how to deal with huge codebases.

You can’t understand everything

2019年2月2日:开源日报第331期

This is the hardest thing of all.

All of the previous codebases I’ve worked on/owned had one thing in common — I knew everything, about everything. The legacy ones I inherited took some time and effort but eventually I used to get well-versed with the entire system.

I tried that approach here and failed miserably. Initially, I was responsible for a single module (GO-SEND product) out of the 80+ modules. These modules included other products (GO-RIDE, GO-FOOD, GO-TIX etc.), libraries/utilities, SDKs for the products, and product agnostic core/platform code.

After a few days of diving in the ocean of code and sinking every time, I got frustrated and talked to my Mobile Lead about this.

Talking to him made me realise that no one in the entire org knows everything about the system.

The key takeaway here is to understand the parts you own or would work on, and be oblivious to other moving parts. Changes are being made to the codebase on an hourly basis, and it’s humanly impossible to keep track of everything.

Get familiar with the architecture of the codebase

Now, when I say be oblivious, I don’t mean everything. It’s a mandatory process to dive into the ocean and sink, but you need to know when to stop. Try to familiarise yourself with the skeleton of the codebase. Read code from modules that make up the core of the system (platform code that is independent of the products), and understand how your module interacts with that code. Dig into SDKs and internal libraries that abstract certain third party dependencies, so that the product modules aren’t affected by future changes.

Have a specific goal in mind before you dive

It’s important to have a reason to dive into the ocean, and to have a well-defined task to finish and get out (because time ticks 🕒). If you don’t have any task, ask your team members to assign you something. It’s better to get up from the chair feeling good about completing something. Definitely beats getting lost in the gigantic world of programming constructs.

Read code thoroughly, don’t break anything

Let’s acknowledge that we developers can be a bit narcissistic about code. We love writing code but reading it bores us to death. Even if we trick our minds into reading someone else’s code, there is usually an urge to rewrite it. The best thing to do here is to be objective and follow one of GOJEK’s guiding principles:
“Every decision is correct at the time it is made”
Spend ample time reading the code and critically evaluate the consequences your changes might have before proceeding.

Follow the coding style of the file you are editing

This is to ensure that your changes don’t look out of place, and are aligned with the surrounding environment. It’s super important to maintain consistency no matter how outdated something feels.

Assume you need to change the filtering condition in a file:

What!! This class is still using RxJava 1.0. 😱

Option 1 Option 2

Talk to other devs

Rockstar developer / coding ninja / 10Xer / one man army / everyone is inferior to me / I like working alone / others are stupid.

If you relate to anyone of the above things, you need to change. Can you build systems single handedly? Yes. But to make scalable solutions and improve yourself, it’s important to throw your ego out of the window. Be liberal and collaborate with others.

Coincidentally, this also helps in dealing with huge codebases. Talk to other developers who have worked on the piece of code you’re concerned with. To get more context, ask about the rationale behind the decisions made and the implications new changes would have. Be open to suggestions on the way you should approach the problem.

Improve it

  • Make the codebase a bit stronger than it previously was by making sure that changes you make are supported by tests.

  • Refactor wherever NECESSARY.

  • Document decisions/assumptions/hacks to make sure the information is present somewhere (apart from the head of an engineer).


下载开源日报APP:https://openingsource.org/2579/
加入我们:https://openingsource.org/about/join/
关注我们:https://openingsource.org/about/love/