TAG | Separation of Concerns
Developers tend to hate legacy code. It’s messy and inflexible and no fun to work with. Most of the time that’s a direct result of quick and dirty work so it seems logical to aim for building sustainable high quality code instead so that the code last for long without becoming a burden.
Only sometimes the long run doesn’t matter.
In one of the projects I’m involved in we have daily status meetings where we update each other on our progress. Every now and then a technical detail is mentioned that can only be described as a workaround. A typical quote on this would be:
Of course this wasn’t originally supposed to be used like this.
It’s been a while since I wrote my first line of code. Years later I went to university to learn how to code properly. I did learn a lot at that time but most of what I know today I learned through years of experience.
But I’m convinced that the most essential lessons I learned could be taught in a dedicated subject.
On the 1st of June Hamburg based code experts mindworks GmbH have started a cool new contest asking people to tweat best practices for PHP #PHPbp to win a cool gadget (post is in German).
The title of this post is my contribution to it.
Yesterday I had this idea about doing a conference talk about decoupled code from a clients perspective. Maybe other things too. Because when something matters to the client it should matter to you too.
Here’s a start.
Sometimes a situation can seem like there is no way out and no way back. Especially in IT you can see legacy systems in a state where the only solution you can think of is doing it again.
It’s like a game of pick-a-stick.
We have a large website and a quite big team of developers working almost entirely on it. We’ve got legacy code but good people. We’ve got load tests and mostly stable deployment processes. We’ve got syndication feeds that many mobile applications depend on.
And changes take ages..
Separation of Concerns is by far the most important design principle in coding as it is the key that helps you to deal with complexity.
Not it is not limited to code alone.
You’ve probably been there as well. You said: Lets build a software that we use for all our clients. A big do-it-all CMS or similar. With every client project your software grows and gains cool features. New features that are attractive also to old clients.
They both use the same software but how can you get from one point in time to the other?
Some of you might have attended Symfony Day 2011 in Cologne two weeks ago where together with Stefan Koopmanschap I gave a talk about Catching Opportunities with Open Source. which we got an amazing feedback for.
As our talk was basically a series of small stories and anecdotes there is not much point to publish our notes. But the discussions we had afterwards on the conference and on twitter inspired me to write a small series of Open Source articles.