Zombie code Code that lives its own life
I offer the readers of "Habrakhabr" a translation of the article "Zombie Code When Maintainability Goes Out Window" .
You are cheerful, agile, fast and you write a code like the wind. But you write a changeable code that can be as easily as possible corrected in the future by others.
Yes, you say? Why?
')
Did you ever think that your code will become obsolete in a year? Don't you care that some future developer will ruin the untouched beauty of your carefully crafted solution? Have you not admired a casually encountered, irreplaceable, but completely outdated lump of dirt? Would you rather write a zombie code that no one except you can understand, a code that will be regarded with fear and trembling, a code that will live forever in the company, because no one dares to change it?
It is not easy, but you can do it. With a little effort, you can develop your skills and discipline, which will give you the opportunity not only to write the code immediately, but also surpass the “so-so” level and you will write the final survivor - a zombie code that will continue to “walk” on the ground and after you leave.
And now how to do it:
Tests are a waste of time. They give the illusion of reliability and can show how your code works to someone else. If you have to conduct tests, do it last and declare that they are correct. Of course, do not test first and do not use tests to help someone — such development is an easy way to understand and change.
First, if the code works, do not fix it. Secondly, no one has time to develop elegance and simplicity. Development through testing (TDD), if necessary, is allowed, but only if you can not do without it. And in the end, "technical debt" is the sale of tools for measuring the characteristics of software.
Hide the possibility of your code is quite possible. First of all, give classes and methods such names so that they declare what they are doing and not their duties. Names such as “Getting a previous purchase for a product” are too long and informative. "Viewing information" will be much better. Better yet, just browse. Long live common names!
- Use generic names, for example, “Buffer”, “Temp” and “X”, as often as possible;
- Use abbreviations and abbreviations for the names of interfaces;
- Use the generic structure not only to save time and effort, but also to confuse information about data types;
- Use typed structures in untyped collections;
- Write everything in arrays;
- Copy and paste the semi-connected structure throughout the code, then modify it to match various data and situations, but do not rename the values ​​and do not change the comments;
- Sometimes (but not too often) give variables names that imply invalid types, for example, designate a floating-point number as “MessageText”;
- Pass by value parameters of type Object or String, and never encapsulate meaningful types;
- If you have to enter constants, give them the same names as their values. Or use Greek letters;
- Comments - the ability to add noise and wrong direction. The best comments announce what the code is doing, and even after the code changes remain the same;
- Remember that the person reading your code should only see what the code does, not how it does it: open connection, getting results, processing records, returning results, etc. And under no circumstances use the basic terminology of the case.
Reading other people's code is a waste of time, it can ruin your creative style. Stand up for your own standards and never comment on them.
Tabulation is waste. The code compiles faster without all these extra indents, besides the separation can make the code more readable. Write it all on one line as long as possible.
Modularity is a limitation. You can keep the entire solution in your head, so why spread it through numerous classes and methods?
Complexity is great, and excessive complexity is even better. It is much better to use the last functionality of the language, which will allow you to write two incomprehensible lines of code, rather than five obvious ones. If someone asks, say that it will improve efficiency and / or laugh at their ignorance of the secret features of the language that you used.
Apply as many architectural solutions as you can and stick to them, no matter what.
Never explain why your zombie code does something. Avoid your teammates or talk about the project you are working on. Your teammates may suggest and annoy with advice, or you may accidentally show what your teammates will understand. This is undesirable.
Refrain from pair programming. It will waste your time on questions for which answers are already in the code. If you are completely cornered, just describe what your code does.
If you have to work with someone by email. Wait at least two days between replies and change your inbox frequently.
Go around or break the so-called “policies”, “standards” or “processes” that can interfere with your evil plans. They promise you "quality improvement" and "time saving", but lies.
On the other hand, if you had to lead other developers, you can release your policies, directives and make changes to the processes as often as you like. But never explain why all this.
New developers in the team, especially newcomers, must rush out of the fire into the fire without orientation, education or support. Make sure that their questions are ignored or ridiculed that they are under pressure, trying to get rid of them. If you really want to make them pay bills, block access to Google and Stack Overflow.
DevOps methods and experts should be avoided. Set everything manually, as you like and change everything when you want it. Be suspicious of control systems - submit your code to the light only when everything is ready. Be sure to use a pseudonym and do not disclose anything in messages.
You can, of course, try to avoid participating in continuous communication with the team and / or sharing information, but you should not do this too often.
If you have to document, do it terribly.
If you have to write external documentation, write it so that only you can understand what is written. Never decipher the abbreviations and skip a few important steps - you had to try to understand the code, it means the others should also sweat. Save the documentation incorrectly and set incorrect search tags.
This is a sign of weakness. Find out everything yourself from the first sources. Other people's libraries are dubious. Write your own frameworks.
If you consistently apply all these tips, then your programs will become the walking dead, zombies that constantly decompose, but never completely die. All these efforts will keep your code after you leave.
Remember that you need to write the code as if the next person who touches it will be a violent psychopath who knows where you live. But this is unlikely to happen, because they will be too busy fighting with your mob of zombies.
Just do not sign your name.
You are cheerful, agile, fast and you write a code like the wind. But you write a changeable code that can be as easily as possible corrected in the future by others.
Yes, you say? Why?
')
Did you ever think that your code will become obsolete in a year? Don't you care that some future developer will ruin the untouched beauty of your carefully crafted solution? Have you not admired a casually encountered, irreplaceable, but completely outdated lump of dirt? Would you rather write a zombie code that no one except you can understand, a code that will be regarded with fear and trembling, a code that will live forever in the company, because no one dares to change it?
It is not easy, but you can do it. With a little effort, you can develop your skills and discipline, which will give you the opportunity not only to write the code immediately, but also surpass the “so-so” level and you will write the final survivor - a zombie code that will continue to “walk” on the ground and after you leave.
And now how to do it:
Check nothing
Tests are a waste of time. They give the illusion of reliability and can show how your code works to someone else. If you have to conduct tests, do it last and declare that they are correct. Of course, do not test first and do not use tests to help someone — such development is an easy way to understand and change.
No refactoring
First, if the code works, do not fix it. Secondly, no one has time to develop elegance and simplicity. Development through testing (TDD), if necessary, is allowed, but only if you can not do without it. And in the end, "technical debt" is the sale of tools for measuring the characteristics of software.
Write a code that is impossible to understand
Hide the possibility of your code is quite possible. First of all, give classes and methods such names so that they declare what they are doing and not their duties. Names such as “Getting a previous purchase for a product” are too long and informative. "Viewing information" will be much better. Better yet, just browse. Long live common names!
- Use generic names, for example, “Buffer”, “Temp” and “X”, as often as possible;
- Use abbreviations and abbreviations for the names of interfaces;
- Use the generic structure not only to save time and effort, but also to confuse information about data types;
- Use typed structures in untyped collections;
- Write everything in arrays;
- Copy and paste the semi-connected structure throughout the code, then modify it to match various data and situations, but do not rename the values ​​and do not change the comments;
- Sometimes (but not too often) give variables names that imply invalid types, for example, designate a floating-point number as “MessageText”;
- Pass by value parameters of type Object or String, and never encapsulate meaningful types;
- If you have to enter constants, give them the same names as their values. Or use Greek letters;
- Comments - the ability to add noise and wrong direction. The best comments announce what the code is doing, and even after the code changes remain the same;
- Remember that the person reading your code should only see what the code does, not how it does it: open connection, getting results, processing records, returning results, etc. And under no circumstances use the basic terminology of the case.
Write an unreadable code
Reading other people's code is a waste of time, it can ruin your creative style. Stand up for your own standards and never comment on them.
Tabulation is waste. The code compiles faster without all these extra indents, besides the separation can make the code more readable. Write it all on one line as long as possible.
Modularity is a limitation. You can keep the entire solution in your head, so why spread it through numerous classes and methods?
Complexity is great, and excessive complexity is even better. It is much better to use the last functionality of the language, which will allow you to write two incomprehensible lines of code, rather than five obvious ones. If someone asks, say that it will improve efficiency and / or laugh at their ignorance of the secret features of the language that you used.
Write the inflexible code
Apply as many architectural solutions as you can and stick to them, no matter what.
Do not share information
Never explain why your zombie code does something. Avoid your teammates or talk about the project you are working on. Your teammates may suggest and annoy with advice, or you may accidentally show what your teammates will understand. This is undesirable.
Refrain from pair programming. It will waste your time on questions for which answers are already in the code. If you are completely cornered, just describe what your code does.
If you have to work with someone by email. Wait at least two days between replies and change your inbox frequently.
Go around or break the so-called “policies”, “standards” or “processes” that can interfere with your evil plans. They promise you "quality improvement" and "time saving", but lies.
On the other hand, if you had to lead other developers, you can release your policies, directives and make changes to the processes as often as you like. But never explain why all this.
New developers in the team, especially newcomers, must rush out of the fire into the fire without orientation, education or support. Make sure that their questions are ignored or ridiculed that they are under pressure, trying to get rid of them. If you really want to make them pay bills, block access to Google and Stack Overflow.
No DevOps. Never
DevOps methods and experts should be avoided. Set everything manually, as you like and change everything when you want it. Be suspicious of control systems - submit your code to the light only when everything is ready. Be sure to use a pseudonym and do not disclose anything in messages.
You can, of course, try to avoid participating in continuous communication with the team and / or sharing information, but you should not do this too often.
If you have to document, do it terribly.
If you have to write external documentation, write it so that only you can understand what is written. Never decipher the abbreviations and skip a few important steps - you had to try to understand the code, it means the others should also sweat. Save the documentation incorrectly and set incorrect search tags.
Do not look for ready-made solutions.
This is a sign of weakness. Find out everything yourself from the first sources. Other people's libraries are dubious. Write your own frameworks.
Write the code for the zombie apocalypse
If you consistently apply all these tips, then your programs will become the walking dead, zombies that constantly decompose, but never completely die. All these efforts will keep your code after you leave.
Remember that you need to write the code as if the next person who touches it will be a violent psychopath who knows where you live. But this is unlikely to happen, because they will be too busy fighting with your mob of zombies.
Just do not sign your name.
Source: https://habr.com/ru/post/269373/
All Articles