Ask HN: How do you write code so it's easy to change?

To add to the list - I just watched this great video on composition vs inheritance: https://www.youtube.com/watch?v=wfMtDGfHWpA

Here is my personal checklist:

* If in a loosely typed language go way out of your way to ensure conventions are in place to identify things by data type. TypeScript has completely changed how I look at JavaScript particularly its use of interfaces for defining objects and data structures.

* Limit your use of dependencies as much as possible. In my current personal project I am down to 1 dependency. Dependencies will weigh a project down and prevent nimble shifts of direction. This also includes frameworks and tools.

* Write good documentation and keep it up to date. Automate the authoring of documentation where you can so that it stays up to date with less manual intervention.

* Isolate concerns as much as possible so that a feature can be deleted and replaced with as little effort as possible.

* Keep things simple. This requires lots of extra effort both in planning and refactoring. When there are fewer pieces and everything is as uniform or consistent change requires far less effort and leaves far less dead code in its place.

* Don't abstract things for convenience or easiness. Abstractions are incredibly helpful when they result in simplicity (fewer pieces and fewer ways of doing things). Absolutely don't use abstractions as a means of being clever or for vanity reasons. Then you just have extra code and the larger a project gets the harder it is test and change.

* When other people want to impose their opinions on you push back until they come back with test automation and/or strong provable evidence of a better way of doing things. If they still try to impose their opinions on you, and this will happen, kindly tell them to go fuck themselves. So much of the stupidity in programming comes from baseless irrational subjectivity.

* Test automation. Its not about how you test, but about what you test. There is a lot of nonsense out there about how to test. In my current personal project I have automation in place for code validation, compile checks, command tests in the terminal, service tests. Soon, as I figure it out, I will be adding test automation for user interaction and user data storage. However you are able to execute all the kinds of tests you need just do it. The goal is to promise your software can deliver a feature and prove it with test automation and then add more tests later to cover for edge cases you did not consider.

Most of the responses focus on how you meet the current requirements. However, the most important thing to know is not actually about current requirements, but future ones.

Sure you can assume that all the requirements will change, but then you’ll need to make a system so flexible it becomes a nightmare to do anything (just look at JIRA or other software like it, with 100 configuration options for every piece). These systems require vast resources to maintain because there is so much code to make it flexible.

You can also assume the requirements won’t change at all, tightly following the spec and optimizing all the edge cases so you have a pristine black box no one can touch.

Finding the happy medium involves knowing which assumptions are likely to change, and which aren’t. Usually, languages won’t change often, so you can rely on most of those features. Certain well-maintained libraries and APIs won’t change much, so those can usually be baked-in too. The business logic around things like pricing, users, analytics, data visualization, and data processing are likely to have changes. My favorite one for web apps with databases is search. The filters very often change and grow, so getting a highly flexible search working is usually a big win for not too much effort.

Note, I’ve never said always. If you can get knowledge about the business needs you’re supporting, you’ll have a much better idea of which things need flexibility, and which things don’t. The longer the roadmap on a project, the more wins you can get when architecting systems too, as you can set yourself up for easier implementation of future features.

I agree with this, but I'd like to add one more thing. No matter what you do, if you find that your code is hard to change, then change it so that it is less hard. Next time you visit it, change it again. Keep doing this until it is very easy to change the code. Write enough test support in your code that you can do this kind of work safely.

> Less code, loose coupling. Do one thing and do it well. Keep the external API simple.

> It's always easier to change a small thing instead of a large thing. So make a small thing, and only make it a big thing if you absolutely have to.

this is along the lines of what i was going to suggest. i prefer to code everything such that it does just one thing that is appropriately at the level or context it sits at.

a function should just do one thing and have reliable outputs based upon inputs. a class should represent one thing. class methods should do one action. modules should collect functionality that does a thing. processes and servers should do a thing. and so one. if you build your system out of things only doing the thing they say they do, then it becomes clear when they're being changed in incorrect ways.