Working Notes: a commonplace notebook for recording & exploring ideas.
Home. Site Map. Subscribe. More at expLog. — Kunal

How To Engineer Program Write Extensible Code

Generation
- A little bit of voodoo: realized while trying to explain to someone else
- write code in a way that it /can/ be easily extended
  - without actually making it extensible yet
- Imagination is generally much worse than reality
  - can lead to factory factory beans
  - don't do that
  - see also YAGNI
- keep the code simple, to the point, and with minimal abstractions
  - use abstractions for reasoning
  - but leave it possible to write abstractions in the future
- invisible "seams"
  - from dealing with legacy code
- the trick is to constantly decouple code
  - I like to personify my code
  - Does this module need to know that the color of the sky is blue?
    - don't pass it in
    - if it must be passed in, mark it as unused
      - alternatively, extract a function that explicitly shows it's unused, arguments notwithstanding
    - at the very least, group the lines of code in a way to make this more obvious
- Add a comment indicating this is a seam
  - if you do it well enough, people will ask you to introduce the abstraction
  - it becomes /obvious/, which is very hard
- not all seams will be used
  - but they make it much easier to code well
- writing functionally, isolating cause, effect, data transforms, etc. all contribute to decoupling
  - also makes it much easier to unit test
  - / aside: testing is excellent because it helps you understand and navigate your code
    - but don't contort your code aggressively to be able to test
    - eg. dependency injection has never been particularly satisfying
    - functional layers? might be much cleaner as an approach