Skip to content

Instantly share code, notes, and snippets.

@ashleygwilliams

ashleygwilliams/modularity.md Secret

Last active September 7, 2016 08:19
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save ashleygwilliams/79029d9d36804ad2c37a633062591618 to your computer and use it in GitHub Desktop.
Save ashleygwilliams/79029d9d36804ad2c37a633062591618 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
modularity.md

  • npm stats

  • npm is HUGE

  • the problem with software is misconceptions

  • a brief history of timefinte regress

  • space turtles

  • what is modularity

  • how is modularity

  • why is modularity

  • it was interesting that no one considered that the universe might be growing or shrinking

  • My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger. Dijkstra (1988) "On the cruelty of really teaching computing science (EWD1036).

  • [Start] with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others. D. Parnas

  • Unfortunately, some problems are more intertwined and hard to separate than others. Although the single responsibility principle suggests that ‘each module should only handle one hard problem’, it is more important that ‘each hard problem is only handled by one module’ TEF

  • HTTP has examples of loose coupling too: Putting a cache in front of your HTTP server. Moving your images to a CDN and just changing the links to them. Neither breaks the browser. HTTP’s error codes are another example of loose coupling: common problems across web servers have unique codes. When you get a 400 error, doing it again will get the same result. A 500 may change. As a result, HTTP clients can handle many errors on the programmers behalf.

  • Error handling, and recovery are best done at the outer layers of your code base. This is known as the end-to-end principle. The end-to-end principle argues that it is easier to handle failure at the far ends of a connection than anywhere in the middle. If you have any handling inside, you still have to do the final top level check. If every layer atop must handle errors, so why bother handling them on the inside?

  • stadium example about complexity and information

  • It isn’t so much that you’re iterating, but you have a feedback loop. It is not so much you are building modules to re-use, but isolating components for change. Handling change is not just developing new features but getting rid of old ones too. Writing extensible code is hoping that in three months time, you got everything right. Writing code you can delete is working on the opposite assumption.

  • design is fundamentally taking things apart. taking things apart in such a way that they can be put back together R Hickey https://www.infoq.com/presentations/Design-Composition-Performance

  • this is really step 1

  • when was the last time you thought about something for an hour? a day?

  • people get good at what they practice, whatever it is that they practice

"all problems in computer science can be solved by another layer of indirection"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment