Let’s imagine a situation, where you have just joined a new software company that has been working on a product for the past couple of years. The codebase is large and complicated, but nonetheless you are expected to contribute to it almost from day one. You clone the repo and spend hours, days or even weeks perusing the code, trying to build ever more complicated models in your head to get gradually closer to understanding what the heck is going on. That’s probably not the most beneficial way of spending your time and also a sign, that mentoring and knowledge sharing is not at the top of the agenda at your new workplace.
I had the pleasure of giving a talk on Clean Architecture at the February edition of Copenhagen Cocoa. The slides for the talk can be found here:
There is also a sample project, which accompanies the talk. It shows how Clean Architecture can be used to implement a single screen in an iOS application:
Today, while going through my regular routine of reading up on what’s new in Swift, I stumbled upon the problem of rotating an array by a given number of positions. This is something I haven’t done in Swift before, and it seemed like a good problem to brush up on my coding skills. Let’s have a look at how things played out.
A few months ago I stumbled upon a blog post by Robert C. Martin entitled “The Clean Architecture”. The author demonstrates how classes can be divided into layers, depending on how central they are to the problem at hand, thus leading to better separation of concerns and modularity. I think that the ideas presented in the article are really valuable, and would therefore like to share my thoughts on how they might apply to the platform I deal with most of the time, which is iOS.
If I was to name one of the tasks a software developer is least excited about, it would probably be maintaining a “smelly” codebase. Imagine a five-year-old piece of software written by an inexperienced developer on a very tight schedule. It’s not a pretty sight and most of us wouldn’t even want to touch this code with a stick. To make matters worse, requirements changed over the years and new features were added on top of a very fragile foundation. Not by the original developers, but by new ones, who made progress by poking a black box and measuring the response.
Unfortunately situations like the one described above are quite common. Especially at companies working on multiple projects for multiple different clients, where developers jump from one codebase to another. That is where code quality is of uttermost importance and writing well structured and easy-to-understand software makes a quickly discernible difference. But where do we start? How can we make sure that our colleagues get positively surprised when they inherit a codebase we’ve been working on?
I have been working recently on a Xamarin.iOS application for managing events. One of the application’s interesting and challenging features is the way it displays multiple lists of events with the help of some relatively advanced, but intuitive UI. This is what the homepage of the app looks like:
I gave a talk on “Cross platform mobile development with Xamarin” at the June edition of CocoaHeads Copenhagen. The event was hosted by Trifork. Here are the slides: