Code that cannot be maintained (part 3, final)
(The end of these two topics - translations of the essay "Unmaintainable Code". In the remaining chapters, the author often refers to the methods already described, doubling and tripling each one of them; the presentation is greatly reduced by eliminating such places.)
If you leave a bug or two in your program, then the person who comes after you will have something to do.
')
Never test code that handles any hardware or operating system failures. Anyway, this code is never executed and only delays the development process. In addition, how can you check how your code handles disk crashes, file read errors, operating system crashes, and other special situations? After all, for this you will need either an extremely unreliable computer, or a sandbox that will simulate it. Modern iron never fails, and what fool will write code for testing only? No, it is not interesting. If users complain, put the blame on the OS or hardware - how do they know if this is so?
If something is not fast enough, advise the client to buy a more powerful computer. Think about it yourself, if you do load testing, you can find a bottleneck, you have to change the algorithms, or even completely redo the project. Who needs it? In addition, customer performance problems will provide you with a free trip to some exotic locality - most importantly, keep your passport at the ready.
(No, the main thing is that the problem should arise on the Cote d'Azur or in Bali, and not in the Far North or even in which Tmutarakan - approx. Per.)
Do not test code coverage or path coverage. Automated testing - for wimps. Find out which functions are responsible for 90% of calls to your code and write tests for them. Most likely, this way you test about 60% of your code and save yourself the remaining 40% of the effort. This will allow you to meet deadlines at the end of the project. By the time someone notices that some kind of extra feature is not working, you will have a cold.
Too many programmers are afraid - they are afraid of the boss, customers, mail, losing a job or going to court. This fear paralyzes and reduces productivity. Studies have shown that the exclusion of the testing phase allows you to perform work ahead of time, which excludes most of these fears. Therefore, the brave programmers are not engaged in testing: their goal is to write code, and the help system and the technical support department will cope with error correction.
If a person is completely confident in his programming abilities, testing is not necessary. Consider: it is obvious that testing does not solve any technical problems, no, it is a question of emotional certainty. It is much more effective to eliminate testing and send programmers to self-assessment courses: after all, every change in the code will have to be tested for many years, and you only need to complete the courses once. The benefits are obvious and awesome.
Debug mode allows you to execute commands in it that are not included in the main mode. Transfer part of the mandatory logic to debug mode, removing it from the main one. With due ingenuity, the basic version of the code will not even compile.
(By the way, it is important - I came to this rake quite recently, although unintentionally - comment. Per.)
(This essay began to be written in 1996, so accurate advice is clearly irrelevant, and very few will be able to follow it; only the basic idea is given - comment.)
The general trend in the development of programming languages ​​is to increase the reliability and quality of protection against a fool. Therefore, you should not use modern languages: insist on the oldest language that you only allow (but in which you can still program).
Hell are other people
In this essay, every now and then there are hints on how to infuriate your maintainer, how to stop attempts by your boss to get your code from you, and even how to start a universal holivar on how to format the code in the repository. Here are some more tips:
If your boss believes that his twenty years of experience with FORTRAN is great for modern programming, strictly follow his recommendations. As a result, the boss will trust you, your career will only benefit from this, and you yourself will learn many new and interesting ways to obfuscate your code.
Do not answer the phone. Forget about letters after assigning them a tracking number.
Never be vigilant in matters of type Y2K. If you notice something that will sneak up at a certain moment and destroy life in the western hemisphere, do not discuss it with anyone before the hour H (moment of event minus 4 years), when it is time to panic and pretend to panic.
(Looks like a disaster movie script, isn't it? - comment.)
Do not tell friends, acquaintances or other competent people, do not publish anything that might suggest a thought. Send one note (normal priority) to your superiors to cover your ass. You can add this letter as an attachment to another, important and urgent. After that, you can quit peacefully, knowing that at one hour you will be begged to return with an astronomical salary increase.
Choose authors who are too busy writing books to program themselves. Card through local bookstores looking for books with lots of diagrams and no code examples. Look at the books you’ve received and learn a few hundred incomprehensible but beautiful words that you can use to intimidate the nonentities following you. Your code should be impressive. Extensive incomprehensible vocabulary leads people to think that you are very smart, and your algorithms are very complex. For completeness, avoid banal analogies in the explanations.
Geniuses do not worry too much about whether their averaged colleagues keep up with them (and some still experience sadistic pleasure from their sufferings), and thus often lead their project to death. Behave the same way, even if you are not a genius. At least tell everyone that if they were smart enough, they would have no problem understanding your ingenious code.
(Contradicts the previous point, but much easier - comment. Per.)
One C programmer was irritated by company policies requiring the use of named constants instead of built-in numerical constants. He followed the letter, but not the spirit of the law, defining one hundred constants:
(Everything is relative. In the components on TopCoder there is a similar rule, and its letter is more important than spirit - yes, they would be happy to get this programmer - comment.)
By the way, simple redefinition of a constant
long entertain people trying to accompany your code.
Have you always wanted to write system level code? This is your chance! Ignore the standard libraries and write your own equivalents. In your resume it will look just awesome!
Write, for example, your own memory allocator that will simply allocate memory in the heap. Instead of writing complex procedures for freeing up occupied memory, require users to periodically reboot to clear the dynamic memory. Once they agree to such a strategy, they will never get rid of it.
(Again, in 1996, the unusual languages ​​were not at all what they are now, so the chapter was reduced to a basic idea with a couple of examples - comment.)
Choose a language unusual for the maintainer, and make the most of the features of its syntax. In SQL, use single- and two-letter table synonyms or names of other non-relevant tables; If possible, use different syntax options - just to keep others in
tonus. In Visual Basic, declare the type of a variable a symbol: instead of
write
Compile the code into an executable file; make sure it works; make a number of small random changes to the source code, but do not recompile it; leave the modified code in the repository. When the program stops working after the next change, it will seem that the error is in it.
If your employees like to use a line-by-line debugger, put several operators on one line - for example, the if-then-else construct can fit on the entire line.
Often make changes to your code, and require regular updates from the user - you do not want to use an irrelevant version? Do not tell anyone what is the difference between the versions - they do not need to know about errors that they did not notice themselves.
(Strange advice for repositories that can compare files - approx. Per.)
Do not release versions of programs that only fix errors - be sure to add a few significant changes to the interface, database structure or file format. People who are really hampered by this error will cope with the update, and the rest will get used to it and start calling it not a bug, but features. Most likely, compatibility is required from you - well, but ensure it only in one direction. Ideally, older versions of a program should not recognize files created in newer versions at all (yes, some word processors provide a great example).
The window “About the program” may contain the name of the program, the list of authors, copyright, several megabytes of code that generates an animated picture - but not the version of the program, the date of the last update, or the website from which it can be downloaded. Then everyone will be able to use different versions, report on long-fixed bugs, etc.
After that you can write
and somebody will fix it on
For variety, you can assign the same values ​​to TRUE and FALSE.
(Yes, yes, I remember #define TRUE (random ()> 0.5) - comment.)
If you are writing in C ++, pretend that you do not know about STL, and write all operations with arrays and strings manually - this will allow you to maintain your skills in handling pointers, and at the same time prevent any attempts of code changes by outsiders. On the other hand, include third-party libraries in the project - this will allow you to include them in your resume, while remaining in the dark about them.
If your compiler has an error, make sure your code is based on it. Once you use this tool, no one else should look for alternatives.
If your compiler warns you about unused variables, do not delete them, but figure out how to use them. My favorite method is i = i.
The best opportunity to try out these examples on a used program is a week before you quit and move to permanently relocate to another country. In other cases, following these tips can be dangerous to your health. The author and the translator are not responsible for the harm done to the national economy and individuals as a result of using the tips of this article.
Testing
If you leave a bug or two in your program, then the person who comes after you will have something to do.
')
1. Do not test error handlers.
Never test code that handles any hardware or operating system failures. Anyway, this code is never executed and only delays the development process. In addition, how can you check how your code handles disk crashes, file read errors, operating system crashes, and other special situations? After all, for this you will need either an extremely unreliable computer, or a sandbox that will simulate it. Modern iron never fails, and what fool will write code for testing only? No, it is not interesting. If users complain, put the blame on the OS or hardware - how do they know if this is so?
2. Do not do load testing
If something is not fast enough, advise the client to buy a more powerful computer. Think about it yourself, if you do load testing, you can find a bottleneck, you have to change the algorithms, or even completely redo the project. Who needs it? In addition, customer performance problems will provide you with a free trip to some exotic locality - most importantly, keep your passport at the ready.
(No, the main thing is that the problem should arise on the Cote d'Azur or in Bali, and not in the Far North or even in which Tmutarakan - approx. Per.)
3. Do not create test cases.
Do not test code coverage or path coverage. Automated testing - for wimps. Find out which functions are responsible for 90% of calls to your code and write tests for them. Most likely, this way you test about 60% of your code and save yourself the remaining 40% of the effort. This will allow you to meet deadlines at the end of the project. By the time someone notices that some kind of extra feature is not working, you will have a cold.
4. Testing - for cowards!
Too many programmers are afraid - they are afraid of the boss, customers, mail, losing a job or going to court. This fear paralyzes and reduces productivity. Studies have shown that the exclusion of the testing phase allows you to perform work ahead of time, which excludes most of these fears. Therefore, the brave programmers are not engaged in testing: their goal is to write code, and the help system and the technical support department will cope with error correction.
If a person is completely confident in his programming abilities, testing is not necessary. Consider: it is obvious that testing does not solve any technical problems, no, it is a question of emotional certainty. It is much more effective to eliminate testing and send programmers to self-assessment courses: after all, every change in the code will have to be tested for many years, and you only need to complete the courses once. The benefits are obvious and awesome.
5. Make sure that only debug mode is working.
Debug mode allows you to execute commands in it that are not included in the main mode. Transfer part of the mandatory logic to debug mode, removing it from the main one. With due ingenuity, the basic version of the code will not even compile.
(By the way, it is important - I came to this rake quite recently, although unintentionally - comment. Per.)
Language selection
(This essay began to be written in 1996, so accurate advice is clearly irrelevant, and very few will be able to follow it; only the basic idea is given - comment.)
The general trend in the development of programming languages ​​is to increase the reliability and quality of protection against a fool. Therefore, you should not use modern languages: insist on the oldest language that you only allow (but in which you can still program).
Teamwork
Hell are other people
In this essay, every now and then there are hints on how to infuriate your maintainer, how to stop attempts by your boss to get your code from you, and even how to start a universal holivar on how to format the code in the repository. Here are some more tips:
1. Giraffe is big, he knows better
If your boss believes that his twenty years of experience with FORTRAN is great for modern programming, strictly follow his recommendations. As a result, the boss will trust you, your career will only benefit from this, and you yourself will learn many new and interesting ways to obfuscate your code.
2. No technical support
Do not answer the phone. Forget about letters after assigning them a tracking number.
3. Keep your mouth shut
Never be vigilant in matters of type Y2K. If you notice something that will sneak up at a certain moment and destroy life in the western hemisphere, do not discuss it with anyone before the hour H (moment of event minus 4 years), when it is time to panic and pretend to panic.
(Looks like a disaster movie script, isn't it? - comment.)
Do not tell friends, acquaintances or other competent people, do not publish anything that might suggest a thought. Send one note (normal priority) to your superiors to cover your ass. You can add this letter as an attachment to another, important and urgent. After that, you can quit peacefully, knowing that at one hour you will be begged to return with an astronomical salary increase.
4. Club "Book of the Month"
Choose authors who are too busy writing books to program themselves. Card through local bookstores looking for books with lots of diagrams and no code examples. Look at the books you’ve received and learn a few hundred incomprehensible but beautiful words that you can use to intimidate the nonentities following you. Your code should be impressive. Extensive incomprehensible vocabulary leads people to think that you are very smart, and your algorithms are very complex. For completeness, avoid banal analogies in the explanations.
5. Pretend to be a genius
Geniuses do not worry too much about whether their averaged colleagues keep up with them (and some still experience sadistic pleasure from their sufferings), and thus often lead their project to death. Behave the same way, even if you are not a genius. At least tell everyone that if they were smart enough, they would have no problem understanding your ingenious code.
6. Pretend to be an idiot
(Contradicts the previous point, but much easier - comment. Per.)
One C programmer was irritated by company policies requiring the use of named constants instead of built-in numerical constants. He followed the letter, but not the spirit of the law, defining one hundred constants:
#define ONE 1
#define TWO 2
#define THREE 3
:(Everything is relative. In the components on TopCoder there is a similar rule, and its letter is more important than spirit - yes, they would be happy to get this programmer - comment.)
By the way, simple redefinition of a constant
#define THOUSAND 999long entertain people trying to accompany your code.
7. Roll-up
Have you always wanted to write system level code? This is your chance! Ignore the standard libraries and write your own equivalents. In your resume it will look just awesome!
Write, for example, your own memory allocator that will simply allocate memory in the heap. Instead of writing complex procedures for freeing up occupied memory, require users to periodically reboot to clear the dynamic memory. Once they agree to such a strategy, they will never get rid of it.
Receptions for unusual languages
(Again, in 1996, the unusual languages ​​were not at all what they are now, so the chapter was reduced to a basic idea with a couple of examples - comment.)
Choose a language unusual for the maintainer, and make the most of the features of its syntax. In SQL, use single- and two-letter table synonyms or names of other non-relevant tables; If possible, use different syntax options - just to keep others in
tonus. In Visual Basic, declare the type of a variable a symbol: instead of
dim Color_var as string
dim counter as integerwrite
Dim Color_var$, counter%miscellanea
1. Do not compile
Compile the code into an executable file; make sure it works; make a number of small random changes to the source code, but do not recompile it; leave the modified code in the repository. When the program stops working after the next change, it will seem that the error is in it.
2. Interfere with debugging
If your employees like to use a line-by-line debugger, put several operators on one line - for example, the if-then-else construct can fit on the entire line.
3. Improve
Often make changes to your code, and require regular updates from the user - you do not want to use an irrelevant version? Do not tell anyone what is the difference between the versions - they do not need to know about errors that they did not notice themselves.
(Strange advice for repositories that can compare files - approx. Per.)
Do not release versions of programs that only fix errors - be sure to add a few significant changes to the interface, database structure or file format. People who are really hampered by this error will cope with the update, and the rest will get used to it and start calling it not a bug, but features. Most likely, compatibility is required from you - well, but ensure it only in one direction. Ideally, older versions of a program should not recognize files created in newer versions at all (yes, some word processors provide a great example).
4. “About the program”
The window “About the program” may contain the name of the program, the list of authors, copyright, several megabytes of code that generates an animated picture - but not the version of the program, the date of the last update, or the website from which it can be downloaded. Then everyone will be able to use different versions, report on long-fixed bugs, etc.
5. Override TRUE and FALSE
#define TRUE 0
#define FALSE 1After that you can write
if ( var == TRUE )
if ( var != FALSE )and somebody will fix it on
if ( var )
if ( !var )For variety, you can assign the same values ​​to TRUE and FALSE.
(Yes, yes, I remember #define TRUE (random ()> 0.5) - comment.)
6. Avoid libraries
If you are writing in C ++, pretend that you do not know about STL, and write all operations with arrays and strings manually - this will allow you to maintain your skills in handling pointers, and at the same time prevent any attempts of code changes by outsiders. On the other hand, include third-party libraries in the project - this will allow you to include them in your resume, while remaining in the dark about them.
7. Compiler-dependent code
If your compiler has an error, make sure your code is based on it. Once you use this tool, no one else should look for alternatives.
8. Unused variables
If your compiler warns you about unused variables, do not delete them, but figure out how to use them. My favorite method is i = i.
Epilogue translator
The best opportunity to try out these examples on a used program is a week before you quit and move to permanently relocate to another country. In other cases, following these tips can be dangerous to your health. The author and the translator are not responsible for the harm done to the national economy and individuals as a result of using the tips of this article.
Source: https://habr.com/ru/post/99409/
All Articles