Once your company/team starts writing Go code, you will notice that people are building lots of similar code. You would ideally want to re-factor such code into a framework package that can be used by multiple projects in the company. Typical areas of re-use include authentication, logging, configuration, helper classes, and so on.

This can be thought of as an internal third-party package under the vendor and maintained as mentioned.

While common code is good, it is also tougher to engineer right. We need to ensure that there are clear guidelines for writing such code. Some of these are as follows:

• The configuration for the code should be externalized. For example, it should not expect a configuration file at /etc/config/my_lib.
• This logger inside the code should get context from the environment.
• This code should as far as possible, not handle errors on its own. It should translate library events into something meaningful related to the contract and emit them.