Sytuacja kobiet w IT w 2024 roku
22.02.20205 min
Fagner Brack

Fagner Brack

Jak skorzystać na długu technologicznym?

Sprawdź, jak wykorzystywać dług technologiczny na własną korzyść i skutecznie zmniejszyć jego odsetki.

Jak skorzystać na długu technologicznym?

Dług technologiczny jest jak zaciągnięcie pożyczki. Powiedzmy, że potrzebujesz drogiego samochodu, ale nie stać Cię na niego. Jedną z opcji jest zaciągnięcie pożyczki i spłata odsetek w czasie. Kompromis polega na tym, że zapłacisz więcej za ostateczną cenę samochodu. To kompromis, ale może mieć sens, jeśli pożyczka jest opłacana prawidłowo, aby nie ponosić zbyt wielu kosztów procentu składanego.

Istnieje jednak różnica między wzięciem pożyczki w wysokości 30 000 USD na samochód niezbędny do ukończenia pracy a Lamborghini za 700 000 USD. Powinieneś zadłużać się tylko na taki dług, który jesteś w stanie spłacić, aby osiągnąć rzeczy, których naprawdę potrzebujesz - nie musząc przy tym ogłaszać upadłości.

Dług techniczny jest najczęściej używany jako negatywna konotacja, ale nie musi takim być cały czas. To jak wzięcie pożyczki. Pozwoli na szybsze dostarczanie oprogramowania w niesprzyjających okolicznościach, bez konieczności inwestowania wystarczającej ilości czasu, aby znaleźć najlepsze rozwiązania dla danego problemu.

Martin Fowler trafia w sedno, mówiąc: […] podczas programowania uczysz się. Często zdarza się, że projekt może trwać rok, zanim zrozumiesz, jakie powinno było być najlepsze podejście do projektu. […]

Innymi słowy, programowanie jest jak gra w „znajdź wzór”. Wymagania będą się zmieniać często i nieprzewidywalnie. Dobrą strategią jest rozpoczęcie od naprawdę minimalnego i naiwnego podejścia do problemu. Im więcej wymagań się pojawi, tym bardziej zmienisz istniejący kod, aby dostosować się do nich. W tym momencie możesz zacząć dostrzegać wyraźniejsze schematy struktury kodu dla domeny, nad którą pracujesz, a następnie refaktoryzujesz w tym kierunku. Może się okazać, że refaktoryzacja przynosi skutki, ale czasami ich nie przyniesie, więc ponownie refaktoryzujesz w pętli zwrotnej.

To jest także paradoks. Tradycyjne organizacje zakładają, że od początku pracujesz w kierunku najlepszego projektu. Jednak nie możesz wiedzieć, jak taki projekt wygląda, dopóki nie znasz wszystkich wymagań, i jesteś w stanie rozpoznać wzory. Taki proces wymaga czasu. Jest to ogromne ograniczenie w rozwoju przyrostowym.

Nawet jeśli nie znasz wszystkich wymagań, nadal jesteś w stanie pisać oprogramowanie, które działa. Jednak może ono nie być zaprojektowane tak, by spełnić przyszłe wymagania. W takim przypadku dług technologiczny może pomóc w odroczeniu refaktoryzacji i dalszym rozwoju, dopóki wzorce nie będą wystarczająco jasne, aby dać dobre powody do refaktoryzacji.

Nie możesz wiedzieć, jak wygląda dobry projekt, dopóki nie znasz wszystkich wymagań

Na potrzeby tego tekstu, nazwijmy „zadaniem” wszystko, co może zmusza Cię do napisania kodu w celu rozwiązania problemu - na poziomie mikro lub makro. Może to być zadanie techniczne, wymaganie, funkcja, historia, epic… nie ma znaczenia.

Projekt zadania można iterować i ulepszać wiele razy, zanim zostanie uznane za wykonane. Jednak po pewnym czasie prawo malejących przychodów zaczyna działać i korzyści wynikające z ulepszenia tego projektu nie będą warte swego czasu.

Zbyt wiele opracowania i abstrakcji może mieć negatywne konsekwencje. Duplikacja jest lepsza niż niewłaściwa abstrakcja.

Chociaż pojawiają się wymagania, które zmuszają Cię do zmiany kodu, warto powtarzać i ulepszać projekt. Gdy wymagania przestaną obowiązywać i nie będziesz mieć powodów, aby dalej je wałkować, lepiej przestać w to inwestować czas. Zamiast tego pozostaw kod w zoptymalizowanym stanie, aby ułatwić refaktoryzację.

To oznacza pisanie kodu z bardzo małą abstrakcją, prostszymi transformacjami i jasnymi testami, by udokumentować intencje.

Możesz podjąć decyzję, aby nie pozostawiać długu technologicznego, jeśli tykasz się podstawowej części systemu, która często zmienia się w stosunku do czegoś, co nigdy nie zostanie tknięte ponownie.

Lepszy projekt, wspomagający jednocześnie czytelność, ma na celu wspieranie przyszłych zmian. Jeśli jest szansa, że ​​kod, który piszesz, nigdy nie zostanie zmieniony, dlaczego zatem miałbyś zainwestować w niego więcej czasu?

W takim przypadku pozostaw trochę zadłużenia technicznego na końcu i pozwól, aby następny wymóg napędzał lepszy projekt. W przyszłości będziesz w lepszej sytuacji, aby wyłapać powtarzające się schematy, zamiast spekulować na ich temat.

Wygląda to świetnie, ale mam złą wiadomość: nie ma idealnych rozwiązań. Jedynym sposobem, w jaki może się to udać, to sytuacja, gdy wszyscy programiści pracujący na kodzie mają ten sam poziom umiejętności i dyscypliny. Jeśli nie, będzie im bardzo trudno zrozumieć intencje kryjące się za kodem i nadążyć z odpowiednimi decyzjami.

W rzeczywistości rzadko zdarza się znaleźć zespoły, w których wszyscy są całkowicie wyrównani. W tym miejscu programowanie grupowe i programowanie w parach może pomóc w kształtowaniu kultury i poprawie współpracy.

Pamiętaj, że nic nie może być użyte jako wymówka do napisania złego kodu.

Możesz użyć długu technicznego na swoją korzyść tylko wtedy, gdy zespół jest wyrównany współpracujący i zdyscyplinowany

Powszechnym problemem z tym podejściem jest to, że programiści mają tendencję do pozostawiania zbyt dużego zadłużenia technicznego zamiast takiego, które ułatwia odkrycie wzorców w przyszłości. To może tylko pogorszyć sytuację.

Chodzi o to, aby ułatwić następną decyzję projektową, a nie ją utrudnić.

Jeśli pozostawisz dużo długu technicznego, nikt nie będzie miał czasu, ani chęci, aby to naprawić później. Będzie tylko napędzać więcej rozbitych okien. Nie poświęcaj swojego czystemu kodowi.

Podejmij świadomą decyzję w taki sposób, aby umożliwiła Ci postęp w przyszłości, przy jednoczesnym wspieraniu przyszłej refaktoryzacji. Powinno się to odbywać tylko w taki sposób, aby kod i testy mogły odsłonić kryjące się za nimi smrodki.

Dług nie zawsze jest zły

Gdybyś nie miał możliwości pożyczenia pieniędzy, nie byłbyś w stanie kupić domu, ani samochodu. To samo dotyczy zadłużenia technicznego.

Upewnij się, że powracasz do projektu swoich zadań stopniowo i twórz testy jakości, w przeciwnym razie nie będziesz w stanie z tą samą pewnością dokonać refaktoryzacji. Upewnij się, że dokonujesz refaktoryzacji w sposób, który pomoże staremu kodowi spełnić twoje wymagania, nic więcej.

Refaktoryzuj dla przeszłości, którą znasz, a nie przyszłości, której nie znasz

Rolą programisty jest nie tylko pisanie kodu, ale także wprowadzanie sensu w świat pełen logicznych nonsensów. To praca polegająca na “znajdowaniu wzorów”.

Uważaj na ten moment „aha” i pozostaw kod w stanie, który ułatwi innym znalezienie go w przyszłości.

Podsumowanie

Być może będziemy kiedyś żyć w świecie, w którym te praktyki są normą. Niestety, jako cały rynek, daleko nam do tego. Od Ciebie zależy, czy zaczniesz go zmieniać.


Oryginał artykułu w języku angielskim możesz przeczytać tutaj.

<p>Loading...</p>