-3

I'm in dire need of some help. My background is from python, js and ruby, with using frameworks to provide good structure.

A potential client has an internal app which does quite a bit of stuff. This means there are multiple functions, and a lot of code. The project is written in php, which I don't have much knowledge about.

They want more features!

The app was written by a former employee. He is unavailable and the code base is not documented. I've started looking at the files, and apart from being structured in different folders, there is a major lack of it.

The code itself mixes SQL-queries, logic and html in the same blocks of code. There are tons long if / else if statements, and as far as I am concerned, noone has ever thought about restructuring and refactoring, it just looks like patches sewn on again, and again, and again. It's all vanilla php. The app is also communicating with a printer. I have not figured out where or how it does that.

This app belongs to a company in growth. And it looks like more companies in the same building will be using it as well.

As I can see it, I have two options.

  1. Lock myself inside a room, get it under version control, and go through every single line of code and try to figure out what it does, till I get to a point where I'm able to refactor and write new, maintainable features on top of it. Hopefully I won't kringe to death.

  2. Write a new app the proper way. Get all specs from the client, and use newer, and better technologies than vanilla php. I'm thinking maybe a MERN-stack for a snappy experience. Maybe write the printer functionality in python, if JS won't cut it.

Because the client wants the ability to scale the app, I believe a full rewrite is the best way to go about this.

In regard of my lacking php skills, I don't think I'll do the job without the rewrite. From my experience reading code in multiple languages, I don't believe anyone else is going to touch this code base either.

Does anyone have any experience with this type of dilemma?

Stephan Bakkelund Valois
  • 101
  • 2
  • 1
    The way you describe it, the specs from the client's perspective are most likely "it should work like the existing app". Which brings you back to square one. Whether you try to extend (and incrementally clean up) the old app or write a replacement from scratch, you will have to dive into the code and understand it. Your best bet is to use tools which support this well. The alternative would be to tell the client that they can get a new app from you if they give you specs, and then you lose the client... – Hans-Martin Mosner Jun 25 '20 at 06:26

1 Answers1

1

As I can see it, I have two options.

You don't. You only have one.

Even if you decide on a full rewrite in a different tech stack, you won't accomplish that if you don't fully understand the old project and its (many, as I understand) quirks.

It’s important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time.

That statement is as true today as it was 20 years ago. If you decide on a rewrite, you will make the same mistakes your predecessors made. Introduce the same bugs. Experience the same scope creep as the same old new features are requested well into the project's lifecycle.

Instead, first focus your efforts on discovery and documentation. Find out what the old project does, how, and why. Write tests. If you're leaning towards a new tech stack, find a testing framework that's largely language-agnostic, so your tests will still be usable after the rewrite.

Only after all that will you have a few options:

  • Refactor. The old code might not be as bad. Update to the latest version of PHP, find a suitable framework to aid in development, and start pulling the code apart. Untangle logic and presentation until you're left with an HTTP API in PHP and a fully Javascript-powered frontend.

  • Rewrite. If after all this, you still feel the project is too far outside your comfort zone, seek approval for a rewrite. Only now, you've got most of the specifications solidified in tests, which means a mostly Test-Driven Development approach is now an easy route to take. You've got a grasp on what the project requires, and might be able to prevent some repetition of history.

Duroth
  • 880
  • 4
  • 10
  • That article you've linked to was a pretty good read. And of course, if I untangle the code and manage to divide the app into an api and a front end, that would be great. I think I'll spend some more time reading the code base before I make a decision. – Stephan Bakkelund Valois Jun 25 '20 at 06:42
  • +++ to writing tests. Especially when deciphering foreign code, tests serve as a vehicle to check whether your understanding of the code matches its behaviour. With some coverage analysis added, you will also get to know which parts you don't test and don't understand yet. – Hans-Martin Mosner Jun 25 '20 at 13:10