रaपa Learning

ದಾಸನ ಮಾಡಿಕೊ ಎನ್ನ

Crafting your habits

Weekly assignments to build habits for clean-code

Entrance: Test-driven statistics

Checkpoint: Ability to program with tests; Participate.

C | C++ | C# | Java | Python

Week 1: Modular, well-named

Breakdown code, add new feature with minimal side-effects

C | C++ | C# | Java | Python

Habits for modularity

  • Break for Single Responsibility - isolate changes
  • Name your files and functions to reflect purpose, rather than their contents
  • Add functionality by adding code, rather than changing the legacy

Review modularity

  • Isolation: Is new functionality added as a new file?
  • Can you recognize the purpose of each file by looking at its name?
  • Are there asserts for the new functionality? Do they reflect what’s acceptable to the user?

Week 2, 3: Fail on false positive, Pass the failing test

Make failing tests for buggy code. Avoid false positives. Then pass the failing test.

C | C++ | C# | Java | Python

Habits for proving your code

  • Test to express acceptability - what would make a user accept this software?
  • Isolate your functionality from its dependencies. Use functional constructs, dependency injection and mocks.
  • Focus the tests on your value-add. Avoid testing proven dependencies.

Review the tests for proof of value

  • Do the tests reflect what’s acceptable to the consumer? E.g., “alignment in the output”
  • Do they fail for the right reasons?
  • Is the software under test isolated from external factors? E.g., computation isolated from I/O
  • What is the residual risk that remains after testing?

Week 4, 5: Reduce complexity, Extend and refactor

Recognize abstractions and (single) responsibility by reducing cyclomatic complexity and duplication. Then experience the ease of extending by refactoring.

C | C++ | C# | Java | Python

Habits for simplicity

  • Split into parts, choose their names to reflect their purpose.
  • Evaluate multiple methods of splitting. Choose the one that has least semantic distance.
  • Recognize open-close principle: Add new functionality by adding new code, rather than changing the legacy.

Review for lucidity

  • Would a consumer of the software be able to recognize the abstractions by their name?
  • Do passing tests give confidence of acceptable behavior?
  • Do the tests protect against common mistakes (E.g., missed translations)