Criminal Reengineering
Programmers are often blamed for doing sloppy work. In nature, there are countless programs that crash, hang, or suddenly write on the Preved Bear screen a million times. What is the result? Something like this:
Such an experience is the reason that prompts people to speak loudly about Microsoft and curse anonymous programmers who unexpectedly (however, inevitably) did not meet their expectations. We all know that; it is burned out in our souls with endless hours of tech support that we provided to family and friends. From time to time, we see how programmers who do their work quickly and carelessly make other people suffer. And so we try, we damn try not to be like that. We try to be good programmers who check every return value and handle every exception.
If we were limited to error handling and thorough testing, everything would be fine. But in truth, we usually go much further, and alas - I have to admit it - in the wrong direction.
')
A huge amount of software running is terribly redesigned . I'm not even talking about interfaces that are full of controls and settings. These are really terrible sins, but they are only the visible part of the iceberg. Much worse re-engineering occurs under the surface, in the code itself.
Have you ever seen how someone applies the “ Strategy ” design pattern where he could easily use a simple 5-line switch construct?
There are a million ways to transform a simple construction like this:
into a disgusting, abnormal mutant monster, such as this one , which I did not put into the article, because it is too long .
The most insidious cause of reengineering is excessive generalization. We re-generalize everything that even a little bit can be generalized. Writing code to work with the list of students? Well, we could work with teachers, and indeed with the general public. Someday It is better to add the base class Man and his subclass Student . Or else you can create a class Man , from him to inherit a class Student Man and from him a Student . Yes, so much better, isn't it?
That's the way it is, only now we have to support three whole classes, each with its own virtual methods and interfaces, possibly divided into three different files, while a dictionary (dictionary, map) in one line would be quite enough .
Perhaps we do this because it is relaxing — rattling off three classes full of code without having to stop and think. It gives a feeling of productivity. This solution looks solid, bulletproof, professional. We look back, warmed by a flash of self-satisfaction - I'm a good programmer , no dirty hacks in my code !
Everything is good, but it does not make us good programmers. Such reengineering does not make anyone's life better; it only makes our code longer, harder to understand and change, and increases the likelihood of errors in the code. We just made the world a bit worse. It lies somewhere between throwing bottles in the middle of the street and stealing cars.
Additional efforts caused by our reengineering also incur huge costs:
Yes, reengineering the student class you indirectly destroyed the day of Miss Alauren .
We must stop upholding every absurd trick of reengineering and call them by their proper names. This is not a “groundwork for the future” because we cannot foresee the future . This code is not reliable - it is difficult to read . Applying a generalized solution to a particular case is not a good programming, it is a criminal reengineering , because you like it or not, but someone somewhere will have to pay for it.
I suspect that all the best programmers have long understood this, but they didn’t shout about it loudly enough for everyone else to hear. Paul Graham is quite right when he suggests that brevity should be appreciated:
In fact, he was talking about language design; Indeed, in the article " Shortness - Power, " he clearly shows that you can write a program that is too short . This is because at the moment Paul Graham is more a language designer than an actual programmer. Otherwise he would say:
When I feel tempted to overly generalize or re-design a piece of code, it is often caused by fear. The fear that someone would find a really good reason why I shouldn’t have to choose a simple solution. Fear that I will have to rewrite this code. Fear to be on the wrong side in a dispute about the merits of the Visitor template . But fear, of course, will never lead us to the most elegant solutions.
The next time you feel motivated to write a good, general solution for a simple task, stop and ask yourself what prevents you from writing a simple, concrete and short solution:
If one of these options is your case, then relax. Do not worry. You worry, you call me, I make you happy (line from Bobby McFerrin ’s song " Don't worry, be happy ": "You worry, you call me, I make you happy.").
And take a yes, write a simple, concrete, short solution and add a short comment like this: Replace with the Visitor template if this code starts to grow .
This is the perfect solution. The next time you get into this code, this comment will remind you of what you wanted to do. It will show other programmers that you considered a more “correct” (difficult) solution, and at that moment you had a good reason not to start doing it for now . It’s hard to argue with such a comment, because you didn’t discuss what is better: the Strategy template or the switch, you just discussed whether it is worth using the Strategy template for a simple problem of 3-4 cases. In any case, this is definitely not a discussion that can show you from the bad side.
After a few months, you can go back and see how many of your comments ultimately turn into more complex code. I bet quite a bit. That's how much time and effort you saved. This frees the hands to continue solving the original problem, and makes the world a little bit better.
Related Links:
1. Stop Over-Engineering! (April 2002); a software-centric discussion from Software Development magazine.
2. Reengineering ; article on wikipedia (eng.)
3. Brevity - power ( original )
Damn computer and Excel ruined my whole life! Hate my life.
Miss Alauren (like any other at one time or another)
Such an experience is the reason that prompts people to speak loudly about Microsoft and curse anonymous programmers who unexpectedly (however, inevitably) did not meet their expectations. We all know that; it is burned out in our souls with endless hours of tech support that we provided to family and friends. From time to time, we see how programmers who do their work quickly and carelessly make other people suffer. And so we try, we damn try not to be like that. We try to be good programmers who check every return value and handle every exception.
If we were limited to error handling and thorough testing, everything would be fine. But in truth, we usually go much further, and alas - I have to admit it - in the wrong direction.
')
A huge amount of software running is terribly redesigned . I'm not even talking about interfaces that are full of controls and settings. These are really terrible sins, but they are only the visible part of the iceberg. Much worse re-engineering occurs under the surface, in the code itself.
You do it wrong
Have you ever seen how someone applies the “ Strategy ” design pattern where he could easily use a simple 5-line switch construct?
There are a million ways to transform a simple construction like this:
switch (operation)<br>
{<br>
case OP_ADD: return a + b;<br>
case OP_SUBTRACT: return a - b;<br>
case OP_MULTIPLY: return a * b;<br>
default: throw new UnknownOperationException(operation, a, b);<br>
}into a disgusting, abnormal mutant monster, such as this one , which I did not put into the article, because it is too long .
The most insidious cause of reengineering is excessive generalization. We re-generalize everything that even a little bit can be generalized. Writing code to work with the list of students? Well, we could work with teachers, and indeed with the general public. Someday It is better to add the base class Man and his subclass Student . Or else you can create a class Man , from him to inherit a class Student Man and from him a Student . Yes, so much better, isn't it?
That's the way it is, only now we have to support three whole classes, each with its own virtual methods and interfaces, possibly divided into three different files, while a dictionary (dictionary, map) in one line would be quite enough .
Perhaps we do this because it is relaxing — rattling off three classes full of code without having to stop and think. It gives a feeling of productivity. This solution looks solid, bulletproof, professional. We look back, warmed by a flash of self-satisfaction - I'm a good programmer , no dirty hacks in my code !
Everything is good, but it does not make us good programmers. Such reengineering does not make anyone's life better; it only makes our code longer, harder to understand and change, and increases the likelihood of errors in the code. We just made the world a bit worse. It lies somewhere between throwing bottles in the middle of the street and stealing cars.
Additional efforts caused by our reengineering also incur huge costs:
- Less time left for sharpening the user interface;
- Less time is left to think about the significant effects of the features we are working on;
- Less time is left to search for errors, and (given that the amount of code has increased) it will take more time to fix them.
Yes, reengineering the student class you indirectly destroyed the day of Miss Alauren .
We must stop upholding every absurd trick of reengineering and call them by their proper names. This is not a “groundwork for the future” because we cannot foresee the future . This code is not reliable - it is difficult to read . Applying a generalized solution to a particular case is not a good programming, it is a criminal reengineering , because you like it or not, but someone somewhere will have to pay for it.
Don't worry, Be Happy
I suspect that all the best programmers have long understood this, but they didn’t shout about it loudly enough for everyone else to hear. Paul Graham is quite right when he suggests that brevity should be appreciated:
We take the length of the program as an approximate estimate of the amount of work needed to write it. not the length in characters, but the length in different syntax elements - in fact, the height of the parse tree. It's not at all true that a short program takes less time to write, but it’s close to the truth. Take a look at the program and ask yourself, is there a way to write it in short?
- Paul Graham, The Hundred Year Language ("The Hundred Year Language")
In fact, he was talking about language design; Indeed, in the article " Shortness - Power, " he clearly shows that you can write a program that is too short . This is because at the moment Paul Graham is more a language designer than an actual programmer. Otherwise he would say:
If you are going to write a hundred lines of code to solve a problem that could be solved in ten lines, stop and ask yourself: what the hell?
- Mark, Criminal Reengineering
When I feel tempted to overly generalize or re-design a piece of code, it is often caused by fear. The fear that someone would find a really good reason why I shouldn’t have to choose a simple solution. Fear that I will have to rewrite this code. Fear to be on the wrong side in a dispute about the merits of the Visitor template . But fear, of course, will never lead us to the most elegant solutions.
The next time you feel motivated to write a good, general solution for a simple task, stop and ask yourself what prevents you from writing a simple, concrete and short solution:
- Am I worried to have to rewrite it?
- Am I worried that someone will criticize him or that I will look silly?
- I'm worried it's not professional enough?
If one of these options is your case, then relax. Do not worry. You worry, you call me, I make you happy (line from Bobby McFerrin ’s song " Don't worry, be happy ": "You worry, you call me, I make you happy.").
And take a yes, write a simple, concrete, short solution and add a short comment like this: Replace with the Visitor template if this code starts to grow .
This is the perfect solution. The next time you get into this code, this comment will remind you of what you wanted to do. It will show other programmers that you considered a more “correct” (difficult) solution, and at that moment you had a good reason not to start doing it for now . It’s hard to argue with such a comment, because you didn’t discuss what is better: the Strategy template or the switch, you just discussed whether it is worth using the Strategy template for a simple problem of 3-4 cases. In any case, this is definitely not a discussion that can show you from the bad side.
After a few months, you can go back and see how many of your comments ultimately turn into more complex code. I bet quite a bit. That's how much time and effort you saved. This frees the hands to continue solving the original problem, and makes the world a little bit better.
Related Links:
1. Stop Over-Engineering! (April 2002); a software-centric discussion from Software Development magazine.
2. Reengineering ; article on wikipedia (eng.)
3. Brevity - power ( original )
Source: https://habr.com/ru/post/99889/
All Articles