Co to jest dług technologiczny?

Długi techniczne są znanymi punktami implementacji inżynierii, które można świadomie wybrać, aby nie wdrażać ich w tej chwili. Długi technologiczne są powszechne, ale muszą być rozważnie przemyślane. Przedstawimy kilka wskazówek, kiedy/jak je oceniać.

Idealnie, każdy fragment kodu — podczas pierwszej implementacji powinien obsłużyć wszystkie znane przypadki. Mogą jednak istnieć blokady:

1. W niektórych przypadkach, miejmy nadzieję, rzadkich — funkcjonalność produktu lub logika inżynierska mogą nie być jasne. Może to być również niejasna skala lub wymagania dotyczące ruchu, co prowadzi do ryzyka niedostatecznego lub nadmiernego przygotowania do ruchu i skali.
2. Nawet jeśli implementacja jest jasna dla rzadkich przypadków użycia, implementacja może być złożona lub czasochłonna.

Wszyscy chcielibyśmy zminimalizować długi technologiczne, ale są chwile, kiedy warto je wziąć.

Konieczność pójścia do przodu

Chociaż brak wszystkich szczegółów lub pełnej implementacji może przeszkadzać, często trzeba iść do przodu z kombinacji następujących powodów:

1. Często trzeba coś zbudować lub wdrożyć, aby odpowiedzieć na dalsze pytania, wykorzystując częściowe informacje zwrotne od użytkowników lub klientów. Roztrząsanie może prowadzić do kosztownych opóźnień i rozsądniej jest zaryzykować niedoskonałą implementację niż jej brak.
2. Konkretny brak przejrzystości może być stosunkowo nieistotny w szerszym schemacie budowanej funkcjonalności, może być łatwo dodany lub poprawiony, a brak implementacji funkcjonalności może być bardziej kosztowny.

Cechy

Kiedy zaciągamy dług technologiczny, świadomie zdecydowaliśmy się na zamianę być może bardziej poprawnej implementacji na implementację częściową. Dobry dług technologiczny:

1. Gdy dług technologiczny zostanie rozwiązany, powoduje mniejszą zmianę kodu w kodzie aktualnie wybranej implementacji i
2. Prowadzi do płynnej awarii jakiejś nietypowej części funkcjonalności. I odwrotnie, po naprawieniu — jest to stopniowa poprawa funkcji.

Należy wziąć tylko dobre długi technologiczne spełniające powyższe cechy. Poniższe pytania pomogą nam ocenić.

Koszt

Niektóre pytania, które należy zadać przy ocenie kosztów zaciągnięcia długu technologicznego lub pominiętej sprawy:

1. Gdzie jest brakująca funkcjonalność — np. w wizualizacji/prezentacji danych lub generowaniu danych? Mówiąc dokładniej, czy pominięta funkcjonalność prowadzi do trwałych błędnych danych?
2. Jaka jest wada doświadczenia użytkownika? Czy jest to powszechny przypadek użycia, z którego użytkownicy mogą się potknąć i być niezadowoleni, czy też rzadki przypadek na marginesie naszej podstawowej propozycji wartości?
3. Czy jesteśmy pewni szczegółów projektu i implementacji brakujących lub pominiętych funkcjonalności? A może wolelibyśmy otrzymać informację zwrotną na temat częściowej implementacji, aby ją zdefiniować?

Zaciągamy długi technologiczne w celu uzyskania określonych korzyści:

1. Szybsze wydanie, potencjalnie prowadzące do zwiększenia sprzedaży lub zadowolenia klientów.
2. Możliwość uzyskania danych dotyczących adopcji lub informacji zwrotnych, co może prowadzić do lepszego zaprojektowania brakujących funkcji. Może to być potrzebne w przypadku niektórych niejasnych funkcji.
3. Koszt alternatywny prac inżynierskich zaoszczędzony w krótkim okresie.

Przestrzeganie podstawowych fundamentalnych zasad solidnego projektowania minimalizuje przeróbki, które pociąga za sobą rozwiązanie problemu długu technologicznego.

Modułowość

Upewnij się, że usługi i obiekty są dobrze przemyślane dzięki dobrze zdefiniowanym interfejsom. Modułowość umożliwia lokalizowanie zmian bez minimalizowania przeróbek kodu.

Staraj się myśleć nie tylko bezpośrednio, np

1. Jeśli obecnie mamy jedną implementację funkcjonalności, ale później możemy być może umieścić implementację jako podklasę interfejsu. Ułatwia to późniejsze dodawanie kolejnych implementacji.
2. Jeśli jednostka ma obecnie jedną możliwą wartość dla pola, ale później może mieć więcej, ustaw to jako wyliczenie.

Czysty schemat

Dobry schemat bazy danych i model ORM, który dokładnie odwzorowuje rzeczywisty przypadek użycia, zwykle jest odporny na dalsze zmiany.

Dobre praktyki kodowania

1. Zachowaj wartości, które mogą zostać zmienione DRY i nie głęboko w kodzie. Mogą to być zmienne konfiguracji danych wejściowych środowiska wykonawczego lub stałe kodu. To musi być świadoma decyzja.
2. Niektóre funkcje wymagają możliwości szybkiej iteracji lub dostosowania do potrzeb klienta. Używaj narzędzi o niskim poziomie kodowania / bez kodu, które są łatwe do iteracji — nawet w pewnym stopniu przez osoby niebędące inżynierami. I jest mniej kodu, a tym samym mniej rezygnacji.
3. Obowiązują ogólne praktyki kodowania i projektowania, o których mowa powyżej — tj. utrzymuj kod DRY (łatwo jest zmienić kod w jednym miejscu), utrzymuj go w prostocie (stąd łatwiejsze zrozumienie zmiany) itp.
4. Niektóre zmiany będą addytywne — dosłownie bazujące na status quo — np. dodanie zestawów replik do istniejącego serwera bazy danych Mongo z pojedynczym węzłem lub sharding na serwerze bazy danych Mongo. Jeśli wdrożenie ich będzie kosztowne, potrzebę takich ulepszeń można przesunąć w czasie, aż będą potrzebne, bez dodatkowego wysiłku.

Brak obsługi wszystkich przypadków nie jest wystarczającym powodem do sprawdzenia kodu. Zamiast tego poniżej znajduje się jeden ze sposobów, aby przejść dalej:

1. Kontynuuj zatwierdzanie kodu w swoim oddziale z dużą ilością komentarzy TODO na temat oczekujących funkcji lub elementów wyjaśniających.
2. Najlepiej rozwiązać wszystkie TODO przed zgłoszeniem żądania ściągnięcia.
3. Każdy nierozwiązany problem staje się długiem technologicznym — upewnij się, że weryfikator kodu i odpowiedni kierownik techniczny/kierownik są oznaczeni / informacja, dług technologiczny utworzony przez Jira i podany w komentarzu identyfikator Jira. Mamy nadzieję, że przegląd PR powinien ponownie potwierdzić, że dług technologiczny jest w porządku.
4. Upewnij się, że kod poradzi sobie nawet z nieobsługiwanymi przypadkami — np. frontend otrzyma odpowiednią odpowiedź API, aby pokazać błąd nieobsługiwanego jeszcze wejścia API, niż awarię backendu.
5. Pamiętaj o harmonogramie długu technologicznego Jira, być może zachowując go w następnym sprincie, aby pojawił się w wezwaniu do wstępnego przeglądu planowania sprintu.