Skip to content

Instantly share code, notes, and snippets.

@jlisee
Forked from vinitkumar/architecture.md
Last active August 29, 2015 14:00
Show Gist options
  • Save jlisee/eb0e5a423b2532a0ff7a to your computer and use it in GitHub Desktop.
Save jlisee/eb0e5a423b2532a0ff7a to your computer and use it in GitHub Desktop.

Architectural Questions

  • Are responsibilities well defined?
  • Are the collaborations well defined?
  • Is coupling minimized?
  • Can you identify potential duplication?
  • Are interface definitions and constraints acceptable?
  • Can modules access needed data—when needed?

The debugging checklists

  • Is the problem being reported a direct result of the underlying bug, or merely a symptom?
  • Is the bug really in the compiler? Is it in the OS? Or is it in your code?
  • If you explained this problem in detail to a coworker, what would you say?
  • If the suspect code passes its unit tests, are the tests complete enough? What happens if you run the unit test with this data?
  • Do the conditions that caused this bug exist anywhere else in the system?

How to Program Deliberately

  • Stay aware of what you're doing.
  • Don't code blindfolded.
  • Proceed from a plan.
  • Rely only on reliable things.
  • Document your assumptions.
  • Test assumptions as well as code.
  • Prioritize your effort.
  • Don't be a slave to history.

Cutting the Gordian Knot

  • When solving impossible problems, ask yourself:
  • Is there an easier way?
  • Am I solving the right problem?
  • Why is this a problem?
  • What makes it hard?
  • Do I have to do it this way?
  • Does it have to be done at all?

Languages to Learn

  • Golang
  • Haskell
  • Python
  • JavaScript
  • C
  • Lisp

Note: This is my personal languages checklist, Feel free to replace it with your languages of choice.

Law of Demeter for Functions

  • An object's method should call only methods belonging to: Itself
  • Any parameters passed in
  • Objects it creates
  • Component objects

How to maintain orthogonality

  • Design independent, well defined components
  • Keep your code decoupled
  • Avoid global data
  • Refactor similar functions

Things to prototype

  • Architecture
  • New functionality in an existing system
  • Structure or contents of external data
  • Third-party tools or components
  • Performance issues
  • User interface design

Aspects of Testing

  • Unit testing
  • Integration testing
  • Validation and verification
  • Resource exhaustion, errors, and recovery
  • Performance testing
  • Usability testing
  • Testing the tests themselves

When to Refactor ?

  • You discover a violation of the DRY principle.
  • You find things that could be more orthogonal.
  • Your knowledge improves.
  • The requirements evolve.
  • You need to improve performance.

The Wisdom Acrostic ( Customer specific)

  • Why do you want to learn them?
  • What is their interest in what you have got to say?
  • How sophisticated are they?
  • How much details do they want?
  • Whom do you want to own the information?
  • How can you motivate them to listen to you?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment