How do you keep control in a large software project? [duplicate]

Question

This question already exists:

How to manage a relatively large one-man project? [duplicate]

Closed 5 years ago.

I've a large-ish software project that I'm the sole developer for (~80KLOCS and counting - I know there are much larger projects out there, but it's an order of magnitude larger than I've ever had to deal with before).

If it's relevant, the code is split between PHP and JavaScript. I'd guess about a third of it was JS, about two thirds is PHP; I expect that over time, the size of the JavaScript will outgrow the size of the PHP.

I'm starting to get to the situation where, occasionally, the odd part of it is getting more complicated to maintain. It's still workable, but I can see that maybe in a few months time, it will become a nightmare.

Anyway, my question is this:

With larger software projects, what's the best way to keep them as being maintainable? I mean, when I suppose my cycle learning to program I've hit a series of these brick walls of maintainability:

• First wall; solved by learning that you could put code inside functions
• Second wall; solved by learning that you could put functions inside classes
• Third wall; solved by learning that you could put classes in to an architecture (say, MVC). And at a similar time - versioning, unit testing etc
• Fourth wall; ????

Anyways, I just wondered - is there some other learning thing that happens, some magical code organisation approach that makes these huge software projects 'work'? Is there must be some kind of thing that keeps huge projects from just grinding to a halt? Is it a just a case of being strict with oneself ... in which case, strict about what?

Thanks for the help, should it come :)

Answer 1

At some point, every project becomes too large and complicated to keep it all in your head. For some this point comes sooner or later than for others and you seem to have hit that point in your project now.

The first step now is to start writing that dreaded documentation. Write down

• what each class is supposed to be doing,
• which classes work together in a design pattern and why you use that pattern there
• for complicated logic, write down why it must be done this way and can't be solved in a simpler way,
• add clarifying (UML) diagrams where needed.

This can be either a stand-alone document, or it can be extracted from comments in the code with tools like JavaDoc, doxygen, etc. The aim here is to have something that you can refer back to to refresh your memory when you need to go back to a piece of code after some time.

---

Something else that you can do to keep a growing code-base manageable is to split it all up in smaller modules/libraries.

By splitting the project up in several smaller modules with strictly defined boundaries/interfaces, you can work on each module in isolation without needing to know/remember what is happening exactly on the other side of the boundary.
This effectively makes each module a small project of its own, with a much smaller complexity than the overall project.