The art of programming under Unix (and not only). Part Two, Clarity Better than Cleverness
I continue the series of articles related to the rules of Eric Raymond from The Art of Unix Programming.
In the last post I wrote about the rule of modularity . Let me remind you that it was about the fact that simple blocks should be connected with clear and understandable interfaces.
Today we will discuss the following rule -
')
The rule of clarity: Clarity is better than cleverness (or clarity is better than skill)
Rule of Clarity: Clarity is better than cleverness.
You probably heard more than once about the principle and process of design, known as KISS. This abbreviation stands for “Keep it short and simple” (“make it simple”) or “Keep it simple, stupid” (something like “don't complicate, stupid!”). In practice, it is expressed in the fact that if you know two solutions to the problem - simple and complex, then you should think twice before stopping the choice on the second.
Very often, programmers themselves set tasks that are not adequate to their goal. They come up with a problem for themselves to heroically overcome. This includes writing all kinds of "engines" that allow you to solve not only the task, but a whole class of tasks. For example, instead of taking a ready-made search engine, they write it themselves. Of course, the task becomes more interesting, but the risks of getting an unstable solution turn out to be higher, and support is much more expensive.
A small digression: There is a very common situation here, that perhaps you thought out for yourself the requirements that were not in the original task. They really can not be superfluous, but in no case can they be hidden in themselves. If a customer has an external task, then it is very correct to fix and approve these requirements, showing alternatives, risks, advantages and disadvantages.
It is worth remembering Albert Einstein's famous expressions relating to this rule: “Everything should be simplified as long as it is possible, but no more than that” and “You cannot argue that you understand something, until you can explain it to your grandmother. ” I'm not sure that I can explain the logic of the system of selection of accessories or the processing of price lists to my grandmother. But it should be explained briefly and succinctly to a person from business. If this fails, you come up with an overly complex system. Simplify, otherwise she is not a tenant ...
There is a philosophical concept close to the subject, Occam's razor. Its essence is that if there are several definitions or explanations of a phenomenon, then the simplest of them should be considered correct. But more often, Occam's Razor is recalled in a different context, “Do not multiply entities without need” (which is not quite true of the philosopher, but correctly in itself). This rule comes in almost every step of programming.
So, I summarize:
In the last post I wrote about the rule of modularity . Let me remind you that it was about the fact that simple blocks should be connected with clear and understandable interfaces.
Today we will discuss the following rule -
')
The rule of clarity: Clarity is better than cleverness (or clarity is better than skill)
Rule of Clarity: Clarity is better than cleverness.
You probably heard more than once about the principle and process of design, known as KISS. This abbreviation stands for “Keep it short and simple” (“make it simple”) or “Keep it simple, stupid” (something like “don't complicate, stupid!”). In practice, it is expressed in the fact that if you know two solutions to the problem - simple and complex, then you should think twice before stopping the choice on the second.
Very often, programmers themselves set tasks that are not adequate to their goal. They come up with a problem for themselves to heroically overcome. This includes writing all kinds of "engines" that allow you to solve not only the task, but a whole class of tasks. For example, instead of taking a ready-made search engine, they write it themselves. Of course, the task becomes more interesting, but the risks of getting an unstable solution turn out to be higher, and support is much more expensive.
A small digression: There is a very common situation here, that perhaps you thought out for yourself the requirements that were not in the original task. They really can not be superfluous, but in no case can they be hidden in themselves. If a customer has an external task, then it is very correct to fix and approve these requirements, showing alternatives, risks, advantages and disadvantages.
It is worth remembering Albert Einstein's famous expressions relating to this rule: “Everything should be simplified as long as it is possible, but no more than that” and “You cannot argue that you understand something, until you can explain it to your grandmother. ” I'm not sure that I can explain the logic of the system of selection of accessories or the processing of price lists to my grandmother. But it should be explained briefly and succinctly to a person from business. If this fails, you come up with an overly complex system. Simplify, otherwise she is not a tenant ...
There is a philosophical concept close to the subject, Occam's razor. Its essence is that if there are several definitions or explanations of a phenomenon, then the simplest of them should be considered correct. But more often, Occam's Razor is recalled in a different context, “Do not multiply entities without need” (which is not quite true of the philosopher, but correctly in itself). This rule comes in almost every step of programming.
So, I summarize:
- Let's move in the first place simple and understandable solutions;
- All complex decisions subject to critical analysis, preferably at an early stage, until you are sure that it is more expensive for you to simplify;
- Any complication should have a basis, ideally coordinated and approved with the customer.
| " Start: the rule of modularity | Continued: composition rule " |
Source: https://habr.com/ru/post/101290/
All Articles