Prefer If Statements To Polymorphism...

Or, Watching Myself Lose My Mind In Real Time…

“Invert, always invert.” –Carl Jacobi, by way of Charlie Munger

• If Statements

  prefer if statements to polymorphism

  whenever you are tempted to create a class, ask yourself: “could this be an if statement instead?”

• The Closed/Closed Principle

  In grug-oriented programming, the closed–closed principle (CCP) states “software entities (classes, modules, functions, etc.) should be closed for extension, but also closed for modification”

  they should just do something useful man

• The Minimize Abstractions Principle

  The Minimize Abstractions Principle (MAP) is a computer programming principle that states that “a module should minimize the number of abstractions it contains, both in API and in implementation. Stop navel gazing nerd.”

• The Try It Out Substitution Principle

  The “Try It Out” Substitution Principle states that you should try something out and, if that doesn’t work, think about why, and substitute something else for it instead.

  It is common to need to substitute multiple things to hit on the right thing eventually.

• The Useful Stuff Principle

  The Useful Stuff Principle states that entities must depend on useful stuff, not overly abstract nonsense. It states that a high-level module can depend on a low-level module, because that’s how software works.

• Dependencies

  The The Existence of Dependencies Is Not An Excuse For Destroying The Codebase Principle states that the existence of dependencies is not an excuse for destroying the codebase

• Abstraction Budget

  consider giving your developers an abstraction budget

  when they exhaust that budget & ask for more, tell them they can have another abstraction when they remove an existing one

  when they complain, look for classes with the term “Factory”, “Lookup” or “Visitor” in their names

• Fewer Functions

  if your function is only called in one place, consider inlining it & reducing the total number of method signatures in your module, to help people better understand it

  studies show longer methods have fewer bugs per line of code, so favor longer methods over many smaller methods

• “God” Object

  consider creating “God” objects that wrap a lot of functionality up in a single package

  consumers of your API don’t want to learn 50 different classes to get something done, so give them a few that provide the core functionality of your module with minimal fuss

• Copy & Paste Driven Development

  copy&paste driven development is a development methodology where, when you need to reuse some code but in a slightly different manner, you copy & paste the code & then modify it to satisfy the new requirements

  this contrasts with designing an elaborate object model, for example

• Implementation Driven Development

  implementation driven development is a development methodology where you first explore various implementations of your idea to determine the best one, then add tests for it

  no test code may be written without first having some implementation code to drive that test

• Mixing Concerns

  Mixing of Concerns is a design methodology whereby “concerns” of various kinds are mixed into a single code unit. This improves locality in that code unit by placing all relevant logic within it. An example of this is hypermedia, which mixes control & presentation information.

• Macroservices Architecture

  a macroservice architecture revolves around “macroservices”: network-deployed modules of code that provide a significant amount of functionality to the overall system

  by adopting a macroservice-based architecture you minimize deployment complexity & maximize resource utilization

• Sorry

  kinda had a manic break last night my bad