2 Code duplication is not always bad: code duplication vs. flexibility

The DRY (Don’t repeat yourself) is one of the most well-known software engineering rules. The main idea behind this pattern is removing duplicated code that will lead to fewer bugs and better reusability of software. When DRY was popular, the systems that we were building were a bit different. They were mainly monolithic, meaning that almost the whole codebase was living on one repository.

Today’s systems evolved, and we tend to build distributed systems with many moving parts. In such architectures, the choice of reducing code duplication has more trade-offs like, for example, introducing tight coupling between components or reducing the development speed of the team. If you have one piece of code used in multiple places, changing it may require a lot of coordination. Where is coordination needed, the process of delivering business value slows down. This chapter will delve into patterns and trade-offs involving duplication code. We will try to answer a question: when code duplication is a sane trade-off, but also when it should be avoided. Let’s transition to the first chapter in which we will start from the architecture that involves code duplication.

2.1   Duplicating common code between codebases

2.1.1   New business requirement resulting in adding duplicated code

2.2   Sharing code between codebases with libraries

2.2.1   Trade-offs and disadvantages of libraries

2.3   Extracting common code to a separate microservice.

2.3.1   Trade-offs and disadvantages of separate service

2.4   Improving loose coupling in the design by code duplication

2.5   Using inheritance in the API design to reduce duplication

2.5.1   Extracting base request handler

2.5.2   Inheritance and tight coupling

2.6   Summary