Dlaczego nie warto przepisywać aplikacji legacy na nowo
Istnieje kilka powodów, dla których warto przepisać aplikację legacy, ale w większości przypadków koszty są wyższe od korzyści. Przedstawię tutaj zalety oraz wady pisania aplikacji na nowo i spróbuję wyjaśnić, dlaczego przeważnie nie jest to dobry pomysł. Wielu programistów (w tym i ja) jest w stanie żyć z aplikacją legacy, ale nie mija dużo czasu, zanim stwierdzą, że należy ją zabić, spalić i zbudować od zera.
Kod jest za trudny do zrozumienia, metody mają setki wierszy, są tam nieużywane zmienne oraz instrukcje warunkowe warunkujące inne instrukcje warunkowe na różnych poziomach itd. Jest to tak straszne, że Sandi’s squint test (czyli przyglądanie się swojemu kodowi zezując, aby przez kształt dojść do tego, których elementów jest za dużo) przyprawiłby Cię o zawrót głowy.
Dlaczego przepisywanie kodu jest tak kuszące?
Możesz korzystać z najnowszych narzędzi
Trudno jest oprzeć się przepisywaniu kodu, zwłaszcza gdy widzisz miejsca, które można ulepszyć na wiele sposobów, używając najmodniejszego podejścia, frameworku lub pakietu. Dlaczego mamy cofać się do średniowiecza i używać mieczy i tarcz, podczas gdy mamy tak dużo nowoczesnych i sprawdzonych narzędzi?
Wydaje Ci się, że masz wszystko, jak na dłoni
Mamy dostęp do bieżącej aplikacji, możemy zobaczyć, jakie błędy popełnili poprzedni developerzy, a sami klienci mają większe doświadczenie i wiedzą, co działa, a co nie, oraz czego faktycznie potrzebują. Przepisanie aplikacji to bułka z masłem, zrobię to w mgnieniu oka!
Łatwiejsze pisanie testów
Większość starszych aplikacji, które trzeba przepisać, nie ma testów. Dodanie ich jest trudne; istnieje nie tylko niezliczona liczba zależności i ścieżek wykonywania, ale często nawet nie wiadomo, co w ogóle trzeba przetestować.
Musisz więc pobawić się w detektywa, uważnie śledząc każdą metodę i próbując odgadnąć, co ma ona zrobić. Kiedy zaczynasz od zera, możesz przetestować własny kod, co jest milion razy łatwiejsze.
Dlaczego przepisywanie aplikacji to zły pomysł
To kosztowne
Aplikacja sama się nie przepisze. Musisz poświęcić wiele godzin na doprowadzenie jej do punktu, w którym robi to, co robiła wcześniej i może, żeby robiła to trochę lepiej. Można by to argumentować, mówiąc: „stracisz tyle samo lub nawet więcej czasu i pieniędzy, nie przepisując jej od nowa, z powodu niemożności szybkiego dostarczenia funkcji”.
To prawda. Utrzymywanie starej bazy kodu, naprawianie błędów i jednoczesne dostarczanie nowych funkcji to nie lada wyzwanie. Nie możesz też wprowadzać jednej funkcji po drugiej, tak jak kiedyś, co jest naszym drugim argumentem.
Nie możesz wtedy udostępniać nowych funkcji
Kiedy zaczynasz przepisywać aplikację, nie możesz wydać niczego nowego przez miesiące. W zależności od charakteru działalności konieczne może być reagowanie na użytkowników i dostarczanie nowych funkcji. Co więcej, zanim przepiszesz apkę, Twój klient mógł już dawno wypaść z gry.
Tak naprawdę nie znasz wszystkich faktów
Po latach zmian nikt nie wie dokładnie, jak aplikacja reaguje w każdej sytuacji, nawet Twoi klienci. Mogą oni mieć ogólne pojęcie o tym, jak ona działa i co robi, ale nadal istnieje wiele niewiadomych, które można odkryć tylko poprzez sprawdzenie aktualnej bazy kodu. Wystarczy, że przejdziecie do pełnego przepisania nieprzygotowani, a stracicie godziny na komunikację z klientem i ślepe zaułki.
Możesz zrujnować relację z klientem
Powiedzmy, że nakłaniasz klienta do zaakceptowania wszystkich kosztów przepisania aplikacji. Obiecujesz im, że to wszystko będzie w końcu tego warte. Aplikacja będzie szybsza, wolna od błędów, lepiej zaprojektowana i łatwiejsza do rozszerzenia.
Jeśli jest jakaś rzecz, którą wiemy o tworzeniu oprogramowania, to jest to fakt, że w pewnym momencie coś na pewno pójdzie nie tak: serwer, baza danych, źle skonfigurowana usługa lub jakaś niewinna aktualizacja.
Co widzą developerzy, a co klienci
Kiedy coś takiego się dzieje, Twój klient zacznie kwestionować swoją własną decyzję o przepisaniu aplikacji. Nie zdają sobie sprawy z tego, że apka będzie 10 razy szybsza. Nie obchodzi ich, że używasz najnowszych i najlepszych narzędzi, sprawdzonych metod, frameworków i pakietów.
Wiedzą tylko, że zgodzili się wydać mnóstwo pieniędzy i cennego czasu na coś, co wygląda i działa tak samo. Każda przeszkoda, którą pokonujesz, niszczy relacje, które masz z klientem.
Kiedy warto przepisywać
Pomijając przypadek, w którym aplikacja jest mała, prosta i można ją napisać od nowa w ciągu zaledwie kilku miesięcy, są jeszcze dwie sytuacje, w których jej całkowite przepisanie może być dobrym pomysłem.
Kiedy dostarczanie nowych funkcji nie jest priorytetem
Kiedy biznes jest stabilny, to większość pracy kręci się wokół obsługi klienta i kilku błędów. Dobry moment to taki, kiedy nie ma presji czasu i chcesz napisać coś od nowa ze względu na wydajność oraz (może), aby być na bieżąco z najnowszymi technologiami.
Przepisanie aplikacji sprawi, że będziesz w odpowiedniej pozycji na wypadek, gdy trzeba trochę przyśpieszyć lub zmienić kierunek.
Próbując innego podejścia
Interes się kręci, klienci są zadowoleni, a obecna aplikacja jest dobrze przetestowana i wykonana, ale trochę się zestarzała i chcesz wypróbować nowe podejście, aby przyciągnąć nowych klientów. Basecamp jest tutaj najlepszym przykładem. Co kilka lat całkowicie przepisują oni i wypuszczają nową wersję swojego produktu.
Nowi klienci chcą nowego podejścia, podczas gdy starzy mają wybór, czy chcą coś uaktualnić, czy pozostać przy obecnej wersji. Wszyscy są szczęśliwi.
Praca na starszych bazach kodu jest do niczego. Jesteś przerażony, gdy klienci proszą Cię o dodanie nowej funkcji.
Czujesz, że nie możesz niczego dotknąć bez zepsucia czegoś innego. Jedynym rozsądnym rozwiązaniem, które widzisz, jest rezygnacja i przepisanie całej aplikacji — wszystko, aby zatrzymać to szaleństwo. Czasami chcesz to nawet robić w swoim wolnym czasie.
Niestety, przepisywanie rzadko jest dobrym pomysłem. Jest zbyt wiele niewiadomych, musisz wstrzymywać się z wprowadzaniem nowych funkcji, ryzykujesz zerwanie relacji z klientami, a zainwestowany czas i pieniądze mogą się nigdy nie zwrócić.
Z drugiej strony refaktoryzacja zawsze może Cię uratować.
Oryginał tekstu w języku angielskim możesz przeczytać tutaj.