The real world one: No one. That's the beauty of code. First of all, "code quality" is a subjective thing. What's good code to me might be bad code to someone else and vice versa, so it's always kinda delicate to blame someone. Also, this "someone" is not always known and also, not always reachable (example: someone who left the company your work for). Anyway, it makes it hard to know who is responsible and even when you know, there nothing you can really do.
Time is one culprit. Patches and enhancements get done over several years. The application becomes absolutely essential to business operations. Attempts are made to replace it with a more modern language but fail for one reason or another. So, a company is left with a poorly designed and written application in a semi-dead language, like VB6, ColdFusion or Powerbuilder,that can't be easily replaced. That means someone is going to be stuck maintaining it.
Inexperience is another factor. For example, a subject matter expert with limited programming experience may have originally written the program, learning as they went. When professional developers are brought in eventually they will probably have a mess to clean up.
If the business is depending on the application that has bad code and it needs to be fixed or enhanced, you just have to get it done as best you can. Since you probably won't have decent regression tests, much less unit tests, you have to be very careful about making any huge changes, like a full refactor.
For example, today I had to deal with an old VB6 application. A small change someone else had made broke another part of the application. It took about 4 hours to track the problem down. I had to implement a fix that would correct the problem without breaking the change that caused it. Eventually, we will replace this app with a new one that uses microservices and a good design pattern. But, until then, we have to be very careful with it.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Another silly question. Who could be responsible for dirty code?
Again, double answer:
The easy one: whoever wrote it.
The real world one: No one. That's the beauty of code. First of all, "code quality" is a subjective thing. What's good code to me might be bad code to someone else and vice versa, so it's always kinda delicate to blame someone. Also, this "someone" is not always known and also, not always reachable (example: someone who left the company your work for). Anyway, it makes it hard to know who is responsible and even when you know, there nothing you can really do.
Haha.
If you are leader, what would you try to avoid the dirty code just you think in your team?
Time is one culprit. Patches and enhancements get done over several years. The application becomes absolutely essential to business operations. Attempts are made to replace it with a more modern language but fail for one reason or another. So, a company is left with a poorly designed and written application in a semi-dead language, like VB6, ColdFusion or Powerbuilder,that can't be easily replaced. That means someone is going to be stuck maintaining it.
Inexperience is another factor. For example, a subject matter expert with limited programming experience may have originally written the program, learning as they went. When professional developers are brought in eventually they will probably have a mess to clean up.
What could you do when you are required to deal with them?
If the business is depending on the application that has bad code and it needs to be fixed or enhanced, you just have to get it done as best you can. Since you probably won't have decent regression tests, much less unit tests, you have to be very careful about making any huge changes, like a full refactor.
For example, today I had to deal with an old VB6 application. A small change someone else had made broke another part of the application. It took about 4 hours to track the problem down. I had to implement a fix that would correct the problem without breaking the change that caused it. Eventually, we will replace this app with a new one that uses microservices and a good design pattern. But, until then, we have to be very careful with it.