The Pragmatic Programmer EP.3 — A Pragmatic Practice Part I
ETC — Easier to change
The authors stated in the book.
Good Design Is Easier to Change Than Bad Design
They believe in the ETC or “Easier to change” principle and are also told that every principle is a special case of ETC.
Why is decoupling good? Because by isolating concerns we make each easier to change. ETC.
Why is the single responsibility principle useful? Because a change in requirements is mirrored by a change in just one module. ETC.
Why is naming important? Because good names make code easier to read, and you have to read it to change it. ETC!
This principle pushes our software to be the high value helping us to make decisions, especially, in dilemma situations, for example, when there are many ways to code software, the common sense will be correct many times because it is easy to guess. To begin with the ETC, first, you need to think of the easy-to-change ways when you have no idea what the future changes will be. Second, your team should take notes on what choices you have and what you selected.
DRY — Don’t Repeat Yourself
Don’t Repeat Yourself principle means duplication of knowledge or intent in both the same and different places, not just the duplication of your source codes in exact steps.
Code Duplication
As you can see, it duplicates that many lines are printing the grades in the same format. This is called code duplication. So, you can simplify them by adding another function like this.
Almost DRY, there still exist many actions comparing the score and calling print_line. We can let it DRY more like this.
Not all code duplication is knowledge duplication
Not all code duplication doesn’t mean knowledge duplication. So, it’s no need to simplify them. For example:
Duplication in documentation
Don’t document what codes have done because codes do.
DRY violation in data
Don’t store the data depending on other values as above. But trying to calculate the data is the way to let it dry because all data must sync all the time.
Representational Duplication
- Duplication across internal APIs: To avoid this duplication, we should centralize the document or mock API among a team
- Duplication across external APIs: We should formally document like GitHub and allow them to import them to our project. If it doesn’t exist, consider initiating ones.
- Inter-developer duplication: Your team members should communicate with each another in standup meetings to let everyone roughly know what you’ve done. Developers will be far away from knowledge duplication handling issues.
Thanks to The Pragmatic Programming book for above knowledge, if you are interested in reading this book, click here for more detail.
