After working for nearly three years full-time I moved into a role that is primarily in Python. After roughly a year in a half I decided I’d try and write down some thoughts on the transition.

Some uses of enums defy the Open-Closed Principle. Pervasive use of switches over an enum leaves a code base in a state where code needs to be modified rather than extended to add new behaviour.

The Go runtime scheduler is at the heart of what gives Go great performance when writing programs that are highly I/O bound. Tens or even hundreds of thousands of Goroutines can be run concurrently. It’s not necessary to understand how the Go Runtime Scheduler works to take advantage of its power but it can certainly help to take further advantage. For instance, it’s a commonplace misconception that the number of goroutines should be kept low for higher performance and that the number of goroutines should be similar to the number of threads you may have in a multithreaded program, but this is not the case. Let’s dive into it.

Simplicity

Interface Segregation Principle

This is defined as clients should not be forced to depend upon interfaces that they do not use in the book Clean Architecture. The reason for this is because when a class depends on an interface it doesn’t use but that another class does the two classes become inadvertently coupled to each other. This is because changes forced upon the interface’s implementing class by each of the client classes that use the interface affect the other client classes.

Open Closed Principle

The open-closed principle means that a software artifact should be open to extension and closed to modification. The meaning of this principle is that software artifacts should be easily extended by adding new code and without modifying existing code. By software artifact I mean anything from a function, a class to the entire architecture of a software application. The idea behind the OCP is to guard software against changes in requirements. If a small change in requirements forces large changes on our codebase then we have a problem. The first is that changing a lot of code requires a lot of work. It’s just harder to change existing code than to write new code. As well as being harder to change existing code, it is much harder to review changed code than new code. This is partly because a reviewer needs to make sure the previous intended behaviours still hold true with the changes as well as making sure the new behaviour work as intended.

I’ve struggled to remember the SOLID principles after reading about them. I’m currently about halfway through reading Clean Architecture and the author regularly refers back to SOLID using their acronyms and it’s making it more difficult to read so I need to learn them. The best way to learn is to write. So, here we go.