Refactoring Code To Psr standard and making the code testable in Laravel 4

Question

When i started making a mobile app (that uses laravel on the server) i decided to not dig into testing or coding standards as i thought it was better to actually get a working app first.

A few months later i have a working app but my code doesn't follow any standards and nor have i written any tests.

Current directory structure i'm using is:

app/controllers : Contains all the controllers the app uses. The controllers aren't exactly thin, they contain most of the logic and some of them even have multiple conditional statements (if/else). All the database interactions occur in the controllers.

app/models : Define relationships with other models and contain certain functions relative to the particular model eg. A validate function.

app/libraries : contain custom helper functions.

app/database : contains the migrations and seeds.

My app is currently working and the reason for the slack is probably because i work alone on the app.

My concerns:

1. Should i go ahead and release the app and then see if its even worth making the effort to refactor or should i first refactor.

2. I do wish to refactor the code but i'm unsure on as to what approach i should take. Should i first get the standards right and then make my code testable? Or should i not worry about standards( and continue using classmap to autoload) and just try and make my code testable?

3. How should i structure my files?

4. Where should i place interfaces,abstract classes etc?

Note: I am digging into testing and coding standards from whatever resources i can find, but if you guys could point me to some resource i would appreciate it.

Answer 1

Oh dear. Classic definition of legacy code, is code with no unit tests. So now you are in that unfortunate position where, if you are ever going to have to amend/enhance/resuse this code base, you are going to have to absorb a significant cost. The further away from your current implementation you get, the higher that cost is going to get. That's called technical debt. Having testable code doesn't get rid of it though, it simply reduces the interest rate.

Should you do it? Well if you release now, and it achieves some popularity and therefore need to do more to it...

If it's going to be received with total indifference or screams of dismay, then there's no point in releasing it at all, in fact that would be counter-productive.

Should you choose to carry on with the code base, I can't see any efficient way to re-factor for a coding standard without a unit test to prove you haven't broken the app in doing so. If you find a coding standard where testable and tested aren't a key part of it, ignore it, it's drivel.

Of course you still have the problem of how do you change code to make it testable without breaking it. I suspect you can iterate towards that with say delegation in your fat controllers without too much of a difficulty. Two key points. Have at least some test first, even if it's a wholly manual one, say a printout of the web page before you do anything. A set of integration tests, perhaps using an automation suite would be very useful, especially if you already have a coupling problem.

The other is, don't make too many changes at once and by too many I mean how many operations in the app will be affected by this code.

Robert C Martin's (no affiliation whatsoever) Working With Legacy Code would be a good purchase if you want to learn more.

Hopefully this lesson has already been learnt. Don't do this again.

Last but not least doing this sort of exercise is a great learning experience, rest assured you will run into situations (lots of them) where this perennial mistake has been made.