Work easier, not harder: A developer’s journey to doing as little work as possible
When designing an iOS app for one of our APIs, we like to make a Swift class for the response data to make it easier to work with. These classes follow the same pattern every time: An initializer function that parses the returned dictionary into the class variables, an isEqualTo function to compare two objects, and a toJSON function that takes the object and puts it back into a dictionary so it can be sent back to the API. While I was working on writing up a class for our new project I was wishing there was some way I could take our JSON model and turn it into a Swift class. After all, we already had an example JSON object written up and the class was suppose to match that.
Luckily enough, Lab Day was the next work day. I had always wanted to write code that writes code since it just sounds kind of silly. I took this opportunity to solve my problem of repetitive code.
So then came the fun part: actually writing code to write code. I created an array to store all of the strings I would later output. I looked back at some of my old code that I would try to emulate to see how I should proceed. It turns out the code follows a very simple pattern of a few lines of either starting or ending a block of code, followed by a chunk of lines, one for each variable. So the code I wrote followed a similar structure: Adding a few lines to the array to end one function and begin another and then going through a for loop to do something with each of the variables.
By lunchtime I was able get a working prototype that could take a simple JSON object and turn it into a single Swift class. That was great, but it wasn’t very feasible to actually use. The objects we would normally be receiving contain arrays, and objects, and arrays of objects. Handling these types of objects would be an extra challenge.
Lastly, if I was dealing with some type of object, I needed to recursively call this function so the new object’s Swift class could be created.
I didn’t get the output I wanted on my first try, which led to some really interesting debugging. If you have an extra && at the end of a long condition in an if statement, it is an easy fix. All you do is delete it. But when the error actually lies in another code, things get a little trickier. Trying to think through where my error was and what I needed to change was a fun challenge.
It was really interesting working on this project. Being one step removed from the code you wanted to end up with made me think about coding in a different way. If you want to check out the code or use it for yourself, you can find it here on Github.