what to do about Procedural code, business logic and queries in PHP

Question

I have been tasked with supporting and maintaining several PHP/MySQL web apps (I use the term 'app' lossely) that seem to defy every known coding standard.

The PHP code contains routines, procedures, business logic, and even queries - it's all in the code. There is no object-orientated programming, not even MVC, and certainly no separation of the presentation layer from the application layer. No framework was used to build these apps either and I am using the Yii Framework for new projects.

Although it's time consuming should I rewrite these applications? At least half my week involves fixing them, doing updates are having to work with these existing apps in my new work.

Anyone have any advice on this?

Answer 1

Will the products last for a long period of time? Will other users see the code and think that you did it? If yes to these, then you might as well rewrite the code. Try and get some support from your company and let them know the benefits and maybe you'll even get noticed for it.

Answer 2

An age old question that is asked alot.

When do you refactor code?

How do you refactor?

How do you stop yourself from refactoring working but awful code?

Basically, if it's working dont' break it. If you work in it, and can make changes to clean up the code without breaking it then do it. Rewrite code? I'd go with the idea of, What's the return of investment, how much time would it take, can you dodge the bugs of the old version without introducing new ones. Things like that.

Good luck with your project, and hope this helps.

Answer 3

I would caution against an all-out rewrite. If the application is working and has users, the path forward is to modify the existing codebase.

Yes, you can implement a framework into an existing framework-less codebase. It takes a lot of effort, but it is possible (I've done this several times). Starting over will cause you to lose precious time. That's been proven time and time again (remember Netscape?)

You're obviously smart enough to know that there is a problem, and to know that the solution is to improve the applications by implementing frameworks and clean them up. That puts you ahead of the game.

Implement new frameworks in phases. Start with an MVC framework - get it into the codebase, but don't fret about the fact that there is no separation of layers yet. Get a new version out that's built on top of an MVC framework but isn't truly obeying MVC conventions. It's a start. Then take a next step - move the business logic into the model layer. Or maybe leave it as it is, but make it OO.

Remember, your job is to produce a product that users can use. Your job is not to adhere to best practices. Meaning - yes, best practices ARE the correct course of action. But they don't matter squat if users can't use your app or your app can't compete with the competition. Don't lose sight of that. Work to improve the app so that you can turn it into a great product, but don't let perfection be the enemy of good.

Answer 4

While having no separation between the presentation layer and bussiness layer is clearly bad, there are some merits with other choices. If it is a pain to maintain code, just refactor the code as you go. Since you are familiar with good design patterns, you should be able do it fairly easily. Moreover, this will also help you reduce the bugs in your code. But remember that while refactoring code, things get worse before they get better. So, don't give up too soon.

Answer 5

In my experiences, this has typically been a business decision. Do your bosses know how much time you spend maintaining these systems? How many users actually use these systems? How critical are they to the business? Can you sell management on a rewrite and can you prove it will be useful and beneficial?

You can start some basic refactoring already in your day-to-day maintenance. Whenever you need to make updates, even if it might take a little extra time, find a way to work an OOP solution of some sort in, or clean up the code that's there to make it easier to handle. All-out rewrites are typically not a good idea and are a hard sell, but if you're already maintaining and adding in new functionality, there's no reason you can't use the new code or fixes to improve what's already there.

Answer 6

I would suggest it depends on how much is the user load on these apps, do they really break apart in live scenarios and how much time are you wasting daily on these fixings and all.

Its always better to rewrite than break head on something which is totally messy.