Live data from Hacker News

Ask HN: I just inherited 700K+ lines of bad PHP. Advice?

news.ycombinator.com

11–20 of 78 posts

Re: Ask HN: I just inherited 700K+ lines of bad PHP. Advice?

#11
So the cold reality for this client is that the codebase will have to be replaced over time. You are not trying to escape legacy simply for the lure of something new, you are trying to escape insanity.

I would talk to the client about focusing your effort on helping them transition--a small piece at time--to a sane architecture. If they aren't open to that, they aren't your client. I've been a business leader in a position where we had to make really tough and painful decisions about coding projects gone awry. I don't envy their position, but continuing forward with this monster does not seem to be in the long-term interests of the company.

Re: Ask HN: I just inherited 700K+ lines of bad PHP. Advice?

#12
But what do you have to do with that? Is it maintenance? Do you need to fix bugs?

If it's maintenance/bug fix, I'd suggest starting by writing tests and fixing things on a day to day basis.

So, for all small tasks that you'll have to do with the code base, just analyse the safest way to tweak it. Most often than not, you'll see that it's just changing a couple lines. If you need to add new features, just code them correctly in another part of the program.

And before you know, you'll understand the code-base. But, tests are really the most important thing here. Don't try to refactor if you can't make sure you're not breaking everything.

Re: Ask HN: I just inherited 700K+ lines of bad PHP. Advice?

#14
What is most important is what are you trying to achieve. Are you trying to make the system as stable as possible at the lowest cost to the client or are you trying to bring this system into a future proof state and the client is willing to pay for that?

Personally if I were in your position I would explain to the client that I'm happy to temporarily fix some bugs but long term the system needs to be rewritten. 700k lines of code is a lot, but the way you've described it I get the feeling most of that code is needless. Depending on what the system actually does you could conceivably rebuild in a few months.

Re: Ask HN: I just inherited 700K+ lines of bad PHP. Advice?

#16

So the cold reality for this client is that the codebase will have to be replaced over time. You are not trying to escape legacy simply for the lure of something new, you are trying to escape insanity. I would talk to the client about focusing your effort on helping them transition--a small piece at time--to a sane architecture. If they aren't open to that, they aren't your client. I've been a business leader in a po…

[deleted]

Re: Ask HN: I just inherited 700K+ lines of bad PHP. Advice?

#18
I started writing some suggestions but you know what - someone is dumping this on you because they didn't care and their predecessors didn't care, etc. They probably make far more than you for doing far less.

The moment you start touching the code, you are going to start being blamed for the nightmare preceding you. It could even affect your career if future employment researches where you worked previously and gets told you made the mess in the first place.

Re: Ask HN: I just inherited 700K+ lines of bad PHP. Advice?

#20
This might sound sacreligious to the many vim fans here, but get a good IDE, it will help you get a handle on what the code is doing and let you navigate around faster, which is especially handy if the execution path for accomplishing any one thing involves dozens of files. A good IDE will also point out blatant errors, and a really good IDE will point out potential errors as well. I personally really like PHPStorm by JetBrains, the code inspection tool is quite good. I was recently able to cut the size of our code base in half by using it to identify tens of thousands of bugs, a lot of them on inspection were "this never worked" type bugs, which with a little digging I was able to confirm could never be called. Eliminating code also makes refactoring the remaining code easier because you have fewer interdependencies to worry about.
Post reply on HN