Poznajesz nową bibliotekę, nowy framework, uczysz się nowego podejścia do architektury. Wydaje się, że będzie pasować do Twojego projektu. Przekonujesz zespół, namawiasz “biznes” i wprowadzacie to z sukcesem na produkcję. Leje się szampan, klepiecie się plecach. Dla takich dni warto było przewalać ten cały kod legacy przez lata.

 


Rok później


Potem zmieniają się trendy, połowa zespołu odeszła do innych projektów, ktoś inny jest zainspirowany wystąpieniem na konferencji. Społeczność przestała się interesować zeszłorocznym skarbem i coraz mniej udziela się w tym temacie na StackOverflow. Co teraz?

Macie dwie drogi. Albo znów rzucicie się na coś nowego ku zadowoleniu całego zespołu, albo będziecie utrzymywać to “stare” rozwiązanie, które już w tym momencie stało się legacy.

 

Gdzie jest problem?


Czasem kiedy bardzo chcemy coś przetestować i sprawdzić (szerzej niż Hello world), podejmujemy szalone decyzje. Wydaje nam się, że tworzenie oprogramowania to nowinki i ciągła zmiana. Myślimy z perspektywy kodera, a nie wartości biznesowej produktu.

Nie zdajemy sobie sprawy z kosztów naszych decyzji. Z tego, że każda dodatkowa zależność musi być utrzymywana, a kod wokół niej rozwijany. Jaki jest próg wejściado projektu, w którym technologie są niszowe, a jednolinijkowce wykręcają głowę jak w Egzorcyście?

 


Jakie jest rozwiązanie?


Nie namawiam Cię do pisania w Javie 6 i JUnit3. Technologie są rozwijane po to, żeby coraz lepiej nam pomagać. Zanim jednak wprowadzisz coś do projektu, zadaj sobie te 3 pytania:

  1. Jaki problem to rozwiązuje, a jakie może wprowadzać?
  2. Kto będzie to utrzymywać oprócz Ciebie? (nie chcesz telefonów na wakacjach i w weekendy)
  3. Czy jest silne wsparcie w społeczności?

Z tymi pytaniami Cię zostawię. Jeśli masz jakąś śmieszną historię w tym temacie, to podziel się nią w komentarzu!