I work as a web developer in the startup industry. I've heard many times that code should be extensible – that it should be easy for engineers to make changes to the system in the future, especially as a product finds market fit. What tips would you give other engineers on writing easy-to-change code?
Ask HN: How do you write code so it's easy to change?
1–10 of 78 posts
Re: Ask HN: How do you write code so it's easy to change?
#2Keep it short and succinct.
Re: Ask HN: How do you write code so it's easy to change?
#3Don't repeat yourself.
There is an objective way to tell if design A is better than design B, and that is to measure how hard it is to make changes. You have to build that into your culture and not optimize for something else, or do things because somebody thinks that is the way to do it.
A big problem in current architectures is that what seems to be a small change (say, add a "cell phone" field next do a "home phone" and "office phone") field often requires a number of little changes in widely separated code:
* a database schema change * changes to database queries * changes to a back-end API * changes to a front-end Javascript app * changes to an iOS mobile app * changes to an Android mobile app
Conventional system design means that what looks like one change to management is actually at least six changes, which might affect that many source code repositories, etc.
An ideal design would let you create a feature by writing all of your code in one place. Of course this would require a big change in how applications are structured and built, but it could lead to a durable advantage. See
https://en.wikipedia.org/wiki/Software_product_line https://en.wikipedia.org/wiki/Feature-oriented_programming https://en.wikipedia.org/wiki/Low-code_development_platform
The biggest barrier to the above I think is that when you talk to a team they always have shiny objects that they can't live without. Maybe they think functional programming is great (yeah, you can handle errors with monads, but you can drop errors on the floor just as easily as you can with exceptions, return codes, etc.) or that immutability solves everything, JDK 13 is the best, whatever. So people are thinking about everything except the thing that management will care about which is long-term sustained productive development.
Re: Ask HN: How do you write code so it's easy to change?
#4Whole books have been written about this. I use the following rules from [1] myself. I like them because they definitely put some constraints on my coding which I like. It forces me to think beforehand and gives me (a junior developer) some guidance which I desperately need:
* Write functions/units that are * Create units with * Write functions/units with These guidelines force you to write maintainable code. Always open for discussion. Note that these lessons are lifted straight from [1].
[1] https://www.softwareimprovementgroup.com/resources/ebook-bui...
Re: Ask HN: How do you write code so it's easy to change?
#5Separate interface from implementation. [1]
[1] https://en.wikipedia.org/wiki/Interface_(computing)#Software...
Re: Ask HN: How do you write code so it's easy to change?
#6Write code for use not for reuse.
Write code that is easy to remove, not code that is easy to change.
Re: Ask HN: How do you write code so it's easy to change?
#7Be as explicit as possible. Use guard clauses. Don't couple things for the sake of less code. Very, very often, repeating yourself is OK.
Re: Ask HN: How do you write code so it's easy to change?
#8Don't repeat yourself. There is an objective way to tell if design A is better than design B, and that is to measure how hard it is to make changes. You have to build that into your culture and not optimize for something else, or do things because somebody thinks that is the way to do it. A big problem in current architectures is that what seems to be a small change (say, add a "cell phone" field next do a "home phon…
> Don't repeat yourself.
And also do repeat yourself. Consistency (patterns) are a factor in reducing errors.
Re: Ask HN: How do you write code so it's easy to change?
#9If this were an easy answer, software devs would not be paid as much. Read some books about the topic, then write a lot of code, then change a lot of that code, and learn from your experiences regarding what was easier or harder to change.
Re: Ask HN: How do you write code so it's easy to change?
#10You're going to get a bunch of extreme platitudes in response to this question.
Like "DRY", "YAGNI", SOLID, short vs. long functions, how to test, minimizing vs. maximizing reuse, static vs. dynamic typing, cyclomatic complexity, interfaces, functional programming, immutability, etc. You should definitely be familiar with these principles and their tradeoffs.
My advice though would be to take them all as suggestions, not absolutes, and to look at your specific requirements of your project, what you know about it and your customers (how it's likely to evolve over time, how it has already evolved, how your company will evolve, who the engineers are, etc.), and then find & adjust the principles that apply. There are no silver bullets here, and which techniques are successful depends very much on the context in which they're used. Work backwards from your team, your situation, and your customers.