I'm currently working on a blog post about the work I did last winter in my "Intro to Databases" course. In that course I teamed up to build a super awesome CSA farm database-driven website. That post isn't quite ready, so this week I'm going to discuss what I found when I reopened the repository:
It turns out, I've learned quite a bit in the last eight months!
Last winter I was also taking "Intro to Software Engineering 1". Just as I was getting to the main bit of "business logic" for my database project, my S.E. course was beginning to drill down on "refactoring", "code-smells", and how all code comments are evil and lazy.
("business logic", another term I've learned since last winter!)
The business logic in question is an algorithm that manages the distribution of produce into boxes which are then picked up by farm supporters. The logic is run anytime new produce comes in, current produce needs to be spoiled out, and supporters join or leave.
To put it lightly, it's a chonker of a task.
But filled to the brim with enthusiasm and refactoring.guru tidbits about 'spaghetti code' and 'self-explanatory names' I opted to write the entire thing as dozens of 5-liner functions without a single comment. 😨
I'm still a firm believer in the techniques of "Extract Method" and "Rename Method". However, I'm also a believer in the fact that this code needs more documentation to be considered complete.
Making small, well-named functions just wasn't enough for anyone to pick up the code and understand it, and refusing to add comments didn't help.
We live and learn, and now at the top of my refactoring todo list for the project is: "Write concise documentation for the big algorithm".
Another cardinal sin that I committed (hehe) when crafting the megalith algorithm was that I pushed the entire thing in one go.
To main.
With no intermediate commits.
😵💫
I did create a local branch when I started development, but that was the last I thought of git while working on it. Besides, I completely neglected creating a branch in the repository.
For this low stakes project everything turned out fine – but that's no excuse. Practice make permanent, so now I strive to more disciplined in my git behavior with each project I work on. I've learned to create remote branches, commit changes incrementally, and create peer reviewed pull requests!
The amount of time I took to develop the algorithm was… more than it needed to be. Thankfully, in the spring I learned that blitzing an algorithm is not the only way! 🙂 🙂 🙂
Enter "Intro to S.E. 2", and Test Driven Development. Imagine, actually defining what I wanted the algorithm to do BEFORE I spent several hours wading through asyncs and futures… amazing!
If I had used TDD, I would have ignored the asyncs at first because my tests for output correctness could be passed easier than my tests for speed. Only once the logic was figured out (and testing green!) would I have needed to swap awaits for futures and asyncs to boost performance and pass a further suite of tests. This would have saved significant time and sanity, so I want to implement TDD as much as possible in my future workflows.
In the fast pace of 17 units a term I sometimes forget that I’m building anything other than assignments and test-readiness. It's refreshing to reflect and see all the techniques I'm soaking up from sitting at my computer everyday. It’s also calming to know that I will look at my current projects in another eight months and find just as much wrong with my process – because I’ll be that much better!