Development Algorithm - raisercostin/software-wiki GitHub Wiki

Intro-to-Steps Classes-of-Objects

2023-10-27

  • learning from ChatGPT about emerging trends and concepts: automated observability. The topic came as a request from me to fix the breaking of principle of least surprise when a save on a spring repository fails silently when is not called inside a transaction.

    Automated observability is an emerging trend that focuses on alerting developers to issues like this automatically. This is commonly seen in modern cloud-native setups but is also becoming relevant in traditional applications.

2023-10-26

  • developer centric coding - I want to use a method/object and this shows what are the needed arguments and those arguments should be easy to "fabric"/"create"/"lookup". Best is in some "companion" static methods (that are more powerful than constructors: meaningful names, null or other objects creation)

2023-10-19

Algorithm for development

  • verificare ieftina in test unitar fata de productie
  • adaugi constraintul ieftin as a test
  • next valuable thing: fix it (without breaking anything else - respecting all other constraints)
  • ugh is ugly -> transform/refactor (not bug fix/new feature) in a safe manner

2023-10-19

The software can be in an unwanted behaviour because of:

  • a bug
  • a missing feature
  • actually un-needed It doesn't matter which ones.

This triggers the need to transform/fix the code/software. You shouldn't "analyize": bug cause or design feature. You should:

  1. define new constraints in form of one or more tests (define the border or a specific behaviour required from exiting border/api)
  2. it fails (because the bug is triggered or missing feature - somewhere you have not implemented yet, wrong returned values or wrong side effects)
  3. safe refactoring - preparatory, learning and technical debt payment redesign, you do not change behaviour but just the form
  4. fix it - risky change (the new constraints are meet). you could discover more and more constraints.
    • respects Open Closed Principle - everything that worked should still work
    • minimal solution, with minimal absolute changes, no redesign allowed (is allowed only before or after)
  5. safe refactoring - post change avoiding overdesign because YAGNI
  6. repeat with new constraints