TAG | Refactoring
Reading this blog chances are that you are a developer. Chances are also you know that I used to be one too but changed sides. Hopefully you are keen to learn what there is in the business world that relates to yours.
Like a management buy-out (MBO).
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.
Todays post I was actually meant to give on this years FrOSCon which sadly I had to cancel as I have been engaged business-wise at that time.. Anyway the idea remained and it might inspire some of you to get a new access to refactoring legacy systems.
With Symfony of course.
Recently working on ImageTransform I decided to do a big refactoring during which I had to move around a lot of classes as I reorganised the folder structure. This of course includes changing a lot of namespaces.
Usually something like this would drag a lot of work behind. Unless..
What I called my “little experience” during the last two days is actually the attempt to rewrite the image manipulation library ImageTransform by Stuart Lowes, which itself is the attempt to turn the symfony plugin sfImageTransformPlugin into a standalone library (unfinished). It’s not at all official and it might be binned again at some point. Until I know that it stays my personal toy.
One of the goals I set myself is to make the code as decoupled as possible and to prove that I try to maintain a high unit test coverage.
Usually the answer is a misconfiguration but sometimes of course they found one of the bugs I involuntarily put in the code.
In these cases I have to get down at the code level and try to fix it. This is how I usually do it.
An just to make sure there are no misunderstandings: I am not about to question TDD!
I am merely asking for help to find my way to do it properly..
I keep propagating separation of concerns, modularity and decoupling and from all the discussions I had and all the books and blog posts I’ve read I haven’t discovered but one single reason against this.
The reason is simple and powerful: performance.
Performance they will suffer if you keep your components abstract and independent. The more you couple the more you can optimise the speed of execution.
This is in most cases actually true. On the long scale however..
So you’re thinking of reusing your code, huh? This can be quite tricky. Reusing software is considered by many to be one of the great myths of software engineering. Still I am convinced that it is possible.
However there are several approaches to this but not all of them have a good chance to succeed.
Using symfonys functional testing classes this is actually quite easy to do.
But wouldn’t it be cool if you could integrate these tests into your continuous integration service just like PHPUnit tests? Wouldn’t it be cool to be able to generate PHPUnit coverage reports?