So breaking things up aggressively into small components you can reason about in isolation tends to be the best way to write reliable code you can maintain over time.
This is so true. Something that has really improved my coding has been having a linter that whines to me about assignment branch condition size. Compared with learning how to properly stub methods in tests it has helped me break tasks down into simple manageable chunks with little room for error.
I find it’s also helpful to explicitly think about high level flow in the code. There are typically two types of code in an application. There’s routing code that figures out where the payload needs to go, and then there’s the code that actually cares about the content of the payload. The routing code can be thought of as sort of a railway where you ship packages around. When a package gets to a destination then you pass it to the code that knows what do do with it.
Nowadays, I really like to draw it out as a state machine before I start working on the code. When you just start coding, it’s very easy to focus on the happy path and then you end up having to start kludging handling of exceptional cases as they come up. When you sketch out the state machine, it forces you to consider the error cases up front. You don’t have to handle them right away, but the design should account for them at the very least. This is an excellent read about this approach https://shopify.engineering/17488160-why-developers-should-be-force-fed-state-machines
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programmerhumor@lemmy.ml
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.
This is so true. Something that has really improved my coding has been having a linter that whines to me about assignment branch condition size. Compared with learning how to properly stub methods in tests it has helped me break tasks down into simple manageable chunks with little room for error.
I find it’s also helpful to explicitly think about high level flow in the code. There are typically two types of code in an application. There’s routing code that figures out where the payload needs to go, and then there’s the code that actually cares about the content of the payload. The routing code can be thought of as sort of a railway where you ship packages around. When a package gets to a destination then you pass it to the code that knows what do do with it.
Nowadays, I really like to draw it out as a state machine before I start working on the code. When you just start coding, it’s very easy to focus on the happy path and then you end up having to start kludging handling of exceptional cases as they come up. When you sketch out the state machine, it forces you to consider the error cases up front. You don’t have to handle them right away, but the design should account for them at the very least. This is an excellent read about this approach https://shopify.engineering/17488160-why-developers-should-be-force-fed-state-machines