Have you ever realized that developers are never happy with the legacy code?
The definition of "legacy code" may vary:
- code inherited from the previous developers of your company
- code that doesn't have test suites
- code that is older that 10 minutes (...)
We all rarely find good code when joining a company, weird uh? Some reasons why good code is so hard to find can be:
- the developer that worked on the code was good but couldn't care less about doing things properly
- the developer that worked on the code was simply unexperienced and created bizzare things
- the developer that worked on the code was terrible at architecture design
- too many developers worked on the same code without understanding what was already been done
- code was not developed using the black box approach and without reusability in mind
All points but last are summarized here:
Since I'm Italian and I don't go easy with my temper and my personal definition is simply:
Legacy code is code that sucks
Who knows me, knows that I'm fond of design and architecture; I'm not discussing the third point, here I'll elaborate on the last one.
What I've always tried to do, among other things, while working in the different companies in my career is to develop reusable code. Let's call a bit of reusable code a 'component'. As you may guess, developing small pieces of reusable code always pays off and it turns out to be a great time saving in future.
As an iOS developer I have tasks to do on a daily basis. Some of them are boring, others are challeging. Even if a task is boring I try to find the fun of it, identifying what can be reused and code it at my best. Sometimes it might be just a minor UI component, sometimes larger pieces of logic.
Usually it's good to know in advance if you aim to create a component along the journey of the task you're working on rather then realizing later that something could have been 'componentized'. This also dictates how goodly you focus on the development of the component.
Here comes the cool part: once you got a nice piece of self-contained code you might yearn to release it open source! This is the thing I love the most of the process because it makes me feel like I'm closing the circle.
Having a component open sourced has some nice side effects:
- you get feedback (appreciation or criticism) from the community
- you get pull requests/bug fixes from the community
- it raises the image of the company for what regards the technologies used
For instance, at Beamly (the company I'm working at now) we are doing cool things and we have released 3 components so far:
the process I used is like so:
- identify a yet-to-be-written piece of code that can be reused
- create a new projects and start coding it in isolation
- if possible, test it
- create a demo app for the component
- go back to the main project and add the component as a development pod (you can read more about development pods in my previous article "CocoaPods: Working With Internal Pods Without Hassle")
- if some fine tuning is needed, act accordingly on the development pod
- open source it and make it available on CocoaPods
Going this way while developing, you focus only on the component. In the end, the understanding of an isolated component is greater that the rest of the boilerplate for you and for the developers after you.
So, back to the original point: think of joining a company where everything is reusable, pluggable like ruby gems or cocoa pods. This doesn't necessarily implies that the quality is good whatsoever, but for sure you'd complain less about the legacy code you have to deal with.