1

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 :)

gnat
  • 21,442
  • 29
  • 112
  • 288
Algy Taylor
  • 131
  • 5
  • "Is there some other learning thing that happens, some magical code organisation approach that makes these huge software projects 'work'?" - No. That's why most huge software projects fail so miserably. – Kilian Foth Nov 14 '14 at 13:57
  • 1
    Maybe you included this in one of your other levels, but code libraries/projects to hold large sections of similar code to be reused in other areas. – bowlturner Nov 14 '14 at 14:00
  • 1
    Above classes, there are further layers of modularisation. Break the codebase into chunks, each of which serves a particular purpose. Try to minimise the connections between them. You will probably also end up with a general purpose "library" layer. – Simon B Nov 14 '14 at 14:30
  • MVC is a design pattern. It isn't and it shouldn't be a complete architecture of a software system (even if it is the most important design pattern ). – Maarten Bodewes Nov 14 '14 at 14:30

1 Answers1

10

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.

Bart van Ingen Schenau
  • 71,712
  • 20
  • 110
  • 179