Quick update on the project – all is going well, and we’ve finally sunk our teeth into concrete tasks over the past week. However, this blog isn’t about that…
It was nice to get a refresher on code smells this week, as it’s one of those things that’s hard to pinpoint. This article from Medium did a good recap of 5 of the most common smells. One in particular, “Blob Class”, actually came up over the past few days in my capstone project. One of my team members was reluctant to add extra methods to our “World” controller, since by that point it contained a mix of code for simulation control and UI. I encouraged them to make the additions at first, thinking little of it at first. The impression did stick, so later on I decided to refactor the code, moving UI controls to a separate class. If my teammate did not voice their concern about the code, I likely would have carried on adding to it, and the class would’ve become long and stinky. This goes to show the benefits of peer review – something the article advocates, and something I aim to do more often in the future.
On a similar note, this article from Reflectoring.io talks about viewing code itself as a form of communication – with other developers. While it’s not something the computer or the end user would see, it’s extremely important to write legible code when working in a team. Having primarily coded alone, it’s something I definitely need to get used to, by dropping some bad habits when it comes to naming conventions. When working alone, using “x” or “num” or even “obj” isn’t too bad, but it’s atrocious when someone else stumbles across those names and have to figure out what they are supposed to represent. Lazy names is something I have to drop – sooner rather than later.
Leave a Reply