How do you make your code maintainable?

Comments

[Derek Hopper]

The short answer is practice.

The long answer is you can never be perfect. There will always be times you create technical debt. I struggled with articulating an answer because the question is naturally broad (not your fault). I don't know if a complete answer can be written. BUT, here are two ideas I've found to be important.

• Have clear boundaries between modules. In an application for a sandwich shop, you might have a Billing and a Cooking module. These modules may work together, but Billing should never dictate how a sandwich is prepared.
• In order for modules to work together, the modules must have a public interface. Think about this interface because it's an important step of design. We tell the Cooking module to make a sandwich. We don't need to know the ingredients - that's the Cooking module's job. When the sandwich is ready, we tell the Billing module to give us a bill for the sandwich. We know nothing about promotions, coupons, or how the customer is paying us.

A good test is asking yourself how you might implement a new feature. If you need to change how something is cooked and the Billing module requires a change, something is wrong. This gives you a chance to change your design.

I hope that helps start a dialogue. Design is ongoing and never finished. The best we can do is try to keep things as simple as possible.

By the way, I highly recommend reading martinfowler.com. It's a great resource on design. Here's a particularly timely example of how to refactor a bit of code to make it more maintainable: martinfowler.com/articles/refactor...

[Franco Scarpa]

Thanks Derek. I didn't expect to get a complete and precise answer. I know how vague but at the same time simple a question like that can be. What I wanted to know was how you struggle to make your code maintebable. Your answer helped me. Among your points, interfaces are what my boss want me to master. Your point about them was so valid.

[perpetual . education]

The smaller the thing - the easier it is to maintain it! 1 orange tree? Pretty easy. 10 orange trees? More work... but at least the same type of work.

If interface and functionality can be put into little groups, then it's easy to maintain and update - for anyone on the team.

So, whatever you use to generate DOM: PHP, JavaScript, Django, Vue, Ember - etc., you can keep things really lean with a few decisions on code-style. That's what works for us! Much lager systems will certainly add complexity - but the same idea applies.