design thoughts

code design guidelines

- when designing libraries its better to leave threads out but not always
  - realize that your users may have varying threading strategies and your lib should not prescribe or assert one lest it resists reuse
  - typical novice problems
    - http://joostdevblog.blogspot.in/2015/01/what-most-young-programmers-need-to.html
      - liar variables, methods, classes
      - muddy classes
      - oversized classes
      - code in comments
      - parallel logic and duplication
- reduce the number of explicit if conditions in the codebase
- DRY in data, code and ideas
- reduce dependence on caches
- reduce what you persist
- reduce reliance on threading
- modularization is serious business
  - understand what should go into what module
  - understand what is the app and what is the library
- one function should only be at one layer of abstraction and do only one thing at that layer of abstraction
- io is the outermost layer and business code is the inner most - clean architecture
- primitive objects at the edges and composite objects as you go up
- stateless at the edges and stateful as you go up
- all io should have async apis
- threads should typically only be used for io
- don't design for the future the future is never here
- do less not more
- you should be able to count lines of code required for any feature with resaonable accuracy
- if you feel something is too complicated it probably is - simplify it
- don't invent artificial design rules
  - example - too many simple classes is a bad thing - it isn't
- separate presentation from model, same code should run on a different platform/UI
- methods with booleans in parameters should be decomposed into two separate methods each
  - methods with more than one boolean is smelly
  - booleans are crude
- minimize Singletons
- decide what to promote to OOP and what stays procedural, almost everything should promote
- methods should prefer data parameters rather than objects
  - unless they need the object to execute some process
- Encapsulate all mutable fields belonging to one invariant into a separate class
- coupling means sharing
  - internal state/data structures
  - db schemas
  - internal representational objects
- any api that can be added without adding new state is a good idea
- make sure your tests only test code you have written
  - don't test IO, or libs/framework written by other parties, in order to achieve this you will be forced to pull business logic out into a testable unit
- how to identify modules in existing code
  - algorithm
    "for class in classes:
    	if class belongs to only one existing module:
    		module.add(class)
    	elif class belongs to more than one module:
    		split class and then add to respective modules
    	else:
    		create new module and add class to it"
- power law
- premature optimization is evil; why you should not optimize your domain model for performant queries when creating a new system
  - typically such a tradeoff effects object and relational schemas and is usually about which object references/contains which other object
  - premature optimization is unnecessary because required levels might still be achievable in the better domain model instead of making a premature compromise and you can't prove or assume this before hand