This article by Ekaterina Novoseltseva on DZone (DevOps Zone) is about 8 benefits of unit testing. In the article, she breaks down how her company, Apiumhub, utilizes unit testing in order to stay Agile. She also breaks down several of the benefits of unit testing including relation to Agile, quality of code improvements, reduction of costs, and several others.
I found this article interesting because while I knew some of these benefits of unit testing, I never thought of some of the specific examples like the relation to Agile. She points out that unit testing facilitates “safe refactoring” by forcing developers to use the smallest functionality possible for testing a single unit. I agree completely with her in regards to Agile especially after she pointed out that this goes hand in hand with extreme programming and test driven development.
Personally, I’d never used test driven development at a large scale before so I’ve never really considered the benefits. The section on the benefits to design really pushes the idea that test driven development makes code more optimized, with cleaner designs. When breaking everything down into a unit first, figuring out what each unit is, and defining what the functionality is through tests, you are forced to consider the designs of the actual functions before writing them.
Another point that she makes that is probably one of the most important to the business is that unit testing reduces costs for the development process. Unit testing finds bugs early in the process because the tests are either written before the code is even written, or before moving onto the next snippet of functionality in order to stay Agile. This means that application-breaking bugs are less likely to be found in the later stages of the development process like “system testing” or “acceptance testing” as Ekaterina points out in the article.
I wholeheartedly recommend this article to anyone who is relatively new to unit testing and doesn’t is any bit unsure of the possible reasons why unit testing is so important. I can see myself utilizing unit testing more in my personal projects in the future as I already try to work on them in some resemblance of an Agile process.
This week I decided I wanted to read a blog post as opposed to a podcast for my blog entry. I went to the slack channel and found an article posted by Jason Knowles on writing clean code. Before reading the article, I knew had a general idea of what clean code was supposed to be, but lacked depth in understanding. Clean code is tremendously important in becoming a strong software engineer. Without a good understanding of writing clean code, a developer will never be successful in effectively contributing to a team. My goal and reasoning for choosing this blog post was to get a better idea of what clean code is exactly and how to work towards consistently writing it.
The blog post opens up a general overview of what clean code is and it’s importance in software maintenance. This flows into the main portion of the post, which is the practices to follow to ensure that one’s code is clean. The post ends with a few sections about code review, pair programming, and other resources.
One of the areas in the post that stuck with me the most is the topic of methods/functions performing a single operation. If a method performs multiple operations, it is probably a good idea to split this method into two different calls. This concept relates to the idea further discussed in the post about inline code VS function calls. The writer identifies that there isn’t one perfect solution for every given problem. In some scenarios, inline code is a better solution than creating a function/method to solve an operation. What comes to mind immediately to me is situations where a few operations will clearly never be needed elsewhere in the application and writing a longer method/function once will make future maintenance and understanding easier. The scenarios where method calls are better seems to be the vast majority of the time.
Another area in the post that caught my attention is the area regarding comments. The writer discusses the idea that comments are often a sign of poor code. This caught me off guard as I’ve always used comments as a way to remember what a function does for future additions and changes to my applications. The author writes that “comments should explain where code cannot” and that comments should be used to explain unconventionally written code. From reading the rest of article, it seems that if the code is written unconventionally, the comments are still a cover-up for poorly written code. This may be a poor code base that the current developer is simply writing an addition to, but does not have time to fix a poor code base.
In my first couple of years as a CS major, I have struggled with writing clean code and I feel that this article will help me in the future to write, scalable, easy to maintain code.
For anyone interested, here is the article this post is about.