This is a book about how to detect bad code from code base with the help of code's history from git. I was surprised how simple things and techniques book uncovered about code quality. The key point is the time. We shouldn't do just static analysis from our current code but analyze how our code has lived and progressed. Tornhill calls this behavioral code analysis. I will explain some interesting things from the book, like hotspot analysis and what are surprises in code and why they can be really expensive. After reading the book I understood how to improve code quality cost-effectively.
Unit tests are my passion. I always write them and I also encourage others to write them and even have taught developers to write unit tests. But I am quite surprised how often developers don't write unit tests. There is a lot of benefits for writing unit tests. In this blog post, I will explain three main reasons why every developer should always write unit tests.
This is the third and last part of my code review related blog post series. Reviewing code is an important task where you can give feedback to the programmer. If you do it right, the programmer can learn something and code quality will be better. In this blog post I wrote how you can review the code better and more effectively.
In the previous blog post, I wrote about why you should do code reviews. This time I wrote about how code reviews should be created. Code review's author has an important part to make review successful. With these best practices review of your code will be better.
Code reviews are something I really value high. In my opinion, every software development team should do code reviews. In brief, the reason is learning and sharing knowledge and code quality. In this blog post, I will explain why.