Skip to content

1. Principles of good design

DRY

  • Don't repeat yourself
  • Vše by mělo být napsané/definované právě jednou

KISS

  • Keep it simple, stupid!
  • Naprogramovat radši všechno jednoduše a zcela se vyvarovat ne nutně složitých implementací.

YAGNI

  • You arren't gonna need it
  • Není dobré přidávat funkcionality dokud nejsou opravdu potřeba

SOLID

  • Sada vlastností/principů
    • S - Single-Responsibility Principle (SRP)
      • Třída by měla mít jen jednu odpovědnost/práci
    • O - Open-Closed Principle (OCP)
      • Implementace by měla být otevřená pro rozšiřování ale uzavřená pro změny
        • Má být snadno rozšiřitelná o novou funkčnost
        • Nemělo by být umožněno provádět změny v kódu
    • L - Liskov Substitution Principle (LSP)
      • Tento princip udává, že každá derivovaná třída (často se pro derivování používá klíčové slovo extends) musí být nahraditelná svým derivátem
    • I - Interface Segregation Principle (ISP)
      • Klient by nikdy neměl záviset na metodě nebo rozhraní kterou/é nepoužívá
    • D - Dependency-Inversion Principle (DIP)
      • High level moduly by neměly být závislé na low level modelech ale na abstrakci (na nějakém interface třeba)

SoC

  • Separation of concerns
  • Princip ve kterém musí každá část návrhu implementovat jinou část problému

LoD

  • Law of Demeter
  • Každá součást návrhu by měla mít limitovanou znalost o systému. Tedy, že by každá součást měla znát jen ty nejnutnější sousední součásti

Avoid premature optimization

  • Neměli byste se příliš zabývat optimalizací kódu nebo systému, dokud neprokážete, že je to skutečně nutné. Je důležité se soustředit na návrh a vývoj funkčního řešení, než se pouštět do složitých úprav pro zlepšení výkonu. Často může být předčasná optimalizace zbytečná nebo dokonce škodlivá, protože může zkomplikovat kód a zhoršit jeho čitelnost nebo rozšíření. Je lepší se nejprve zaměřit na správné návrhy a dobrou architekturu a až poté začít řešit problémy s výkonem, pokud je to skutečně nutné.

The boy scout rule

  • Měli bychom zanechávat kód lepší, než jaký jsme ho našli. To znamená, že pokud upravujeme nebo opravujeme kód, měli bychom se snažit nejen vyřešit přímý problém, ale také zlepšit celkovou strukturu nebo čitelnost kódu.

Principle of least astonishment

  • Měli bychom designovat software tak, aby chování a funkce byly co nejvíce intuitivní a předvídatelné pro uživatele.

Tech debt

  • Je to pojem, který se používá k popisu situace, kdy je v projektu potřeba opravit nebo vylepšit něco, co bylo dříve implementováno neefektivně nebo špatně. Technický dluh se může týkat různých aspektů projektu, jako je kód, architektura, dokumentace nebo testování.