Czy powinieneś przepisać kod legacy w C#? Głębsze spojrzenie na podejście Dereka Comartina

Zasada "Nigdy nie przepisuj kodu"

Derek rozpoczyna od przywołania od dawna powtarzanej rady w dziedzinie tworzenia oprogramowania: nigdy nie przepisuj kodu od podstaw. Pogląd ten wywodzi się ze słynnego wpisu na blogu Joela Spolsky'ego zatytułowanego "Things You Should Never Do" ("Czego nigdy nie należy robić"), w którym autor stanowczo ostrzega przed przepisywaniem starszych systemów.

W 0:32 Derek wskazuje na najważniejszą myśl zawartą w artykułe Spolsky'ego:

"Popełnili najgorszy błąd strategiczny, jaki może popełnić firma programistyczna: postanowili przepisać kod od podstaw".

Derek wyjaśnia, że głównym wnioskiem jest to, że zaczynając od zera, nie ma powodu, by sądzić, że koniecznie wykonasz lepszą robotę niż za pierwszym razem. Zwłaszcza w dużych, złożonych systemach łatwo jest nie docenić ukrytej wartości tkwiącej w obecnej implementacji.

Iluzja prostoty

O 1:07 Derek wspomina swoje początki jako młodszy programista. Podobnie jak wielu innych, często chciał przepisać duże fragmenty systemu tylko dlatego, że uważał, że kod jest zły. Później jednak zdał sobie sprawę, że przekonanie to często wynikało z niezrozumieniuiuiuiuia kodu, a nie z tego, że sam kod był z natury słaby.

Dzieli się z nami prawdą, z którą każdy może się utożsamić:

"Rozpoczęcie czegoś od zera jest łatwiejsze niż konieczność zagłębiania się w kod źródłowy, całą jego złożoność i skrajne przypadki — to naprawdę trudne".

W gruncie rzeczy to, co wygląda na "pożar opon", może być po prostu niezrozumiałą logiką, która powstała w wyniku wieloletniej ewolucji i wprowadzania poprawek. Programiści często mylą nieznajomość z kiepskim projektem.

Kiedy przeróbki mogą być uzasadnione

Derek nie twierdzi jednak, że przeróbki są zawsze złe. Około 1:44 zaczyna wprowadzać niuanse. Dla zespołów, które od lat pracują nad tym samym kodem, rozumieją całą złożoność dziedziny i ograniczenia systemu — przepisanie może być dobrym rozwiązaniem.

"Jeśli korzystasz z systemu od bardzo dawna... wtedy właśnie pojawia się niuans. Można powiedzieć, że tak, ta sprawa to prawdziwa katastrofa i hamuje nas. Być może warto to przeredagować.

"Gorsze jest lepsze" i zasada 80/20

Derek wprowadza koncepcję "Worse Is Better" (gorsze jest lepsze) w 2:01, łącząc ją z zasadą Pareto (zasada 80/20). Twierdzi on, że często 80% wartości systemu pochodzi z zaledwie 20% kodu źródłowego. Dlatego podczas przepisywania celem nie powinno być wierne odtworzenie wszystkiego, ale skupienie się na tym, co naprawdę ma wartość.

"Istnieje punkt, w którym mniejsza funkcjonalność — a nawet gorsza — jest preferowaną opcją".

Wyjaśnia, że prostota i praktyczność często przeważają nad kompletnością. Ograniczony, ale użyteczny i łatwy w utrzymaniu system może sprawdzić się lepiej niż rozbudowana, ale trudna w utrzymaniu platforma starszego typu.

Ocena stosunku kosztów do korzyści

O 2:47 Derek sugeruje, że ostateczna decyzja często sprowadza się do analizy kosztów i korzyści. Przepisywanie tylko dla samego przepisywania nigdy nie jest uzasadnione. Jeśli jednak koszt utrzymania starego kodu lub ograniczenia wynikające ze starej technologii przewyższają koszt przebudowy, wówczas równanie może przechylić się na korzyść przepisania.

Autor odnosi się do sytuacji, w których Twoja przewaga konkurencyjna jest ograniczona, ponieważ utknąłeś na przestarzałych platformach lub narzędziach. W takich przypadkach sama luka technologiczna staje się uzasadnionym powodem do przebudowy.

Lekcja od Grega Younga

W 3:12 Derek przytacza znakomity wpis Grega Younga, w którym opisano przepisanie prototypu, który przypadkowo trafił do produkcji. Przepisanie zajęło 9 miesięcy. Efekt końcowy?

"Po dziewięciu miesiącach pracy nad piękną architekturą i kodem zarabialiśmy około 10 000 dolarów więcej miesięcznie".

Greg doszedł do wniosku, że lepiej byłoby zbudować 30 nowych prototypów w celu przetestowania nowych strategii, zamiast inwestować znaczne środki w przebudowę tego jednego. Derek uwielbia ten wniosek, ponieważ podważa on założenie, że celem zawsze jest techniczna doskonałość.

Czasami wygrywa oprogramowanie, które jest "wystarczająco dobre" — zwłaszcza gdy już przynosi korzyści biznesowe.

Tendencja "stare kontra nowe"

O 4:20 Derek odnosi się do powszechnego przekonania, że stare jest złe, a nowe jest dobre. Podaje osobisty przykład: integruje się z dwiema usługami innych firm, które służą temu samemu celowi. Jedno z nich wykorzystuje nowoczesny format JSON i prawdopodobnie zostało napisane w języku Python. Drugi, co zaskakujące, zwraca XML i prawdopodobnie został zbudowany w ColdFusion w latach 90.

"Oba są równoważne. Są stabilne. "Zapewniają one taką samą wartość dla mnie i moich klientów."

To pokazuje, że nowsze nie zawsze znaczy lepsze. Stabilność, niezawodność i użyteczność często mają znacznie większe znaczenie niż stos technologiczny.

Osobiste doświadczenia Dereka związane z przepisywaniem tekstów

W 5:31 Derek w końcu dzieli się swoją historią. Brał udział w zakrojonej na szeroką skalę przebudowie po spędzeniu ponad sześciu lat w domenie oryginalnego systemu. Przepisanie zajęło około 14 miesięcy, głównie z powodu luki technologicznej, która ograniczała zdolność systemu do integracji z nowoczesnymi narzędziami e-commerce i usługami online.

"Naprawdę musieliśmy stworzyć coś nowego specjalnie do tego celu".

Nie była to tylko kwestia "złego kodu" — system był zasadniczo niezdolny do ewolucji, więc przebudowa była jedyną realną drogą naprzód.

Podsumowanie

Pod koniec filmu, około 6:11, Derek podkreśla, że odpowiedź nie brzmi po prostu "tak" lub "nie".

"Nie sądzę, aby jednoznaczna odpowiedź brzmiała "nie". Uważam, że należy zachować ostrożność przy podejmowaniu tej decyzji, ponieważ kontekst ma znaczenie, a sprawa ma wiele niuansów".

Przepisanie starszego kodu C# może być konieczne — ale tylko wtedy, gdy kontekst, wiedza branżowa, dostarczana wartość i ograniczenia techniczne przemawiają za taką decyzją.

Wnioski

Film Dereka Comartina to wyważone, oparte na doświadczeniu spojrzenie na jeden z najbardziej dyskutowanych tematów w dziedzinie tworzenia oprogramowania: czy należy przepisywać starszy kod? Jego rady nie są dogmatyczne — są przemyślane, oparte na faktach i bogate w osobiste spostrzeżenia.

Odwołując się do lekcji historii, prawdziwych historii i pułapki "nowe jest lepsze", Derek pomaga widzom stworzyć dojrzałą strukturę podejmowania jednej z najbardziej znaczących decyzji w architekturze oprogramowania.

Jeśli stoisz przed podobnym wyborem w swoim projekcie C#, obejrzyj ponownie film Dereka i dokładnie rozważ kontekst. Czasami starszy kod nie jest wrogiem — jest po prostu źle rozumiany.

Obejrzyj więcej interesujących filmów na kanale Dereka w serwisie YouTube. Odwiedź CodeOpinion.com po więcej treści od Dereka.