How can you write maintainable code?

Use design patterns and SOLID principles to make your code reusable, flexible, and easy to understand. See how other developers have solved similar problems by reading some opensource code. Keep it simple and avoid writing complex code. Write simple, modular code that is easy to read and maintain Document your code and write test cases to ensure that it works as expected. Include inline comments and class level comments. follow practice to write well formatted and easy to read code. Get it reviewed by peers and have open discussion with your peer colleges and be open for change and suggestions.

"The nice thing about standards is that you have so many to choose from." — Andrew S. Tanenbaum Coding standards can make code easier to read and understand, except when a solution is hard to read and understand and the standards make it even more difficult. Don't be a slave to standards. A written explanation can be key to understanding so don't hesitate to include a description of the solution rather than hoping the formatting and naming conventions will make the code "self-explanatory." A picture may be worth a thousand words but a well-written paragraph can describe things that can't be seen. And if the implementation of the solution should change over time don't forget to update the explanation as well.

Following coding standards and writing the simplest code that works allows a new developer to more quickly absorb the existing code. This increases your access to the manpower necessary to maintain your code. Most IDEs have a formatter and/or linter built in, or accessible through a plugin. Pick one and spend zero time fighting the IDE. The goal is uniformity, not to address the flavor of the day.

Engineering and Simplicity are often in opposition and require you to carefully balance the trade-offs. You can write extraordinarily simple two-line methods that address interfaces eight deep. Think long and hard before adding architectural or engineering features that trade simplicity for value that is indirectly related to the goal of the project; Especially if that engineering feature is masquerading as simplicity itself.

- Accept that you cannot stop your developers from using the latest & greatest framework versions & syntactic sugar constructions. - To keep your core project code simple & clear - provide developers with an R&D playground, and plan a PoC project where they can have fun and exercise skills. Strive for Win-Win situations.

- allow code refactoring only if this activity is connected with technical debt, performance issues, etc. - code improvements are dangerous because developers can also change SDK/Package versions, which can introduce new nasty bugs - most of the code will be dropped and re-written from scratch in 3-6 years because of company acquisition, product, or platform breaking changes.

Here there be monsters. An unskilled hand here can remove all progress. Refactoring is *sometimes* necessary. Just think about how hard it would be to use a reference book if the paragraphs kept changing their order, content and relationships. Instead, review old code semi-regularly, to ensure that it does not rot. Check it against current or new practices on the project, understand the value proposition of a refactor, and make a decision. Try to avoid hearing the conversation "oh yeah, that code does it the old way...".

Unit test, E2E Tests, Integrations test are the the most crucial approaches to make your product predictable and maintainable. One of my ex-colleague was saying: Easier and faster to catch errors in Prod(That is why he is "ex") But avoid Unit tests, etc in startup products with fast changes cycle. It will slow down your development and time to market

I will add to Andriy's perspective that with the rise of ChatGPT & Copilot, you need to review Unit tests carefully, assuming they are auto-generated. You can have coverage around 90%, but the quality of those tests could be awful.

In my opinion, in any long-lived piece of software, separation of concerns and modularity are of primary importance to maintainability. If you need to change your code in the future, you should be able to make that change, test it, and deploy it, without inadvertently impacting the rest of the code base. Everything else is a "nice to have".