Let Someone Walkthrough Your Unfinished Code

"Make it a practice to present and discuss each implementation at one-third completion", wrote Adam Tornhill in his excellent Software Desing X-Rays book. Since reading that book I've been thinking about it, and I wrote why I strongly agree with it. Practically it improves code quality (which I value really high).

The Conclusion of The SOLID Principles Series (SOLID 6/6)

I wanted to recap this series about SOLID principles. In my opinion SOLID can be summarized with two things: "Code against interfaces, not implementations" and "write small classes/interfaces". If we follow those two things, our code would be close to SOLID.

Dependency Inversion Principle (SOLID 5/6)

"Program to an interface, not an implementation" is a famous quote by Gang of Four. Even if it is not the definition of the dependency inversion principle, it is really close to it. Another related quote is by Robert C. Martin: "depend on abstractions, not on concretions". While writing this blog post I concretely learned what these quotes practically mean.

Interface Segregation Principle (SOLID 4/6)

Interface segregation principle (ISP) says that clients should not be forced to depend upon interfaces that they do not use. Practically that means that we should have rather small interfaces with just few (or even one) methods than fat interfaces with many methods. In this blog post I will explain what ISP is and what relationship it has with Liskov substitution and single responsibility principles.

Liskov Substitution Principle (SOLID 3/6)

You can't get any idea of what Liskov substitution principle (LSP) is from its name. And its definition is hard to understand. But when you dig into it you'll find that it is quite important and not that difficult principle. It has a relationship with open/closed principle and contract by design. LSP guarantees that every object of subclasses behaves just like superclass. In this blog post I will explain what LSP is and how it helps to make better code.

Open/Closed Principle (SOLID 2/6)

"Software entities should be open for extension, but closed for modification" is the definition of open/closed principle. I learned a lot while writing this blog post. For example I learned what relationship does open/closed principle have with strategy pattern. I will explain also it beside I explain what is the open/closed principle.
This is the 2/5 blog post from SOLID serie. It was worth to write!

Single Responsibility Principle (SOLID 1/6)

Single responsibility principle (SRP) is a good way to write better code that is easier to maintain and read. In this blog post I have written what is SRP and why you should write code applying SRP.
This is the first blog post from SOLID serie. Reason to write this serie was to deeply learn what SOLID is and master it.

Software Design X-Rays by Adam Tornhill

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.

Always Write Unit Tests

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.

Code Review Best Practices For Reviewers (Code Review 3/3)

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.