“Complex things break in complex ways.” (
Steven M. Bellovin) “The threat is complexity itself.” (same article, Andreas M. Antonopoulos).
As one webpage to email script grows to encompass an entire content management project, or one product listing grows into a storefront and shopping cart, how do we keep our simple tools from becoming complex tools that could break and require a complicated repair?
People who have read my code might notice that I rely on subroutines and functions to keep me on track. I try to break a project into numerous problems, so that each more or less discrete problem is solvable in its own right. To take as an example the form->email project I mentioned above, I’d have one function to accept the variables from the form and “clean them up” so that I could protect the system from people trying to break my form, and another function to handle the actual emailing ( since I usually work in php, a wrapper to the mail() function).
To me, this is what “making legos to build programs” is about; which is how I learned. Once I’ve written those functions, I can put them into a separate file and include that file as a library. The next time I have to write a similar tool, I can use those same functions. Unfortunately, that also flavors my approach to object oriented programming, but that’s a post for a different day.
When I’m banging away at the keyboard like Hephaestus, I’ve usually got the problem in my head. So, I know the six or ten or maybe even twenty functions I’ve got going, and I can apply them as necessary. However, once the forge has cooled and someone brings back a broken lightning bolt and I must reforge it ( days, weeks, even months or years later), I often have to take a few minutes to reacquaint myself with the tools I had to build for that particular project.
So if I keep my creating simple with the use of functions that break a project down to atoms, and then reassemble the atoms to finish the project, how do I keep the resulting project from being a complex group of simple things that itself will break in complex ways? It’s easiest to lump together functions to larger groups. Actually the process is reversed; I break a large problem into slightly smaller problems, then break those problems into slightly smaller still problems, et cetera. What I’m describing now is more of recombining these problems back into the larger problems. So two or three functions that are always called together can be called with the same function.
However, this doesn’t help, really, when I come back days or months later and stare at the project, what helps me the most is the documentation I included above each function and frequently within each line. As well as documentation during the “main processing part” of the project.
Sometimes, however, a project is too big for me to load entirely into memory; Wordpress is one example. It’s just too big for me to see all the pieces of it. And when I try to work on it, I can sense that I’m losing visualizations of projects I’m currently working on. Another time when a brain->computer analogy works well. I have to swap some of the projects I have in RAM down to disk in order to look at other problems. To keep from breaking a large project catastrophically, I have to have some understanding of the complexity of the entire project, so I build my way up from the smaller functions through the aggregate functions and then look at how the aggregate functions are applied to each other. This takes a lot of processing power, and usually about the time I have got the functions sorted out, something else more urgent will call my attention to real life, and I’ll lose my place.
So, how do we, we of perhaps smaller RAM, catch up and understand a larger project without it conflicting in our mind space with other projects and real life issues?
I don’t know. What are your suggestions?
