Bad code haunts everyone sooner or later troubling the one who wrote it along with whole team.
Every developer in the world tries to write good and efficient code. I don't think that there is anyone who writes bad code deliberately.
Then why do we still get bad softwares? Let's look at few reasons for bad code going to production which is generally termed as Technical Debts.
Think of a scenario where you took money from someone on interest, for that time being it solves your problem, right.
But eventually, you have to repay that money to a person with interest. Sometimes, we delay so much in repaying money that the amount of interest gets higher than the actual money which we took from a person which makes it impossible for us to repay the money.
The same is the case with software development, you write bad code, and keep on shipping it to production and since you were not focusing on improving the code, there will be a time when it becomes impossible for you to refactor/improve your code.
Reasons of technical debt
- Business Pressure
Sometimes business pressure forces us to ship unfinished code to production. To make it work, we do some patches here and there and hides them. But this will come back haunting us.
Don't do this, it is okay to get delayed sometimes instead of shipping bad code to production because in a long time it will cost more money and effort to improve it.
- Developers not taking technical debts seriously or don't understand the importance of it
This is one of the most common cases, I have seen while working at various companies, many developers don't take these things seriously, for them working code is sufficient.
This becomes almost impossible to refactor and improve the code because your employer does not value it.
- Lack of Documentation
Documentation is one of the most important aspects of software development. It doesn't matter how good code have you written, if other developers can't understand, contribute or use it. We must write a good documentation explaining every aspect of your code so that others feel, it is easy to use and they don't need to ask you everytime.
- Incompetence
When the developer doesn’t know how to write decent code.
- Lack of knowledge sharing among team members
When developers don't share their understanding of project with team members, it becomes almost impossible, specially for junior developers to work on it. They work in dark all the time and eventually create problems for themselve as well for whole team.
- Lack of tests
The lack of immediate feedback encourages quick, but risky workarounds. In worst cases, these changes are implemented and deployed right into the production without any prior testing. The consequences can be catastrophic. For example, an innocent-looking hotfix might send a weird test email to thousands of customers or even worse, flush or corrupt an entire database.
- Working in Isolation
This can lead to the accumulation of technical debt, which is then increased when changes are merged. The more changes made in isolation(in your respective branch), the greater the total technical debt because it can cause merge conflict, it is very hard to review it.
- Lack of compliance monitoring
This happens when everyone working on the project writes code as they see fit. There must be a guideline to follow while writing, documenting, testing and deploying the code.
When to refactor your code
Follow rules of 3 for this.
- When you are writing code for the 1st time, just get it done.
- When you are doing something similar for the second time, keep refactoring thought in mind but anyways get it done.
- when you are doing something similar for the third time, start refactoring it.
- Adding new feature
While adding new feature into someone else dirty code, first refactor it and then add new features. It is very easy to understand clean code and add new features into it.
- When fixing bugs
Clean your code, you will automatically find bugs.
- During code review
This is last and probably the most important part of the refactoring process. After this your code will be going to production. It is always best to do code review in pairs, make sure author is present.
How to refactor
- Make sure after refactoring your code should be cleaner than previous on and still all features are working. If code is not cleaner, you have just wasted your time.
- Make sure you have a good understanding of the code you are refactoring.
- Make sure while refactoring, no new functionality should be added in your code. Refactoring and adding new feature are two different things. Once you complete refactoring, then you can add new features.
- Make sure all previous test cases are passing after refactoring.
Top comments (2)
Taslim. Can you please elaborate the point of working in isolation. As while merging, if there are defects - then it can be taken back as we know after merging - which branch is causing problem to the whole application.
Hey Shubham, thanks for the question.
the point of working in isolation means:
In a team, there can 10s or 100s of engineers working and making their respective changes to respective branches, right? Lets say, you are working on a feature which takes 4 weeks and other engineer's work took 2 days , 5 days, 1 week etc. They will be merging their branches to respective CU/sprint push and your branch would be behind multiple commits, all of the sudden you merge your changes and it creates merge conflicts or overwrites the other previous changes, it would become a mess and will take heck lot amount of effort to fix these. You would need to check who made what changes in what branches. Obviously, in a small. team you can manually fix these but. as team size increases, it becomes difficult