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.