YAGNI: You aren’t gonna need it

YAGNI to kwintesencja zasad clean code. Dotyczy ona bezużyteczności kodu, a dokładniej, konieczności usuwania tych fragmentów, które nie są potrzebne. W myśl „You aren’t gonna need it” nie powinniśmy tworzyć niczego więcej, niż to, co jest potrzebne.

Tylko to, co faktycznie jest potrzebne

YAGNI, czyli „You aren’t gonna need it”, jest jedną z moich ulubionych zasad z zakresu clean code. Mówi ona o tym, aby podczas tworzenia kodu nie dodawać rzeczy, które są nam niepotrzebne. Może to brzmieć banalnie, bo w końcu, po co dodawać coś ponad, dodatkowo, co nie jest niezbędne? Często jednak nie zdajemy sobie nawet sprawy (my programiści), że w wielu sytuacjach jesteśmy nadgorliwi. Tworzone rozwiązanie powinno spełniać swoje wymagania i nic poza tym. Nie zrozum mnie jednak źle, chodzi mi tutaj o dopisywanie czegoś na zapas, bo za kilka dni może się przydać, albo istnieje niezerowa szansa, że nasze rozwiązanie w przyszłości rozbuduje się o kolejnego if-a. Inny przykład, to instalacje biblioteki lub zewnętrznej zależności, bo jutro masz w planie jej użyć. 

Kiedy łamiemy YAGNI?

Podczas robienia code review, łamane YAGNI widuję najczęściej w dwóch przypadkach: dodawanie kodu na zapas i implementowanie strategii dla np. dwóch ifów (tutaj samemu zdarza mi się czasami dołożyć cegiełkę). Spróbujmy jednak zobrazować sobie ten pierwszy przypadek, jako, że jest on częstszy.

Otrzymaliśmy zadanie stworzenia modelu identyfikującego pewien agregat. Ma on się składać z dwóch pól, powiedzmy: timestamp i id zasobu. Jednakże my wiemy, że w przyszłym sprincie dojdzie do tej klasy nowa metoda: toString(), która zamieni reprezentację obiektu do postaci ciągu znaków. Chcemy szybko dowozić, więc dostarczamy model identyfikatora wraz z logiką, która (może) w przyszłości dojdzie.

class SubjectId {
  private constructor(
    private readonly timestamp: number,
    private readonly resourceId: string
  ) {}

  static create = (resourceId: string): SubjectId => 
    new SubjectId(new Date().getTime(), resourceId);

  toString = (): string =>
    `${this.timestamp}#${this.resourceId}`;
}

Ten kod nie powinien powstać w takiej formie. Twoim zadaniem było dostarczenie modelu identyfikującego, ale bez logiki zawartej w metodzie toString(). Złamałeś/aś YAGNI!

Trzeba uważać, serio!

Chciałbym poznać Twoje zdanie (psst! sekcja komentarzy) na ten temat. Czy zdarza Ci się wpadać w pułapkę nadgorliwości? Jak już wcześniej wspomniałem, u mnie też się to czasami dzieje. Chcę ułatwić sobie pracę na przyszłość, albo w ferworze programowania napiszę zbyt wiele. Dla części z Was może być to dobre zachowanie, jednak na dłuższą metę, jest to zwyczajne łamanie zasady YAGNI. Oczywiście, nie popadajmy też ze skrajności w skrajność. Trzeba zwyczajnie zachować równowagę między tym, co jest do zrobienia, a tym co możemy zrobić ponad to.

Podsumowanie

  • YAGNI, to jedna z zasad z zakresu clean code.
  • W myśl YAGNI, staraj się zachować balans pomiędzy tym, co musisz, a tym co możesz jeszcze zrobić.
  • Zbyt duża nadgorliwość może skutkować marnowaniem czasu na rzeczy nieistotne.
Autor wpisu

blog@orbisbit.com

Komentarze

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Sprawdź również
  • CQRS – Command Query Responsibility Segregation

    Command Query Responsibility Segregation czyli CQRS. Jest to wzorzec projektowy, który rozdziela zadania odczytu i zapisu do osobnych modeli. Sprawdź ten wpis, aby dowiedzieć się kiedy i jak z niego skorzystać.

    Zobacz wpis

  • GRASP – kolejny zbiór zasad Clean Code do zapamiętania

    Pewnie większość z Was słyszała o zasadach SOLID. Są one bardzo rozpowszechnione i dosyć często stosowane, ale czy słyszeliście o GRASP? General Responsibility Assignment Software Patterns, to kolejna dawka zasad czystego kodu do zapamiętania.

    Zobacz wpis

  • Wzorzec strategia (strategy pattern)

    Jeżeli masz dość if-ologii w swoim kodzie, to konieczne sprawdź czym jest czynnościowy wzorzec projektowy strategia. Pozwala on mądrze obsługiwać różne scenariusze w procesie i jednocześnie być fancy pod względem zasad SOLID.

    Zobacz wpis