The easiest design principle (SRP)

I won't underestimate this and try to explain the whole S.O.L.I.D design principles, however, I can clarify the most understandable (and commonly misapplied) principle: The Single Responsibility Principle, aka SRP.

But a bit of context:

The SOLID principles tell us how to arrange our functions and data structures into classes, and how those classes should be interconnected. The use of the word “class” does not imply that these principles apply only to object-oriented software. A class is simply a coupled grouping of functions and data.

The goal of those principles is the creation of mid-level software structures that:

• Tolerate change;
• Are easy to understand;
• Are the basis of components that can be used in many software systems.

SRP: The Single Responsibility Principle

A function should do one, and only one, thing.

Your function should NOT be like this.

Modules should have one, one and only one, reason to change. (Clean Architecture by Robert C. Martin.)

Software systems are changed to satisfy users and stakeholders; those users and stakeholders are the “reason to change” that the principle is talking about. However, we can replace user or stakeholder per Actor.

The word “cohesive” implies the SRP. Cohesion is the force that binds together the code responsible to a single actor.

Let’s “unconsciously” break that principle?

Let me show you how to break that principle. Picture that: you are working on a project which basically calculates salaries for the company and pays their employees. You have an HR team and a Financial team as project stakeholders.

On the code side, let's bring this to a fronted perspective. We have a React + Redux application, so you create a Saga and add two features: calculatePayment and reportHours.

The fact that you have both iterators in the same Saga can cause the actions of the Financial team to affect something that the HR team depends on.

Suppose that the calculatePayment() function and the reportHours() function share a common algorithm for calculating non-overtime hours.

Suppose also that the developers, who are careful not to duplicate code, put that algorithm into a function named regularHours(). For the educational purpose and to simplify the code, let's consider Saga iterators as normal functions:

Now suppose that the Financial team creates a task for the tech team like:

The way non-overtime hours are calculated needs to be tweaked.

In contrast, the HR team does not want that particular tweak because they use non-overtime hours for a different purpose. A developer is assigned to make the change and sees the convenient regularHours() function called by the calculatePayment() method, go there and apply the change. Unfortunately, that developer does not notice that the function is also called by the reportHours() function.

Here we came with code duplications discussion, I’ve heard multiple times: “Never duplicate code, never!” or “Always refactor code duplication”. In my opinion, it depends. You can have duplicated code if different actors are calling it.
If you were assigned to refactor some modules and are thinking about removing duplicated code, please check the context and bring the question to your team about that duplication.

—

How the solution should look like when you respect the SRP

The SRP says to separate the code that different actors depend on.

So, the first thing it’s separate (or duplicate) the regularHours() function into 2 files and connects them with their respective actors. After that, you can work on the task that you’ve been assigned and do whatever you have to do, following the financial team's request.

In the end, you can realize that now actors are calling the methods which give way more readability to your code.

I know it might be trivial, but if it is trivial and important must be said. Complex things are made by simple things.
Hope it helps you in some way.