Seeing the bigger picture
A special moment in the web developer learning process
This post comes as a result of the impressions and the impact that switching from a single page spaghetti code to modular approach had on me. This was the most important step in my front end developing learning process at the time. The switching process happened while developing a JavaScript based task organization application as a part of a learning project.
More about the app: https://github.com/AGjozev/To-Do-Application
Single file script
Many of the coding learning processes start with creating single file script projects. Through these projects we learn about the syntax of the language, in this case JavaScript, its characteristics and we develop our skills for using the set of tools and methods that are at our disposal. But after a while, the projects become more robust and more complicated, the line number on our code page has four digits and the structure is more like a pot filled with spaghetti-like entangled functions and methods.
- Lack of structure
Although, as a beginner, my lack of experience, and with that, lack of clear vision about how the end code structure should look like for this application added to the problem with the structure, I realized that much bigger problem is losing, or melting of the predetermined structure as result from the co-dependence and close entanglement of the different code segments brought by the code complexity.
- Tendency for writing solutions in the current position of the cursor
As the code complexity and melting of the structure grows, so does the number of situations where the predetermined solutions are not working as planned, causing bugs and problems. Solving these problems and creating new solutions creates a tendency for writing code in the nearest function associated with that part of the application or just writing a new method at the current cursor position. By doing that we become the biggest contributors of code entanglement.
- Endless debugging
Endless clicking on your F keys on your keyboard, looking for the problem, the bad line of code, the bad connection, calculation or whatever is causing the problem could be one of the most frustrating processes in this profession. Especially when the code is badly entangled, searching for the reason for the bug is a time-consuming process. But what is worse is that in these situations, when the methods are closely interdependent fixing one problem may cause other bugs to emerge in the neighbor segments of the application.
- Changing a segment in the app
And finally the moment comes, after countless hours hard work everything works bug-free. Proudly and with a sense of triumph we present the work to the supervisor, in my case my mentor, we receive words of praise followed by a “OK, and now…”
“OK, and now we have some changes that must be done in the application. Change the appearance of the side menu and the position of the search input element. Adding a new task should be direct not through a pop up. Add an option for task location with a map and a drag and drop sorting. Also a calendar in the side menu with “search by date” ability would be nice.”
Adding new, changing or removing segments is the biggest challenge in this type of spaghetti code. Not being able to recognize where some segment begins and where it ends and which are all the methods that hold code referring to that segment is the biggest obstacle for doing any work in a normal time frame. And every change made, results in fist full of errors and bugs which bring us back to the process of endless debugging.
This type of requirements for changing or adding something to the applications are pretty standard in this profession. The problem is doing them in normal time frame working with entangled code… sometimes if the changes are big enough it could seem faster task to rewrite most of the app then to apply the changes.
That was my breaking point. I had to find a better way to structure my code.
Untangling the spaghetti, switching to modules
After a detailed explanation of the concept of modular coding by my mentor and reading about it in a few educational posts on the web I started my untangling process.
- The process
Don’t get me wrong , this was a hard task and I often got the feeling that rewriting the whole app would be easier. I had to cut through my methods, finding and adding every code associated with that segment in the other methods creating independent modules. But I did it with newly acquired enthusiasm, learning something new with every new module, realizing the huge potential this type of structure has.
- Debugging is faster than ever before
As always, debugging is part of the job. But this time doing it is a much faster and more precise process. It’s easy if you know where to look for the error in the code. The frustration was completely gone from the process.
- Change made easy
And again when the finish line is in sight and everything is good and ready, another set of changes comes into play. And this is where you can see the real power of the modular structure. Changes now are done in just a fraction of the time needed before. Many of them with this structure can be done with very little or even without making changes in the JavaScript, instead just using HTML and CSS changes.
Conclusion
At the end I would like to express the change in viewpoint regarding the code structure. The closest analogy I cloud think of is this one: spaghetti coding was like putting together a puzzle with binoculars. I was always focused on the things before my eyes, but I couldn’t see the bigger picture. Instead I was trying to create a mental image of the things I was building and guide myself by it. With modular approach the binoculars were finally off. I was seeing the bigger picture, with all of the components and their details. It was a complete picture.
