Anyone can write as much code as they want, but only a few developers write well-maintained code. As a developer, I have written bad code in the past, got a few bugs, and later realized the importance of clean code. On this journey, I understood that if we don't write maintainable code, it will be a loss for the company in the long run.

How?

When production issues arise, if other developers can't understand your code or if your code is not simple enough, it will cost the developer time and money to fix the critical bugs.

By following simple tricks, we can make our code base clean and more readable.

• Don't write huge, monolithic functions. Instead, you can have simple linting rules to avoid unmaintainable code.

  Ex: Your function code shouldn't exceed more than 30 to 40 lines. How will it help? While doing code reviews, we can easily catch bugs if our code is segregated into small functions. => We can easily write unit tests. One can easily avoid deep-nested if-else logic.

• By moving repeating code into a utility or separate function, will be a starting point for writing better and more modular code.

• Write enough debug logs; this is a great technique that comes with experience. We should know what to log, where to log it, and how to use the log data.

• Unit testing and code coverage (some people argue with this; you can have meaningful coverage and have more scenario-based automation in place): Bread and butter for a developer.

• Use CI/CD for deployments. (Pipeline should meet thresholds for unit tests, integration tests, and security scans.) In my personal opinion, Developers should start learning how to build devops pipelines to become more productive and avoid unnecessary delays (maybe devops can design pipeline patterns and developers should be able to quickly create and run pipelines).

• Spend a good amount of time documenting your API's. Developers should communicate through API's.

• If something is not ready and you think requirements can change, do not implement actual logic. Go with the mock implementation (API), read data from the mock API, and follow this for a few iterations. Once everything looks good, replace the mock with the actual implementation.

  Advantage: Everyone will be happy after actual implementation. No duplicate work

• 50% of the time, we will be working on the code written by other developers. Respect other developers' code and start refactoring if you see you understand the code and write it in a better way.

• Don't fit design patterns into the codebase just for sake. If there is a real benefit and a specific design problem, you are solving it using a design pattern. Design patterns are great tools to solve complex problems.

• Exception Handling: Do not catch the parent exception; instead, catch the specific exception. And handle exceptions inside your function. Do not skip by thinking that the caller will always handle and pass good input.

• Introduce good naming conventions; everyone should adhere to these rules while pushing the code. Have two-level code reviews and do not compromise on code quality.

• Test your code on your own before handing it over to QA or a tester. Focus on edge cases and different input types, and try to break the code.