Your Web News in One Place

Help Webnuz

Referal links:

Sign up for GreenGeeks web hosting
September 26, 2021 11:35 am GMT

Reasons behind bad Software code (Technical Debts) and Refactoring

Bad code haunts everyone sooner or later troubling the ones who wrote it along with the whole team.

Every developer in the world tries to write better and efficient code. I don't think that there is anyone who writes bad code deliberately.
Then why do we still get software and codes? 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

  • Bussiness 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 of 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 doesnt know how to write decent code.

  • Lack of knowledge sharing among team memebrs

When developers don't share their understanding of project with team mebers, it becomes lamost impossible 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 or kludges. 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, the greater the total technical debt.

  • 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.

  1. When you are writing code for the 1st time, just get it done.
  2. When you are doing something similar for the second time, keep refactoring thought in mind but anyways get it done.
  3. 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 because it will be very easy for other people to understand and use it.

  • When fixing bugs

Clean your code, you will automatically fine bugs.

  • During code review

This is last and probably the most important part of the refactoring process because 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.

Original Link: https://dev.to/tastaslim/reasons-behind-bad-software-code-technical-debts-24f8

Share this article:    Share on Facebook
View Full Article

Dev To

An online community for sharing and discovering great ideas, having debates, and making friends

More About this Source Visit Dev To