10 ways to screw in programming

Recently, by inheritance from a dirty, stinking contractor (who claimed that his knowledge and skills are so good not to touch him until he finishes the project) I got a web application. Unfortunately, we took his word for it. At first glance, most of the functionality of the web application worked as expected. However, as soon as the client began to use the application in real conditions, spring showed who, where the shit, it began to act up. The contractor disappeared after payment (die reputation!), And I was left to try to repair what the client had suffered so far.
I decided to describe some of the mistakes I encountered. These are errors that every good programmer should have been able to avoid for a long time ... but, obviously, some people need to be reminded of them.

# 10 - Do not store settings in configuration file

When you write scalable applications, information such as database connection parameters and the SMTP server address will be used throughout the application. In order to protect your application from further support, override these settings every time you need them. Instead of putting them into a configuration file (Web.config or whatever), just scatter them all over the project. Anyone who later gets your application will thank you for wandering in thousands of lines of code just to change the name of the SMTP server. It’s much more fun when the next programmer finds the server name in only 14 out of 15 places, and the last 15th place somewhere in the depth of the code makes the application work incorrectly. Sometimes it is useful to build the name of the parameters from incomprehensibly stitched strings. An active partnership of a new developer and a disgruntled client will help strengthen their relationship. And if not you, then who will create the prerequisites for this close friendship?

# 9 - Do not store variables in [any] memory

One of the advantages of databases is that they store information and allow you to access it whenever you need it. To make sure that your application is simply nowhere else awful, look at the database every time you need at least a small piece of information. The more often you need this information, the better - create more and more new connections to the database. General information about the user of the system is most suitable for this. Do not try to save information about the user, such as “isAdmin”, by assigning the value to a variable and using it throughout the entire current query. Connect to the database every time you need to know something about the user. In the end, the client paid for this database, and we have to squeeze the maximum possible out of it!
')

# 8 - Use tricky plugins

If a client has non-standard requirements, for example, table formatting that your WYSIWYG editor cannot do (colspan is difficult), you should definitely find on the Internet a rare unsupported plugin without source code that will do the work for you. To write the same on your own - you spend almost a whole hour; it is better to spend three hours searching for a plug-in that does roughly, but not quite what you need. +1 in karma, if you can find a plugin that does not do what you need, but offers 15 MB + features that you do not need, but which cannot be removed. +2 karma if the documentation for this plugin is written in a language that you do not know.

# 7 - Never remove functionality

During the development of large applications, there are times when the functionality you have worked on is no longer required. To leave dead ends and labyrinths for those who will continue to work on this application, do not remove this unnecessary functionality. You can even comment out some small pieces, or even hundreds of lines of this code, in random order, but do not delete it. Imagine the hours of pleasant forwarding to the future team of this application, when they will unravel the tangle of your code and find that it is not needed at all! If you can do it in such a way that it looks like the code seems to be needed, but in reality it will not, your successor will be afraid to delete such code ... This will be fun! Ah, again, a bonus ... if your project uses version control tools and several servers, make sure that for each server and version control system - the file versions are different (both the sources and the binaries). So no one will know which version is in production, and who is reluctant to play Russian roulette on the production server?

# 6 - Fuck the performance

Large applications are usually used to work with large amounts of data. Of course, during development you will create 20 or so test records. I bet that there is not the slightest need to worry about what happens when you have 25 entries, or even 1000! Obviously, if you break the data into pages - everything will work fine and performance will always be excellent. So, if the application is compiled, feel free to give it to the customer!

# 5 - Shoot the core logic / functionality into loops

As we already noted in # 6 - we work with large amounts of data. And inevitably often will need to run through the data in the cycles. To make your application really hard to maintain, you need to embed basic functionality and / or logic inside loops. For example, instead of querying the database, drop all the data into memory and go through the data array in a loop, get all the data except for one field and run through it in a loop ... Then, in the next loop, you should get all data from the database, but this time include another additional field. This will guarantee that your application will fall from five concurrent users (Re: # 6). Fix the material: get the data> create a loop> get the data> work with the data. I am sure that this development will allow you to achieve complete idiocy, so do not hesitate to use this clever trick many times - as much as you want.

# 4 - do NOT document ANYTHING

Everyone knows that documentation is for morons. What I want to say is either you can read the code, or you can't, right? (this is exactly what was said to me in one conversation). CERTAINLY, the next programmer can read the code. It becomes interesting when you absolutely do not write comments, - what, why, why? Let them guess. You are mysterious as a ninja. No need for someone to know everything about what you were trying to do. Because if you wrote that you were going to do something, but in the end you did not do it ... well ... it is just inconvenient.

# 3 - Use illogical variable names

If you need a lot of variables to work on the application, you need to choose a movie or TV show with enough characters - you will use their names as variables. The Lord of the Rings, Star Wars and Family Guy is a great choice. Maybe you can even make friends with variables. Then you don't have to kill them! You can create chameleon variables - and then you can reset and assign them something new each time, when you need a variable for new functionality. They will grow and develop right before your eyes! Again, support Greenpeace and the Green Party - use a minimum of variables!

# 2 - Catch all the mistakes - and do nothing with them

Nowadays, most languages ​​/ platforms have a built-in error handling mechanism. If the program crashes, it leaves enough details through the standard error stream. But you can not leave it just like that! Start by packing each small piece of functionality into try / catch. And then inside ... catch insert a comment, like "/ / There is complete crap."

# 1 - Duplicate the functionality

If the client informs you that they need 2 pages: one for the administrator - where the product list with the delete button is in front of each product, and one for the regular user - the list without the “delete” button, you definitely need to create 2 separate pages. In fact, if you can make a separate page for each group of users, this is even better. Creating a separate page for each user is 100% success. Focus and get serious about it, as this is your last line of defense against a horde of skilled professionals who will inevitably be puzzled to try to improve a carefully designed Pandora's box inside your application.

This is by no means an exhaustive list. Only on this project I could name 10 more slop things. This time I will leave 10. Who wants to add a couple more points?