Returning to An Old Project: Brining the Power of Unit Testing and Refactoring (and rewriting) To Resurrect the Dead


I have a project that stalled.

The project is an iOS app. A fairly simple, really. The app is, more or less, a graphical interface for database (I suppose most apps are some form of this). The app has been around in one form or another for many years, but doesn’t need to be update that often. The truth of the matter the database that i’m using hasn’t been updated in a while because I’ve never gotten around to write an editor. So, the last major release was around 2015.

In late 2015 or so, I had the brilliant idea of porting the app to MacOS. After all, I eventually need an editor. A twist in that idea was the app would be 100% written in Swift, if possible. The iOS version was written in Objective-C.

It turned out the transition went well. I released the MacOS version in 2016.

It went wrong when I decided it was time to unify the code base of the apps as much as possible. In other words, the iOS app had to move to Swift too. Why? Well, I got a job and this particular app was a relatively low priority.

Fast forward to 2018. I decided that it was time to expand the things I do at work. Thus, I decided to become a Test-Driven Development (TDD) instructor (in training at least). So naturally, I decided to find a relatively small project that I can apply my (limited) TDD chops.

It is time to revisit my Devonian Database iOS and MacOS apps. These apps are available for free on the different App Stores.

The iOS app been in the app store for many years, and I managed to get the last version out in 2015 or 2016. I fixed it up and released as part of a job hunt: have a good working app in the store to prove I can do the work. As part of that effort, though, I decided to release the Mac version of the same app. Cleaver me decided to make this new version entirely swift: no Objective-C code at all. That app was successfully released too.

What got me was the next decision: make my iOS app Swift only as well. The decision made sense, and still does. Minimize the code base and both apps are easier to maintain. While Objective-C is still a powerful language, Swift is an easier language to use (with the exceptions of occasional major changes to the languages and the difficulties in testing and Objective-C interoperability). But it takes time and energy. I got the job and the app fell by the wayside.

I started looking at the app again and it’s a mess. For most developers, looking at your old code is a cringe-worthy experience. Now that I work on a team, I find my old code has one fatal flaw: it was written for me… The problem with “written for me” that that the me of today has no idea what the me of 2015 was thinking. I wrote things quickly. I wrote things using simple and convenient design patterns instead of something that would be more appropriate. I did write a few unit tests (or in many cases integration tests pretending to be unit tests), but they were few and far between and written at a time where I really didn’t understand how to write good Swift tests. Not to mention many didn’t work at all.

So, my first few hours will be spent looking at the core of the app - the database management code. I’ll blog the results of this work.

, styled with lin.css