How to Adapt to a New Team's Codebase: A Process of Making the Code My Own

A 5-year game server developer in charge of the Cookie Run: Witch's Castle server at Devsisters shares how they adapted to a completely different codebase.

Previously they worked in an object-oriented environment based on C#, but on the new team they had to learn Scala and ZIO for the first time, along with hexagonal architecture and DDD. Since they had to learn on their own, the difficulty was even higher, but they spent about 1 week learning the syntax and framework, then 3 weeks internalizing the code by carrying out actual quests.

The learning order had three stages.

• Syntax learning: Learning basic Scala syntax and functional concepts
• Framework learning: Understanding the structure and behavior of ZIO used in server development
• Commercial code analysis: Building experience through actual production code and small quests

In the early stage, they dug into the SignIn feature first, learning the flow of running the server, local compilation, and debugging. Afterward, with the login reward feature, they practiced handling side effects in the functional paradigm using liftEvent, and through gRPC work they understood how to wrap println with zio.succeed and the type consistency of for expressions.

Through operational logging work, they also learned the importance of logs, the analytics log class hierarchy, and event occurrence patterns. Progressing from small ad system features to larger tasks like the Cookie Puzzle Challenge and the Ruins Exploration Event, they gained a full grasp of the codebase's overall flow, and now say they are familiar enough to even write the team's guide documents.

The biggest difficulties were the functional paradigm, complex Scala syntax, and lack of documentation. However, organizing the cause themselves before asking questions led to better answers, and code reviews and feedback with teammates, as well as communication with other job functions, sped up the adaptation.

Finally, they summarize that there are two ways to adapt to a team. If there is time, the standard approach is to thoroughly learn the language and architecture first, then proceed with small features. If quick contribution is needed, one must learn the project and the language simultaneously. Either way, they emphasize that not stopping at mere team adaptation, but continuously digging into the project structure and theoretical background, is what leads to growth.