You may need to handle some code not written from you. Some may be very dirty and make you extremely depressed.
What would you do when you see these code?
- Rewrite
- Skip
- Tell your boss. Some codes are dirty.
If you are leader, what would you do to avoid dirty code?
I like that :-)
Easy answer: skip. I don't want to work with dirty code and no one does.
Real world answer: It depends on the context. Chances are, if you come across dirty code as a part of your job, you won't be the one choosing what to do with it. Sometimes your boss will tell you to rewrite it, sometimes to keep working on it as is, etc...
And even when you don't have a boss (or you are your own), you might not always have a choice, sometimes you won't have the time and/or the means to rewrite every "dirty" code (also, that's partly a subjective opinion) you see and you will have to work with it if you can't afford to ditch it completely.
Another silly question. Who could be responsible for dirty code?
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.
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?
When I see a dirty code, I take judgement call.
Can I fix it as part of the current scope without the risk of breaking something? If yes, I fix. If no, I skip it.
I have never used option 3 since my boss knows the code is all dirty and which is why I was hired 😁
If you are leader, what would you try to avoid the dirty code just you think in your team?
Focus on your review process. If something can be written better, documented better, those things needs to be handled before the code gets promoted.
Sadly. It require resource.
I may find a chance to test it
If you are looking for quality software, you need to be ready to make the investment. Else spend money on a unmaintainable pile of spaghetti code, which will end up becoming your achilles heel.
It depends on the amount of time I'm given. If I have enough time left from another task or am being told to refactor, I'll refactor it.
If it's just badly formatted, a quick Ctrl+Alt+L (PHPStorm Shortcut for reformatting code) only takes a minute.
Only if it's really bad and/or potentially dangerous. I'm always asking other devs about dirty code, but in a nice non-confrontational way.
PS: I really like refactoring code, it's like house cleaning, makes you feel better afterwards.
Rewriting is tricky because you're unlikely to know it well enough to make sure you replicate all of the important functionality. In fact, the messiness of the code makes it harder for you to understand it well enough to rewrite it. Plus rewrites take a lot of time!
Skipping is actually a pretty solid option if you don't need to change the code. The code may not be great, but if it's doing its job and you don't need to modify it to fix bugs or add features then by all means just leave it be.
Telling your boss doesn't necessarily help, but might be helpful if it means you can secure extra time to clean it up while you're working in it.
In my experience, the best approach is to clean it up as you work in it, making lots of small, safe refactors. Hopefully it's under test, but if not then you can start writing tests for the parts you're working on so that you can more safely and aggressively refactor it. Eventually you can get the system under control and totally clean, but it takes time and elbow grease. And getting it totally clean may not even be the right investment for your company to make. So often times it's good to spend some percentage of your time cleaning it up as you add features or fix bugs. Alternatively, you can invest time in fully cleaning up just the parts you need to modify for the work you're doing. That way you're not spending time cleaning up code unnecessarily and the parts you're changing are well-factored and easy to work with.
It's also worth noting that many developers (myself included) can get personally invested in their code. So if you have to work in someone else's dirty code then it's worth investing in building a relationship with them, asking about how they'd change the code, and starting with small changes to build trust before moving on to larger refactors.