Red degree

The DRY principle is to not repeat yourself, to not have duplicates of code.

It is not simply not having the same line of code twice in your project. The point is to not have code that has the same purpose twice in your code. Let's assume that you check an object for a specific condition, i.e. if an specific validation rule shall be checked. First, there the validation rule should not be implemented multiple times in several places, it is also the condition that should not be implemented multiple times.

Refactor the duplicated code into a method that you can reuse the same code block.

Modern programming languages offer options such as static methods or extension methods. The best option is to use object oriented design (OOD) and have the object, the guarding check and the validation rule as objects.

Implement the bare minimum to achieve your goal.

The less code you write, the less code you have to maintain. Often you also reduce the risk of having a bug when writing less code. It is ok to consider upcoming requirements, but that should not exceed your estimated time frame or over-complicate your current solution.

If you implement something, which is currently not required, and turns out to be not required later either, then you ran into the YAGNI principle, something we will look into later.

There are different kind of optimizations you could do. Improve the performance, make the code more readable or more elegant, etc. Usually, those optimizations are not needed - if the original code is not obviously stupid - in early stages of the project and simply cost effort and time. The implementation might change several time due to new requirements and then all the optimization work might be lost.

A clean working version of your solution is the foundation for optimizations when it is time to optimize and streamline the code.

In object oriented design/programming there are two major concepts of reusing functionality: inheritance and composition.

With inheritance, a child class is derived from its parent class. By that it can override methods of the parent class to provide a different functionality or adding extra methods to add new functionality. A lot of programming languages also support shadowing of existing methods instead of overriding them. Inheritance creates a superset of the entire inheritance hierarchy. The dependencies of a deep inheritance hierarchy makes a system unnecessarily complex.

With composition, a class uses another class and represents a specific subset of functionality. Changes to the used members of the other class are the only dependencies which can affect the consumer class. This makes the system simpler.

This principle is about separating decision blocks from behavior blocks and to not mix them.

If a method contains transformations, I/O calls, or generally, API calls, then it is called Operation.

If a method contains (decision) logic, then it is called Integration.

Simply speaking: do not mix your ifs and conditions with the actions that have to be performed. Place each action in a separate method. Place complex conditions in separate methods too.

The outcome could look like:

if (IsDataMissing(order)) RequestMissingData(order);
else Approve(order);

You can imagine how much more could be in the three methods IsDataMissing, RequestMissingData, and Approve and how much more readable this is.method declarations wi

Usually developers follow this rule when the overall method gets longer. So don't be too strict to yourself if the code block afterwards is longer than the original code due to the method declarations.

Most developers don't work on a greenfield project - they work on a code base with a long history and some fluctuation in the team over the past years. Most likely the original team members have retired or left the company for other reasons. They have to work with the code as it is. So a big refactoring to modernize the code is no option.

Here comes the boy scout rule into play. Instead of making the one big change to cleanup everything, you make the situation a little bit better every time you work on the code.

When you implement a feature and you see something you can improve with a tiny bit of extra effort, you do that. You don't change how things work, but you can fix a typo if you see it. You maybe add some extra documentation if that would have been helpful for you in the beginning. You change the name of a variable to clarify its purpose.

This will improve the quality of the code over time.

You should always identify the root cause of a problem and fix that. You should not be satisfied with implementing a work-around to cure a symptom. The cause of a problem might be buried deep down in the code and you will have to dig for some time to reveal it. But resolving that will prevent it from appearing in other situations and keeping you busy again.

Root cause analysis is also known as the Five Why's. Ask Why? at least five times to check if the cause you found is the real root cause.

The importance of having the source code protected by a version control system can't be emphasized enough.

A version control system takes away the fear of irreparably damage the code by changing it.

The modern standard for version control systems is git. Some of the biggest software projects uses git for their source code. But also the configuration of infrastructure-as-code is more and more often stored in git repositories. The advantage is always the same: you have a versioned history of your code/configuration. A lot of platforms for software development integrate git repositories in their systems and provide a system of restrictions to follow a specific process to apply changes. This allows teams to coordinate their collaboration to follow a specific flow.

As describes in the boy scout rule, you should always leave the code in a better state as it was before. Little refactorings go a step further. You do not only fix typos or rename variables, you refactor the code to improve the readability, reusability or performance.

The must used simple refactoring is to extract methods as described in the Integration operation segregation principle and to remove duplicate code.

On your path to become a better and more confident developer, you should take some time to have a retrospective during your daily doing. Reserve a time that you can reflect about your day and make plans.

What did I do well?
What can I improve?
What could be the next step to aim for on my learning-path?

The important thing is, to have small steps in mind, things that you can achieve in a day.

A recommendation could be to aim for one thing a day - and complete that thing the next day.

Did I follow all principles and applied all rules? Hmm. Focus on this principle a bit more tomorrow.
Tomorrow I will investigate the most important issue in the technical debt category and add my findings to the issue.
Tomorrow I will talk to person X in the business division to clarify the specification of PBI 1234.