General Programming Exp

Read exceptions and logs. Do not rush (DNR)! Calm and steady.

Design

SOLID principles: - Single responsibility
- Open-closed - open to extension closed for mutation
- Liskov substitution - super-types can be replaced with subtypes without contract brooking
- Interface segregation - many interfaces are better for client code, than singe chunk
- Dependency inversion - dependencies on abstractions, not on concrete types
Be SOLID but KISS.

Refactoring Do it sometimes, BUT: - Let the solution live some time, proof itself. DNR.
- It is OK, programming it's like neurons paths building - need to rearrange sometimes.
- But estimate the costs, time is critical! Let it works, if it works.

Type system

Co and Contra-variants: - Covariance - C[T'] isSubTypeOf C[T], e.g. List<Cat> is subtype of List<Animal>
- Contra-variance - C[T] isSubTypeOf C[T'], e.g. Action<Animal> is subtype of Action<Cat>

Team work

TODO: pick from lectures

Requirements

Mine it, not just "pick".

Self-development

Brain

SES:

1. Sleep
2. Eat
3. Solve

Knowledge

Manage your knowledge as investments documents folder.

Technical

Tips: - Try to always use _ underscore instead of - words separator (can be selected with one click).

Parallel computing

Parallel != Async: - First for computational speed
- Second just for concurrency

Deadlocks: situations when threads blocks each other. E.g. in MPI Recv: T1: block(res1); block(res2);
T2: block(res2); block(res1);

Race condition: situation when some threads try to access data simultaneously. E.g.:
if(x == 3) y = x * 5; Problem can be solved by wrapping condition and assignment in lock.

Testing

There are two separate kinds of tests:

1. Integration (may be used with TDD). Good for:
   
   • Design e.g. TDD
     
   • Project acceptance or approval
     
   • Project understandability (by yourself of others)
     
2. Unit
   
   • Micro-design
     
   • Program extension and mutation
     
   • Bugs location
     
   • Code understandability (by yourself of others)
     Mocks lie more in Unit tests plain. Mocks are useful for testing interaction with side-services, like graphics.
     

Arrange your tests by power, e.g. unit tests arranged in DESC order for path finder:
- FindPathFrom(A to Z) - big power
- FindPathFrom(A to UNREACHABLE_NODE) - bit more power
- FindPathFrom(A to A) - trivial, low power
And than you can bound possible error from just test result (e.g. if 1, 2 - passed, 3 - not, means there are trivial error).

Tips:

1. Only one logical assertion per test - counterproductive to test all in each, it leads to overlaps and brook tests bugs location ability.
2. Do not create redundant preconditions (for the same reason as in)
3. Name it well, e.g. scope-action-result.