Skip to content

README.md

Latest commit

 

History

History
148 lines (116 loc) · 5.88 KB

README.md

File metadata and controls

148 lines (116 loc) · 5.88 KB

Design

“Once you understand that all other technical goals in software are secondary to managing complexity, many design considerations become straightforward.”

Design Goals

  • Minimize complexity
  • Make design as modular as possible
  • Black box everything
  • Simple interfaces
  • Well defined functionality

Typical Challanges

  • Need to solve part of the problem before the whole problem can be fully defined
  • Design is mega sloppy
    • Lots of mistakes involved
  • Design is about tradeoffs, priorities and restrictions
  • There are many ways to design the same system
  • Designs grow and change after spending more and more time with the code and seeing whats possible

Primary goal is to Minimize Complexity

  • Goals
    • To minimize the amount of a program you have to think about at any one time
    • To write code that compensates for inherent human limitations
    • To avoid situations where nobody completely understands the impact their code changes have
  • How to Attack Complexity?
    • Minimize amount of essential complexity that anyone’s brain has to deal with at any one time
    • Keep accidental complexity at a minimum

Design can be broken into several Levels

  1. The software system - designer
  2. Division into subsystems/packages - designer
  3. Division into classes within packages - designer
  4. Division into data and routines within packages - programmer
  5. Internal routine design - programmer
  • The package divisons need to account for
    • All major subsystems
      • Databases, UIs, business rules, interpreters, reporting engine
    • Communications between each package
      • Make each subsystem meaningful by RESTRICTING communications
      • Allow communication on a NEED TO KNOW basis
      • If all can communicate, there will be unintended consequences
      • Much easier to relax communication than make it more strict

Common Heuristics

Find real world Objects

  • Modeling an OOP system effectively

Compartmentalize

  • Abstract, Encapsulate and Hide Information effectively

Identify areas likely to Change

  • Protecting frozen functionality from changes

Keep Coupling loose

  • The more easily the other modules can call a module, the more loosely coupled it is
    • sin() vs initVar(var1, var2, var3, var4)

Use Design Patterns when applicable

  • Code level patterns

Other (just as important) Heuristics

Common Design Practices

These are steps that can be taken to help produce a desirable design

  • Iteration
    • Subsequent attempts are better than the previous
  • Divide and Conquer
    • Break problem into different areas of concern to tackle individually
  • Top-down
    • Guiding principal is the human brain can only focus on a certain amount of detail at a time
    • Essentiallty trying to decompose the problem
  • Bottom-up
    • This is a more tangible approach, as Top-down can be too abstract
    • Need to keep to goals of the system always in mind
      • What does the system need to do?
      • What are the concrete objects and responsabilities at this level?
      • What common objects can I group?
      • Set up to the next level
  • Experimental Prototyping
    • Two heads are better than one, so bounce ideas off others
      • Co-workers
      • Meetings with stakeholders
      • Ask a third party for help
      • Drawer your design and come back to it in a week once you've forgotten it

Desirable Charactersistics of a Design

  • Minimal Complexity
    • Avoid “clever” designs like the plague
    • Do make “simple” and “easy-to-understand” designs
  • As lean as possible
    • "A book is finished when nothing more can be taken away, not when nothing more can be added"
  • Standardized techniques
    • The more a system relies on exotic practices, the more intimidating it will be for someone to try and understand
  • Stratified properly
    • Keep levels of decomposition stratified so the system can be viewed consistently from any single level
      • View at one level without dipping into other levels
    • Compartmentalize code by creating a good interface
  • Loosely coupled
    • Connections among different parts of a program to a minimum
    • Good abstractions in class interfaces
    • Encapsulation
  • Has high fan-in
    • High number of classes that a given class uses
    • Means a system has been designed to make good use of utility classes at the lower levels in the system
  • Has a low to medium fan-out
    • The number of classes a given class uses is low (>7 is high)
  • Easily extensible
    • Changes (“enhancements”) to the system don’t cause violence to the underlying parts
  • Is portable
    • Can easily be moved to another environment
  • Easy to maintain
  • Is reusable (if desired)

How much design is enough?

  • Most problems arise from a lack of design detail - not too much of it
  • Exploring other design options is a better use of time than polishing design documentation
Situation Pre-Construction Detail Documentation Formality
Team has deep experience in applications area low low
Team has deep experience but is inexperienced in the applications area medium medium
Team is inexperienced medium-high low-medium
Team has moderate-high turnover medium -
Application is safety-critical high high
Application is mission-critical medium medium-high
Project is small low low
Project is large medium medium
Software is expected to have a short lifetime (weeks or months) low low
Software is expected to have a long lifetime (months or years) medium medium

Checklist