Bulletin boards, refactoring and teamwork
Monday morning and we were straight back into building our message board system. Friday, we had started all guns blazing, hit a wall, regrouped and tried a few more ideas. By the end of the day, we had some form of progress. We had managed to pull out some of the hard coded sections, but it seemed the more problems we solved the more we created. So we packed it in early and played games. Now it was Monday morning, time to bang our heads against a wall again and cross our fingers for a stroke of genius to hit.
Our prayers were answered in the form of our coach, Eddie.
As I’ve mentioned before, COBOL isn’t exactly the most popular language for novice coders. Makers don’t tend to teach it, in fact we are the first cohort to undertake a COBOL module, so understandably there is an element of the blind leading the blind. Okay, maybe that’s a bit harsh, it’s more like someone wearing the wrong prescription of glasses (our coaches with years of experience in coding) leading the fully blind (us, the shiny new apprentices). Still having coaches relatively new to the language has its’ perks; one of which is their desire to tinker with the challenges themselves, enjoying the fresh material. And this is what led to our weekend miracle; a curious Eddie, access to our codebase and the underlying motivation to learn and improve.
In other words, Eddie had kindly spent some of his weekend deciphering our code and making it better and he was happy enough to share his findings. Excellent. Grateful for his help and after some time spent understanding the changes (which were reassuringly not too drastic, proving we weren’t far off), we were rolling again. And boy did we roll!
The mood in the team was totally lifted, suddenly the initial impossible task seemed not only feasible but kind of easy. We quickly tidied up the rest of the message-board system and then all turned our attention to the game section of the code. Having already made some progress on this last week, we were able to break through this hurdle too with some extra man power. Suddenly it was Tuesday afternoon and we’d done it. We had finished the program, complete with all the essential requirements, fully working, a day early. Unbelievable.
Buoyed by our success and feeling pretty smug we spent the Wednesday adding in the stretch challenges and extra ‘nice to have features’ as well as some appropriate Teenage Mutant Ninja COBOL Turtle ASCII art. I personally spent the day refactoring, determined to get rid of some of the uglier sections of our code. I found this super beneficial and boosted my confidence further as I realised that not only did I fully understand every section of our code, I could comfortably manipulate it and refactor without breaking the whole thing.
Wednesday afternoon ended on a high as we had a mini demo session with the other group. Both groups like proud parents showing off their precious baby and all the amazing things they could do. Both teams had absolutely smashed it.
Having grown used to a weekend break between modules, Thursday morning felt a bit abrupt; being immediately thrown into a new topic with new challenges. However, after a kick-off session and some general discussion, things started to look clearer and I was eager to get stuck into something different.
The focus of the next 7 days was to be COBOL maintenance; looking at complex, perhaps large codebases, understanding what was happening, refactoring and adding new features. We had been given 3 projects to work on through the module and I started with the first; the well-known Gilded Rose Kata.
The Gilded Rose is a common programming challenge translated into many languages. You are a shopkeeper selling magical and unusual wares, they have sell-by dates and quality ratings that differ with time and type and dictate the price of each item. The task is simple, you must look at the existing code and add the logic for a new item. The catch is the codebase is extremely messy and the logic is all over the place. You can try and add the new feature immediately but it’s likely you’ll run into problems, instead the challenge is to refactor and tidy the code without breaking it, so that when you come to add a new feature, it’s easy.
I began by trying to read through the original code, quickly I realised I’d need some help to follow the logic. Remembering my lessons from early in the course, I reached for pen and paper and began making a diagram. After some tedious reading through each line of the code I eventually had some form of flowchart and a list of rules for the different items. As it turned out, there were plenty of similarities and the rules were fairly simple. Quickly I was able to refactor large sections of the code, drastically improving the readability and shortening the overall length of the program. However, I wasn’t happy, I still had a bunch of messy conditional logic, nested if-loops, multiple else-if sections. I could do better.
I took a different approach and decided to break my code into sections with one for each type of item. Ultimately I barely had to rewrite any code but simply ordered it better making the whole program slightly longer but infinitely easier to read and follow. Much better. I felt that I could change it further if I wanted. I toyed with the idea of refactoring in different ways, adding functions, changing if statements, moving sections.
Overall, I felt my current approach was the most appropriate; the neatest with the least repetition, but I was happy with my level of understanding and how confident I felt in manipulating the codebase. Turns out refactoring can be kinda fun, who knew?
