One Thing I Want To Implement
One thing from the articles that I would like to start doing more often is cutting down the amount of redundant code present in my codebases. This is something that I tend to already do at times, but after reading chapter 1 of Clean Code, I feel that I need to have much more urgency on this. As Bob Martin points out, clean code is actually a matter of “professional survival” (page 5). Put in this way, I need to realize that writing clean code isn’t something that can be considered optional or a matter of convenience; it’s actually something that is necessary for the survival of a codebase as a whole, and probably more importantly for me, for my job survival. If I start to write messy code now, I will inevitably reach a point of productivity slowdown that will also inevitably call into question my value to the company. Thus, one of the easiest ways I can avoid falling into this state of unproductivity is to simply stop repeating myself in my code. I’ve found that I most often repeat myself in code if I am trying to be lazy in the short-term or take the easy way through some task. Usually, it’s some task that seems pretty harmless. It can be something like creating a new component in Angular. Usually, in a new component, there is a lot of code that is repeated from other components. Instead of simply making the old component code reusable, it’s tempting to just write it again in the new component. This is generally a shorter process in the short-term, but the end result is that now I have two components that are mostly the same code, but do completely different things. Instead, I could have just reused the first component and would have had half as much code in the codebase. This is something that I clearly need to stop doing, since after all, it is a matter of “professional survival.”
To this end, Bob Martin also raised some interesting strategies for writing clean code developed by other luminary programmers. For instance, I really liked the suggestions presented by Dave Thomas, in which we advocates that clean code has “unit and acceptance tests” along with “meaningful names” and “minimal dependencies.” All of these suggestions are not particularly unique; however, they do underlie the fact that writing clean code, while a matter of survival, is not something that is particularly difficult. It is straightforward to give classes and functions clear, descriptive names. It is also straightforward to write a meaningful test for each piece of new code that I introduce into a system. It may be difficult to write tests for old portions of the codebase that I have not authored, but it is not difficult to write tests for new code going forward. Following this principle is something that I will strive to do moving forward.
One Thing I want To Avoid
One thing that I want to avoid doing is utilizing excessive comments in my code. Martin Fowler has some particularly salient points on this topic in chapter 3 of Bad Code Smells. In the chapter, he highlights that “comments lead us to bad code” (page 71). I have certainly found this to be true in my own experience. In fact, I’ve even found that excessive commenting in my code actually is a symptom of poorly written code. If I feel a need to over-explain something or include really nitty-gritty details about an implementation, then, chances are, the code that I’ve written is not the most easy to understand implementation possible. As Fowler points out, instead of writing comments to explain a poor implementation, it’s probably a better idea to first try and refactor the code so that comments are not needed in the first place. Therefore, I want to make an effort in my work moving forward to cut down on the amount of comments I leave and rather search for ways to make comments less necessary.
Works Cited:
Fowler, Martin. Refactoring: Improving the Design of Existing Code. 2nd edition, Addison-Wesley Professional, 2018.
Martin, Robert C. Clean Code: A Handbook of Agile Software Craftsmanship. 1st edition, Pearson, 2008.
CATEGORIES: Uncategorized