Encapsulate the concept that varies.
Ask HN: How do you write code so it's easy to change?
31–40 of 78 posts
Re: Ask HN: How do you write code so it's easy to change?
#32Lots of comments here on keeping this as simple as possible and not over-architecting. This is a good value, but its equally important to add architecture and abstractions before its too late. Software projects become tangled spaghetti messes slowly, over time, by adding "just one more thing" to existing modules and functions until they are large and impossible to fully understand. My simple rule of thumb is this - no file should be longer than 300 lines of code and no function should be longer than 15 to 20 lines of code. If your file or function is longer than these guidelines, its trying to do too many things and its time to break it down.
Re: Ask HN: How do you write code so it's easy to change?
#33Assume the code is going to be changed by first semester CS students. Dumb it down as much as possible. Don't do any clever tricks. Make the patches as small as possible so they can be (i) easily reviewed and (ii) allow easier bisecting. Example: if a computation requires some intermediate value, create a new variable with a proper name and assign the intermediate value to it, instead of just inlining it in a bigger…
This and include conversational comments that explain in plain terms what problems you're solving and why.
Re: Ask HN: How do you write code so it's easy to change?
#34Separate policy from mechanism. [1] I usually reframe this as separating the what from the how. Back in the 80s and early 90s people would commonly call this "data driven design" (this is distinct from "data-oriented design" which lives more in the how).
One area you can quickly see this in action is with user interfaces. So many modern applications construct their UI tediously by coding each component and all of the aggregations by hand. If you take a step back, it's usually very easy to see that the configuration of the UI is just data. Why not just build one layout "engine" and feed it data to generate your UI? The engine part can use whatever hotness you like, but you only have to write that code once. The configuration of the UI (the policy) is what changes frequently (the business requirements); not the mechanism underneath. (This doesn't mean you won't have to change the mechanism, you will. It just requires change at a much slower pace and the changes are bound within the context of the mechanism itself.)
This approach separates layers of a system which have different change vectors and velocities. The mechanism tends to have a much lower rate of change and it's where we programmers like to live. Build tools for "the business" -- whatever that means in your context -- so they can maintain as much of the policy as possible.
If you think through designs like this; however, you will realize that our modern fascination with massive "scaling" of teams is no longer attractive. This may explain why it has fallen out of favor.
[1] https://en.wikipedia.org/wiki/Separation_of_mechanism_and_po...
Re: Ask HN: How do you write code so it's easy to change?
#35Only write code that's absolutely needed for what you're building. It's very tempting to make it "extensible" by overgeneralizing. What you get then is overly complex code, most of which is never used. Cut out everything that isn't currently used, and you have a small system where every line pays for its keep.
Agreed - and note that this principle is in tension with the junior/intermediate (heck, even senior) urge to make things "easy to change" by just making everything abstract and configurable. ("See, now if we want to do it this other way in the future, we only have to flip this bit!")
I still haven't found a pithy way to describe the limitations of this principle. Obviously, frameworks are helpful and also fail this principle, so even this principle has exceptions. But are you going to be so arrogant to believe your abstract extensible change will be adopted by all your fellow teammates in the future?
Re: Ask HN: How do you write code so it's easy to change?
#36try to anticipate where the code may have to change, and with what frequency. For example how likely is it that a modification to handle new file specification will be required, or how often would you have to integrate new authentication methods. how often would you need to give things a facelift to keep up with marketing trends.
Re: Ask HN: How do you write code so it's easy to change?
#37Beyond having good testing, don't try to write it to be easy to change, write it to be good code.
You should try to express problems elegantly, and that will help make some changes easy. That's nice when that happens, and it does happen quite a bit. But many changes will still not be straightforward.
Generally, write the code to do what it's meant to do, and when it needs to change, rip it out and rewrite it.
It's shockingly easy to write something that's concrete and later realize "I need two of these" and then quickly factor out the common functionality.
Especially, don't kludge things. The problem with "easy to change" is it means "easy to kludge just one more feature on here." That won't remain easy to change. Refactor aggressively and your code still won't be easy to change, but it won't become a kludgey mess that's hard to change, either.
Re: Ask HN: How do you write code so it's easy to change?
#38Optimise code for Deletion.
If it's easy to delete, then it's easy to replace.
And if it is easy to delete then it should be naturally loosely coupled.
Re: Ask HN: How do you write code so it's easy to change?
#39The answer to your question is essentially the entire field of software architecture and to some degree even software engineering itself.
Thus there aren't many simple always-applicable tips. Every tip requires experience to know when you apply it. Any tip that doesn't require that experience ends up not accomplishing much.
Keeping things simple is good. But sometimes you do need some abstractions, scaffolding, and structure that sacrifices simplicity but enables the code to grow.
Tests are good. But sometimes code can be so heavily tested that changing the tests themselves is a large maintainence burden when the requirements change.
Abstraction and encapsulation are good. But both add complexity and raise the amount of code someone has to load into their head to understand what's actually happening.
Documentation is good. But writing good docs itself an artform, and docs that aren't maintained well can cause more harm than good.
The best advice I can give is to not seek out "tips". Just work with the best engineers you can find, write code, reflect on it, and trust that your experience and intuition will grow over time. There is no shortcut to mastery.
Re: Ask HN: How do you write code so it's easy to change?
#40A lot of people say "You could write this X/Y block in one line" or "You can simplify this".
A lot of the times they don't mean simplify, they mean compact code.
I write verbose code, as explicit as possible. Sometimes it looks like it was written by someone just learning to program. And that's on purpose to make the code as easy to understand and change as possible.
TL:DR: Be skeptical about code "simplification" and don't fall on using fancy language features when if/else conditions do the job.