Code Archeology - Avoiding the Quicksands of a Legacy Codebase

Last updated: 19 days ago

Engineers love to work with the newest technologies introduced at WWDC. In reality, when you start a new job and dive into an existing project, changing a line written by someone else can break things. The Talk is about dealing with legacy code and not being scared by files which are 8000 lines long.

When Apple announces a new framework at WWDC it is welcomed with tremendous applause. Core ML or ARKit were and still are what many developers crave to try out in their projects. On a daily basis, we engineers may encounter slightly different problems.

Many of us work with the code that somebody has written in the past. Due to our limited perception and limited ability to predict the actual execution of a program after changing a line of code, we don't know what the ripple effect of the change will be. Sometimes you need to do an archaeological dig on the codebase to understand how the code works. If you find a Chinese vase from the Ming dynasty you don't want to break it. The same applies to the application you work on.

This talk will be about the importance of writing unit tests when there are none for legacy codebases. Unit tests help preserve the artifacts discovered during an archaeological dig through the code. I will present a TDD approach to building new features on top of the legacy code. I will share tips and tricks related to refactoring and dealing with problems I have experienced when working in a multi-language project that uses Objective-C, Objective-C++ and Swift on top of that.