1
What if there were simple rules that could help you create a good design as you worked and help you gain insight into the structure and design of your code?
2
3
Kent Beck came up with four rules of Simple Design while he was developing ExtremeProgramming in the late 1990s. Until now, many developers feel that these rules are of significant help in creating simple yet well-designed software, and also helps in maintaining code to be clean. According to Kent, a design is “simple” when it follows these rules, in order of the importance:
4
5
6
7
https://www.martinfowler.com/bliki/BeckDesignRules.html
8
9
- Passes the tests (It Works)
10 - Reveals intention
11 - No duplication
12 - Fewest elements
13
14
The rules are in priority order, so “passes the tests” takes priority over “reveals intention”.
15
16
Without further delay, let’s dig in each of every rule and talks about what they mean in the full extent:
17
18
1st Rule: Passes All Tests (It Works!)
19
20
21
22
https://blogs.egu.eu/divisions/gd/files/2019/07/Untitled-4-e1560239780934-1400x800.png
23
24
First of all, of course, we need to make a working application to be delivered, that’s why it’s the number one priority. One of the many things that could make us sure that our app is working fine (and know exactly why it’s working) is to have tests for the particular code we wrote. Writing tests (comprehensive tests) actually could lead us to better designs. The more tests we write, the more we’ll continue to push towards things that are simpler to test, thus pushing us towards making our classes small and single purpose.
25
26
27
28
_Once the tests are passed, we are empowered to keep our code clean. We do this by refactoring the code, and it’s better to do it frequently and incrementally after each few lines of code we add. After making a single feature work and pass all the tests, take time to review your code. Did others not understand what I actually write here? Am I just degrading it? If the answers are yes, then we clean it up and run our tests. _The fact that we have these tests eliminates the fear that cleaning up the code will break it!
29
30
The next 3 rules could help you to check the quality of your code.
31
32
33
34
2nd Rule: Reveals Intention
35
36
37
38
https://cdn.wrytin.com/images/wrytup/r/1024/under-jx0fxee8.jpeg
39
40
When we are communicating with other people, we need to make sure other parties understand what we want to convey in our conversation. It’s also the same with code. As coders, we were working as a team in a project and there are lots of other coders that will see, touch, or even need to modify the existing code, and it’s very important for them to understand what you write in there.
41
42
To make our code reveals our intentions, we need to be expressive, and the most important way to be expressive is to try. Too often we get our code working and then move on to the next problem without giving a second thought to make that code easy to read. Place ourselves as other people that will become the next person to read our code. Care is a precious resource.
43
44
Some things that we can do to make our code more expressive are:
45
46
- Choose a good name that represents the things. Use predictable names so when other people read the class, function, or variable names, they don’t get a wrong idea or surprised when discovering the responsibilities.
47 - **_Keep your functions and classes small. _**It’s easier to name, write, and understand it.
48 - Challenge and commit yourself to write code so that it reads as documentation. Well-written unit tests are expressive and act as documentation by example. Someone that reads the tests should be able to get a quick understanding of what a class is all about.
What if there were simple rules that could help you create a good design as you worked and help you gain insight into the structure and design of your code?
Kent Beck came up with four rules of Simple Design while he was developing ExtremeProgramming in the late 1990s. Until now, many developers feel that these rules are of significant help in creating simple yet well-designed software, and also helps in maintaining code to be clean. According to Kent, a design is “simple” when it follows these rules, in order of the importance:
Image for post
https://www.martinfowler.com/bliki/BeckDesignRules.html
Passes the tests (It Works)
Reveals intention
No duplication
Fewest elements
The rules are in priority order, so “passes the tests” takes priority over “reveals intention”.
Without further delay, let’s dig in each of every rule and talks about what they mean in the full extent:
1st Rule: Passes All Tests (It Works!)
Image for post
https://blogs.egu.eu/divisions/gd/files/2019/07/Untitled-4-e1560239780934-1400x800.png
First of all, of course, we need to make a working application to be delivered, that’s why it’s the number one priority. One of the many things that could make us sure that our app is working fine (and know exactly why it’s working) is to have tests for the particular code we wrote. Writing tests (comprehensive tests) actually could lead us to better designs. The more tests we write, the more we’ll continue to push towards things that are simpler to test, thus pushing us towards making our classes small and single purpose.
_Once the tests are passed, we are empowered to keep our code clean. We do this by refactoring the code, and it’s better to do it frequently and incrementally after each few lines of code we add. After making a single feature work and pass all the tests, take time to review your code. Did others not understand what I actually write here? Am I just degrading it? If the answers are yes, then we clean it up and run our tests. _The fact that we have these tests eliminates the fear that cleaning up the code will break it!
The next 3 rules could help you to check the quality of your code.
2nd Rule: Reveals Intention
Image for post
https://cdn.wrytin.com/images/wrytup/r/1024/under-jx0fxee8.jpeg
When we are communicating with other people, we need to make sure other parties understand what we want to convey in our conversation. It’s also the same with code. As coders, we were working as a team in a project and there are lots of other coders that will see, touch, or even need to modify the existing code, and it’s very important for them to understand what you write in there.
To make our code reveals our intentions, we need to be expressive, and the most important way to be expressive is to try. Too often we get our code working and then move on to the next problem without giving a second thought to make that code easy to read. Place ourselves as other people that will become the next person to read our code. Care is a precious resource.
Some things that we can do to make our code more expressive are:
Choose a good name that represents the things. Use predictable names so when other people read the class, function, or variable names, they don’t get a wrong idea or surprised when discovering the responsibilities.
**_Keep your functions and classes small. _**It’s easier to name, write, and understand it.
Challenge and commit yourself to write code so that it reads as documentation. Well-written unit tests are expressive and act as documentation by example. Someone that reads the tests should be able to get a quick understanding of what a class is all about.
#clean-code #simple-design #visual studio code #coding
