After I watched and shared Mark Trostler’s presentation “Testable JavaScript” three times, at intervals of about a year. And for me, the experience was like reading one of those books that you find out more each time you re-read it.
Looking back, it’s easy to see that part of it was that, as a mostly-self-taught web-developer, for a pretty long while I didn’t take too serious the design patters and principles from the mainstream OO world. So while I could read the code and see how and why it worked, I didn’t quite grasp the underlying principles.
This last time, I had a fresh new perspective: I have successfully brought my side project to a spaghetti that just brought me to my knees. A mix of embarrassment with discouragement and burnout pushed me to look for different ways to structure my code. I went on and read as many things as I could about design patterns, so definitions and concepts were pretty fresh in my mind when I’ve watched the presentation this time. Probably equally important is that I had a clear question now: how do I structure my code in a way that I can make sense of it even after 6 months of development.
The 2 big things that rang for me were programming to interfaces and the decorator pattern. Even with amusingly awkward naming, the code snippets brought the point home for me, and I immediately found places to use them in my rebooted codebase. Even after reading Mark’s book, the two things remained the biggest ones for me: I think it might be the 80–20 rule in action.
PS: I feel like my blog articles have a pretty abrupt end at times, and I remember cases where real-world conversations felt like this too. I think this may be a sign that I’m “straight to the point”, which is a good thing, so I’m not too uncomfortable about it.