Dlaczego uważam, że KISS jest królem wszystkich dobrych praktyk?

Esencję tego, co chciałbym zamieścić w tym poście można opisać nieśmiertelnym cytatem:

prostota jest szczytem wyrafinowania

Leonardo da Vinci

Antoine de Saint-Exupéry miał do powiedzenia coś bardzo podobnego:

Wydaje się, że doskonałość osiąga się nie wtedy, kiedy nie można już nic dodać, ale raczej wtedy, gdy nie można nic ująć.

Antoine de Saint-Exupéry

Przypadki tego typu wypowiedzi rozsiane są w cytatach bardzo wielu genialnych ludzi. Nie bez powodu jest to zasada, która powtarza się w każdym inżynieryjnym zagadnieniu. Nie ma tu znaczenia, czy jest to rakieta, czy system informatyczny.

Czym jest KISS?

KISS to akronim, który można rozwinąć na wiele sposobów na różnym poziomie wulgarności : ) Tak, czy inaczej zawsze chodzi o to samo – prostota jest jedną z największych wartości i niepotrzebne skomplikowanie powinno być unikane. Praktyka pokazuje przecież, że najczęściej proste rozwiązania okazują się najskuteczniejsze.

Zasada ta ma wiele form pokrewnych np.:

Dlaczego tak mocno wypowiadam się odnośnie KISS?

Skomplikowany i przerośnięty kod jest bardzo poważnym problemem. Szkody spowodowane brakiem prostoty zwykle okazują znacznie większe, niż się wydaje. Ma to wpływ na każdy aspekt rozwoju i działania systemu. Skomplikowane funkcjonalności wymagają więcej czasu i testowania, a przerośnięty kod wcześniej czy później zacznie generować problemy wydajnościowe.

Jednakże nie jest to główny problem. Każde skomplikowanie musi być zrozumiane przez przyszłych programistów pracujących w danej części kodu. Czas poświęcony na oryginalne zrozumienie tematu można pomnożyć przez ilość wszystkich przyszłych i obecnych kolegów w zespole. Dlatego też każde nieprzemyślane rozwiązanie wielokrotnie odbije się czkawką w przyszłości.

Dlaczego tak łatwo popełnić grzech komplikowania?

Niestety jest wiele powodów …
Programiści uwielbiają złożone rozwiązania (które przecież mogą być proste), przez co:

  • wpadają w pułapkę przedwczesnej optymalizacji,
  • używają ulubionych rozwiązań, nawet jeśli prostsze są dostępne (tzw. silver bullet),
  • stosują skomplikowane, rzadkie i ciężkie do zrozumienia rozwiązania w celu zaimponowania reszcie zespołu,
  • wykazują zwykły brak wiedzy odnośnie dobrych praktyk, połączony z przesadną wiarą w swoje umiejętności.

W jaki sposób można się przed tym bronić?

Przede wszystkim przy pisaniu, naszym priorytetem powinna być łatwość zrozumienia kodu przez innych. Jeśli w naszej głowie pojawi się chęć imponowania, czy konkurencji, to prawdopodobnie jesteśmy ofiarą Efektu Dunninga-Krugera.

Bądź czujny jeśli:

  • musisz długo tłumaczyć koledze z zespołu zastosowane rozwiązanie – prawdopodobnie jest ono zbyt skomplikowane,
  • podejrzewasz, że problem z którym się mierzysz jest pospolity – zawsze poszukaj gotowych rozwiązań zamiast pisać własne.

Pamiętaj:

  • pierwsza kopia robocza kodu zawsze powinna być maksymalnie prosta, potem optymalizowana w zależności od potrzeb,
  • zawsze próbuj pracować na konfiguracji domyślnej – konfigurację niestandardową dodajemy tylko jeśli jest to konieczne,
  • konsultuj rozwiązania ze starszymi programistami lub architektami, jeśli pisane rozwiązanie wydaje się skomplikowane.


Reasumując, każdy bardzo poważnie powinien wziąć pod uwagę KISS przy tworzeniu jakichkolwiek rozwiązań. Ta jedna, prosta zasada wystarczy, żeby uniknąć potężnej ilości problemów w naszym systemie.

Leave A Comment