5 typowych błędów w C# które czynią twoje oprogramowanie nieutrzymującym — Wyjaśnione przez Dereka Comartina

1. Brak kontroli nad stanem

Derek zaczyna od wskazania błędu polegającego na umożliwieniu wielu granicom lub usługom aktualizowania wspólnych danych bez jasnego określenia własności. Posługuje się przykładem, w którym system rozliczeniowy sięga do innej części aplikacji i zmienia jej stan. Prowadzi to do problemów z spójnością danych, szczególnie gdy obiekt ten znajduje się w innym miejscu w systemie.

Takie podejście typu "każdy sobie rzepkę skrobie" prowadzi do błędów, w wyniku których programiści pytają: "Dłączego te dane są nieprawidłowe?" lub "Kto je zmienił?". Derek podkreśla, że należy zdefiniować odpowiedziąlność. Każda część systemu powinna udostępniać dobrze zdefiniowany interfejs API lub metodę — odpowiedziąlną za zarządzanie stanem.

Zamiast zezwalać dowolnej części aplikacji na modyfikowanie danych współdzielonych, Derek sugeruje tworzenie wyraźnych poleceń i zapytań. Na przykład, gdy chcesz zaktualizować przesyłkę, wydajesz polecenie za pośrednictwem dedykowanego interfejsu. Zapewnia to strukturę i pozwala uniknąć wycieków zasobów spowodowanych niemożliwymi do wykrycia zmianami.

2. Kod niejawny a jawne przepływy pracy

Według Dereka wiele systemów w dużym stopniu opiera się na operacjach CRUD (Create, Read, Update, Delete), co jednak skutkuje niejawnymi przepływami pracy. Kod działa technicznie, ale brakuje mu jasności co do tego, co robi. Jeśli klasa obsługuje wyłącznie operacje ogólne, rzeczywisty przebieg procesów biznesowych pozostaje ukryty.

Weźmy następujący przykład: kierowca odbiera paczkę i generowany jest list przewozowy. Jeśli system uruchamia tylko UpdateShipment, nie jest jasne, czy zmiana ciągu znaków (np. numer BOL) wynika z odbioru czy z korekty. Derek zwraca uwagę, że powinniśmy zastąpić niejasne aktualizacje konkretnymi operacjami, takimi jak PickupStopLoaded.

Dzięki temu kod staje się bardziej czytelny. Pomaga to również w obsłudze wyjątków, ponieważ gdy wystąpi wyjątek, ślad stosu jasno wskaże, która operacja zakończyła się niepowodzeniem. Metody jawne wspierają również lepsze standardy kodowania, ponieważ każda funkcja ma jedną odpowiedziąlność.

3. Dodawanie zbędnych sformułowań pośrednich

Derek przechodzi do kwestii pośrednictwa — wstawiania zbędnych warstw pomiędzy wywołującym a metodą docelową. Ilustruje to na przykładzie połączeń z bazami danych. Kontroler może wywołać usługę, która wywołuje pomocnika, który wywołuje inną usługę, która ostatecznie wykonuje zapytanie za pośrednictwem Entity Framework.

Ta piramida abstrakcji utrudnia śledzenie problemów i poprawę wydajności. Chociaż tworzenie abstrakcji może być przydatne, na przykład opakowywanie interfejsów IDisposable w celu lepszego zarządzania zasobami, Derek ostrzega przed przesadą. Zadaj sobie pytanie, czy Twoja abstrakcja upraszcza API, czy też po prostu ukrywa zależność od podmiotu zewnętrznego, która istnieje tylko w jednym miejscu.

Zamiast tworzyć warstwy tylko dla samego tworzenia warstw, Derek sugeruje bezpośrednie zarządzanie sprzężeniem. Nadmierna pośredniość nie tylko zaśmieća kod, ale także zwiększa ryzyko wycieków pamięci i osłabia korzyści płynące z mechanizmu zbierania śmieći.

4. Zabawa w "co by było, gdyby"

Kolejnym błędem, który wskazuje Derek, jest przygotowywanie się na hipotetyczne scenariusze, które mogą nigdy nie wystąpić — nazywa to "grą w co by było, gdyby". Wielu programistów C# pisze elastyczne klasy i funkcje, aby uwzględnić przyszłe potrzeby. Na przykład: "Co zrobić, jeśli potrzebujemy obsługi dwóch języków?" lub "Co zrobić, jeśli musimy zmienić technologie?".

Derek ostrzega, że takie podejście prowadzi do rozbudowanych frameworków i zbyt ogólnego kodu. Wspomina on o napotkaniu logiki łączenia ciągów znaków i opakowań typów referencyjnych, których nikt nie rozumie, ponieważ służą one tylko w jednym rzeczywistym przypadku użycia.

Zamiast przygotowywać się na nieznane, Derek radzi skupić się na rzeczywistych wymaganiach. Każda metoda i zmienna powinna służyć aktualnemu, uzasadnionemu celowi. Niewykorzystane funkcje tylko zwiększają koszty utrzymania. Jak mówi Derek, nie chodzi tylko o czas rozwoju — chodzi o koszt posiadania. Jeśli na przykład Twoja publiczna implementacja bool Equals obejmuje każdy możliwy do wyobrażenia przypadek skrajny, ale żaden z nich faktycznie nie występuje — zmarnowałeś cenny czas.

5. Nieprawidłowe zarządzanie przepływami pracy

Na koniec Derek omawia błąd polegający na traktowaniu przepływów pracy jako bloków proceduralnych zamiast modułowych kroków. Autor posługuje się przykładem z życia wziętym: składaniem zamówienia online. Po zakończeniu procesu płatności przez użytkownika system obciąża kartę kredytową, a następnie wysyła e-mail z potwierdzeniem.

Jeśli jeden z etapów zakończy się niepowodzeniem — na przykład proces płatności — jak zareaguje Twój kod? Czy cofasz zamówienie? Zgłoś błąd? Wysłać wiadomość e-mail o niepowodzeniu? Derek wyjaśnia, że wrzucenie tego wszystkiego do jednego bloku powoduje niekontrolowaną złożoność.

Zaleca projektowanie przepływów pracy jako małych, izolowanych jednostek, które komunikują się za pomocą komunikatów. Wykorzystanie operacji async Task i yield return ułatwia zarządzanie tymi krokami. Ponadto stosowanie instrukcji using i bloku using w odniesieniu do zasobów zewnętrznych, takich jak dostęp do plików lub połączenia z bazami danych, może pomóc w zapobieganiu wyciekom pamięci.

Na przykład blok using otaczający strumień zapewnia jego prawidłowe usunięcie — jest to kluczowa kwestia podczas pracy z interfejsami IDisposable. Gdy procesy robocze stają się złożone, te najlepsze praktyki zapewniają skuteczne wykrywanie i obsługę wyjątków, zachowując wydajność i łatwość konserwacji.

Podsumowanie: pisz czysty, łatwy w utrzymaniu kod

Jak podsumowuje Derek w swoim filmie o 12:45, rozważa te błędy nie tylko jako rzeczy, które widział, ale także jako rzeczy, które sam popełnił podczas tworzenia dużych systemów biznesowych. Są to wnioski wyciągnięte z doświadczenia, a autor zachęca czytelników do dzielenia się własnymi błędami w komentarzach.

Rada Dereka dotyczy nie tylko języka C#, ale również wielu innych języków. Niezależnie od tego, czy pracujesz nad porównywaniem ciągów znaków, metodami Equals(), czy projektujesz nowe funkcje, kluczem jest przejrzystość, intencja i zapewnienie łatwości utrzymania kodu.

Jeśli chcesz podnieść swoje umiejętności w zakresie języka C# i uniknąć tych typowych pułapek, kanał Dereka oferuje wiele bezpłatnych zasobów dotyczących architektury systemówej, wzorców projektowych oraz praktycznych porad dotyczących języków programowania. Uniknięcie choćby jednego z tych błędów może znacznie poprawić jakość Twojego projektu.

Kiedy więc następnym razem zaczniesz pisać kod, pamiętaj o słowach Dereka i zadaj sobie pytanie: "Czy nie komplikuję tego bardziej, niż to konieczne?".

Aby uzyskać więcej podobnych treści, odwiedź kanał YouTube CodeOpinion Dereka Martina.