Jest w życiu wiele zasad, reguł, którymi się kierujemy. Zazwyczaj nie podążamy jednak ślepo za nimi. Wyciągamy z nich to co jest nam w konkretnej sytuacji najbardziej potrzebne. W programowaniu również. Najbardziej znane są trzy:

• SOLID:
  • S – Single Responsibility (pol. pojedyncza odpowiedzialność)
  • O – Open – Closed (pol. otwarte – zamknięte, kod otwarty na rozszerzanie, zamknięty na modyfikacje)
  • L – Liskov Substitution (pol. podstawianie Liskov*)
  • I – Interface Segregation (pol. segregacja interfejsów)
  • D – Dependency Inversion (pol. odwracanie zależności)
• DRY – Don’t Repeat Yourself (pol. Nie powtarzaj się)
• KISS – Keep It Simple Stupid (pol. Nie kombinuj głuptasie)

Oczywiście, można za nimi ślepo podążać. Wziąć np. SOLID i ściśle się tego trzymać. I jest to bardzo dobra decyzja. Pytanie, czy zawsze?

Weźmy np. zasadę DRY – Don’t Repeat Yourself – piszemy kod, który jest reużywalny, nie powtarzamy logiki zawartej w jednym miejscu w aplikacji, w innym. Tylko, że z tego rodzą się czasem klasy/metody potwory. Okazuje się, że mają wiele odpowiedzialności, skomplikowaną strukturę – tylko po to, żeby nie powtórzyć się w innym miejscu.

I tu mamy problem – jest to świadome naginanie reguły KISS – Keep It Simple Stupid – która mówi o tym, żeby kod był tak prosty, jak to tylko możliwe. Ta z kolei jest ściśle powiązana z TDD, w którym powinniśmy pisać tylko tyle kodu, ile jest potrzebne do tego, żeby nasz test przechodził.

Wniosek nasuwa się jeden – nie istnieje srebrna kula. Nie ma idealnego scenariusza, w którym weźmiemy garść złotych myśli (nasze reguły) i mamy gotowy przepis na sukces. Trzeba pamiętać o tym, żeby nie mieć klapek na oczach. Należy umiejętnie żonglować poszczególnymi zasadami, żeby osiągnąć satysfakcjonujący, końcowy rezultat.

* Edited