TLDR;

• When extending a function, NEVER change the function signature
• Make sure you have thought about the future uses before exposing an Interface to public, because you’re NEVER gonna change that
• There’s Backward Compatibility (code can compile) and Behaviour Compatibility (code acts the same way) to consider

Background

In this world, we have two kinds of repositories:

1. Application Repositories — repositories that is only used & seen by you and your team that contains the business logic of your App
2. Shared Libraries — Repositories that are used by many other application repositories (think any standard library, SQL package, Redis, any open source pkg etc…)

Because many application repositories rely so heavily on Shared Libraries, we need to make extra care when writing them to 1) maintain readability and most importantly, 2) ensure backward compatibility.

This blog post hopes to provide junior devs with an illustration of the concepts taught in the Golang blog’s latest post:  https://blog.golang.org/module-compatibility. I will first show simple examples of the patterns discussed and also point to some examples already illustrating these points.

#golang #clean-code #golang-development