Zwalczanie długu technicznego jako „najniższego dewelopera”?

Załóżmy, że pracujesz dla firmy i tworzysz dla nich oprogramowanie. Nie masz pojęcia o dużym obrazie, a może drobnym. To, co masz, to zadania przypisane do ciebie przez system śledzenia problemów. Otrzymujesz zadania, sprawiasz, że działają tak, jak je opisuje zadanie, odsyłasz je z powrotem. Jak dodanie 2 liczb całkowitych:

function add(a,b){return a + b;}

Ale później, w miarę postępu projektu, zauważasz, że w miarę jak addstaje się bardziej złożony, zdajesz sobie sprawę, że powinien on potrzebować jakiejś formy architektury, więcej niż funkcji, która dodaje parametry i zwraca wartość. Jednak tego nie wiedziałeś. Po pierwsze, wszystko, czego potrzebowali, było takie proste add. Nie spodziewałeś się, że add stanie się tak skomplikowany.

Projekt rozwija się z większą liczbą funkcji, których nie spodziewałeś się po pierwsze. I na koniec, gromadzisz kolejne hacki i warstwa po warstwie funkcji, aby uniknąć łamania / przepisywania istniejącego kodu.

Jak sobie radzisz z tymi sytuacjami? Jak walczysz z długiem technicznym jako „najniższy programista”?

Wyjaśnienie:

• Jesteś „implementatorem”, najniższym w hierarchii.

• Widzisz problem, ale nie masz nic do powiedzenia w tej sprawie.

• Nie liczę długu technicznego ani nie szukam narzędzi.

• Odnośnie trzeciego „duplikatu”

  • Refaktoryzacja i przepisywanie - Jesteś zablokowany dla swoich zadań. Nie otrzymujesz dodatkowych opłat.
  • Przegląd architektury - znasz cały system, ale nie masz pojęcia o architekturze.
  • Zamrożenie kodu - to nie twoje połączenie. Nie jesteś zarządem.
  • Modularyzacja - brak pomysłu na architekturę. Moduły zmieniają się wraz ze zmianami wymagań.
  • Zautomatyzowane testy - Brak.

Za każdym razem, gdy zauważysz coś takiego, wprowadź nowy bilet do swojego systemu śledzenia problemów.

Przyzwyczaj się do używania narzędzia do śledzenia problemów jako podstawowego narzędzia do komunikowania takich rzeczy, ponieważ od tego momentu będzie łatwo wybierać, oceniać i ustalać priorytety dla starszych pracowników / kierownika / kierownika / osoby odpowiedzialnej za śledzenie problemów w projekcie .

Użyj odpowiedniego narzędzia do pracy. Robię to zawsze i zdecydowanie polecam zrobić to samo.

Jako przykład, oto bilet, który utworzyłem około miesiąc temu. Po zakończeniu konkretnej funkcji odkryłem, że kod stał się znacznie bardziej skomplikowany niż wcześniej, ale nie mogę tego naprawić w terminie podanym na wdrożenie funkcji.

(Nazwy funkcji, biletów i kodu używane w prawdziwym module śledzącym są ukryte, ale tekst jest kopiowany w niezmienionej postaci).

Podsumowanie: uproszczenie projektowania obejmująceParticularPieceOfCode

Opis:
W trakcie implementacji według TICKET-12345, kod wymagający użycia ParticularPieceOfCodenarosł trochę komplikacji i stał się raczej trudny do odczytania, zrozumienia i utrzymania (patrz przykładowy fragment kodu poniżej).

Znajdź sposób na uproszczenie.

Przykład kodu, który byłby pożądany do przeprojektowania można znaleźć w ClassName#methodName:

<a piece of code like one behind the right door here:>

FWIW moja rada obowiązuje niezależnie od tego, jakim jesteś „poziomem”.

Używam go na twoim obecnym („najniższym”) poziomie i używam go teraz, kiedy mój poziom jest dość daleki od „najniższego” i mam zadowalające „powiedz”, jak to nazywasz, i zamierzam go użyć zawsze bez względu na wszystko.

Pomyśl o tym, bez żadnego poziomu, bez względu na to, ile masz władzy, po prostu nie ma lepszego sposobu.

Jeśli powiesz „ hej ”, mamy problem , to tylko grzechotanie powietrza. I nawet jeśli twój szef / dowódca się zgodzi i powie, że masz rację, mamy problem , to nic nie zmienia - to tylko grzechotanie powietrzem po raz kolejny i nie może być niczym innym.

• ^{Możesz pomyśleć, że napisanie swojego zdania (np. W e-mailu) byłoby lepsze, ale jeśli o tym pomyślisz, tak naprawdę nie jest. Jeśli twój projekt ma znaczną aktywność pocztową, to co zostało napisane, zostanie utracone i długo zapomniane miesiąc później.}

Użyj odpowiedniego narzędzia do pracy. Śledzenie problemów jest właściwym narzędziem dla opisywanego zadania .

Zauważysz problem, wprowadzasz go do systemu przeznaczonego do śledzenia go, a on zajmuje się resztą w najlepszy możliwy sposób - po prostu dlatego, że został zaprojektowany do tego :

pakiet oprogramowania komputerowego, który zarządza i utrzymuje listy problemów , zgodnie z potrzebami organizacji ... często używane ... do tworzenia, aktualizowania i rozwiązywania zgłaszanych problemów klientów, a nawet problemów zgłaszanych przez innych pracowników tej organizacji ... Śledzenie problemów system jest podobny do „ narzędzia do śledzenia błędów ” i często firma zajmująca się oprogramowaniem sprzedaje oba urządzenia, a niektóre narzędzia do śledzenia błędów mogą być używane jako system śledzenia problemów i odwrotnie. Konsekwentne korzystanie z systemu śledzenia problemów lub błędów jest uważane za „znak rozpoznawczy dobrego zespołu programistycznego” ¹ ...

Niezależnie od innych środków komunikacji, posiadanie biletu w trackerze ułatwi ci to.

Nawet jeśli wolisz grzechotać w powietrzu , powiedzenie „Chciałbym omówić BILET-54321 ...” stanowi bardziej solidny punkt wyjścia niż „Słuchaj, chciałbym porozmawiać o jakimś fragmencie kodu, z którym miałem do czynienia jakiś czas temu ... ”I możesz bezpiecznie przekazać referencje do biletu pocztą: nawet jeśli poczta zaginie, problem nadal będzie występował w module śledzącym, wraz ze wszystkimi szczegółami, o których chciałeś powiedzieć.

Co sprawia, że ​​czuję się źle z powodu twojego scenariusza, to dokładnie to, co napisałeś w nagłówku i wielokrotnie w tekście pytania:

Jesteś najniższym programistą w łańcuchu

Dlaczego ten punkt jest tak ważny? Po pierwsze, i z czysto technicznego punktu widzenia masz rację. Jesteś zatrudniony jako „implementator” rzeczy, pszczoła robotnicza, która działa na podstawie wydanych poleceń.

Ale nawet jeśli jesteś najniższym deweloperem pod względem rangi, nadal nie jest to w porządku. Kluczem tutaj jest uświadomienie sobie, że postrzegasz siebie jedynie jako najniższego programistę. Czy kiedykolwiek próbowałeś przezwyciężyć to postrzeganie siebie i faktycznie przejąć odpowiedzialność za coś ?

Brać! Nie czekaj, aż ktoś uczyni cię odpowiedzialnym.

• Widzisz problem, ale nie masz nic do powiedzenia w tej sprawie.
• Nie liczę długu technicznego ani nie szukam narzędzi.
• Jesteś zablokowany dla swoich zadań. Nie otrzymujesz dodatkowych opłat.
• Nie twój telefon. Nie jesteś zarządem.

Zazwyczaj jest odwrotnie: zarabiasz więcej, a twoja opinia jest szanowana bardziej, gdy pokażesz, że jesteś wart swojej ceny . To „zrób wcześniej”, a nie na odwrót.

Od ludzi w moim zespole oczekuję dokładnie tego: poczucia odpowiedzialności za projekt lub produkt, który staramy się zbudować i za wszystkie procesy związane z tym wysiłkiem. Gdy ktoś w moich robi na mnie wrażenie zespołu przejmując odpowiedzialność, np proponowanie usprawnień lub nawet lepszy start do poprawy rzeczy na własną rękę, to są ludzie, którzy będą awansować.

Innymi słowy: nikt nie promuje robotniczych pszczół, ludzi biernie czekających na przydzielone im zadania, pozbawionych nawet najmniejszego mrugnięcia inicjatywą „ ponieważ nie są za to wynagrodzeni ”, w końcu jęcząc, że nigdy nie mieli szansy.

Oczywiście wszystko to znowu zależy od kultury twojej firmy, do czego Joel odnosi się w „Two Stories” powiązanych przez Arthura. Jeśli menedżerowie firmy są naprawdę tak głupi, aby blokować swoim ludziom postęp, wówczas wskaźnik fluktuacji jest już prawdopodobnie bardzo wysoki i może być czas na wyciągnięcie z tego wniosków. Ale jeśli tak nie jest, prawdziwy problem może tkwić w tobie.

Jesteś profesjonalistą. Twój pracodawca zatrudnił Cię jako profesjonalistę. Tak więc traktuj swoje obawy w taki sam sposób, w jaki zatrudniani przez Ciebie profesjonaliści traktują ich profesjonalne opinie . W szczególności oczekujesz, że inni specjaliści dokonają po drodze niezbędnych optymalizacji i poprawek, pod warunkiem, że te optymalizacje nie zwiększą nieoczekiwanie kosztów.

Załóżmy na przykład, że zabierasz samochód do mechanika, aby wymienić lampę. Mechanik zauważa cztery rzeczy:

1. Drut prowadzący do lampy jest postrzępiony i niebezpieczny. Ale można go przyciąć bez znacznego wzrostu kosztów. Spodziewałbyś się, że zajmie kilka minut, aby przyciąć drut, być może nawet tego nie zauważając.
2. Śruba jest luźna. To jest całkowicie niezwiązane, po prostu to zobaczył. To 20 sekund jego czasu, aby złapać niezbędnego kierowcę i dokręcić go; więc można oczekiwać, że on to zrobi.
3. Podwozie lampy jest popękane, co spowoduje grzechotanie lampy. Wymiana jest droga. I to nie jest konieczne. Dzwoni więc do ciebie, by o to zapytać - jeśli powiesz „nie”, to na piśmie podsumuje wizytę.
4. Pod samochodem jest spora ilość płynu hamulcowego. Powinien, a nawet może być wymagany jako profesjonalista, aby uniemożliwić ci korzystanie z samochodu, dopóki nie pozwolisz komuś naprawić wycieku.

Każdy z tych scenariuszy, i jestem pewien, że inne, mają podobieństwa w tworzeniu oprogramowania - szczególnie jeśli uważasz się za profesjonalistę na dowolnym poziomie . Jako profesjonalista, z bardzo nielicznymi wyjątkami, Twoim zadaniem jest osiągnięcie celu końcowego, jakim jest ulepszenie produktu w określony sposób, zgodnie z Twoim profesjonalnym zrozumieniem .

1. Jeśli poprawka jest trywialna, niezwiązana lub nie, wykonaj poprawkę.
2. Jeśli poprawka nie jest trywialna i nie jest potrzebna, sformułuj formalne zalecenie, korzystając z dowolnego formalnego mechanizmu komunikacji / śledzenia problemów, na jaki się zgodziłeś.
3. Jeśli można stwierdzić, że poprawka jest konieczna do wykonania głównego zadania, ale niespodziewanie zwiększy koszt, poinformuj o zmianie zakresu.
4. Jeśli zidentyfikowany problem stanowi poważne zagrożenie dla powodzenia projektu, wyjaśnij to. Formalnie. Jeśli istnieją etyczne obawy związane z dopuszczeniem do usunięcia problemu (np. W systemach opieki zdrowotnej, w nagłych wypadkach lub w transporcie), nalegaj, aby rozwiązać problem przed wysłaniem produktu (powiadomić media lub władze, jeśli jest to etycznie konieczne).

Robisz to w ten sam sposób, w jaki urzędnik w kancelarii walczy z nieetycznymi zachowaniami, pracownik fast foodu walczy z niehigienicznymi zachowaniami, a funkcjonariusz parkingu walczy z korupcją policji.

1. Bądź dobrym przykładem. W miarę możliwości możesz stworzyć czysty i rozsądny kod. Kiedy masz wybór, wybierz ten, który spełnia Twoje wymagania z mniejszym minusem. (Należy pamiętać, że dług techniczny nie jest podobny do długu hipotecznego - samo posiadanie go niekoniecznie jest czymś złym.)
2. Przekaż swoje obawy . Powinieneś mieć kogoś, kierownika zespołu, klienta lub architekta, który ponosi rzeczywistą odpowiedzialność za zarządzanie długiem technicznym i alokację zasobów przedsiębiorstwa. Kiedy zobaczysz coś, co uważasz za złe, przekaż im swoje obawy. Wpisz to na piśmie (np. W e-mailu), jeśli nie masz pewności, że zrozumieją, odpowiedzą i uznają twój wkład.
3. Nie stresuj się Dług techniczny rzadko powoduje awarię kończącą zatrudnienie w przedsiębiorstwie. Tak długo, jak przekażesz swoje obawy i wykonujesz swoją pracę, problemy związane z architekturą, takie jak dług techniczny, dosłownie nie są twoim problemem. Tak, mogą wpływać na ciebie, ale nie martw się bardziej niż ponowny wybór szeryfa jest zmartwieniem młodszego funkcjonariusza policji.

W podanym przykładzie z addfunkcją, która uległa całkowitemu pełzaniu funkcji, poświęć kilka minut i szkicuj, co by to poprawiło. Wyślij to do kogokolwiek, kto będzie potrzebował zgody na jego wdrożenie, i przejdź dalej.

Zakładając, że twoje przedsiębiorstwo było zarządzane przez wyjątkowo kompetentnych ludzi i posiadało prawidłową strukturę, albo twoja obawa zostanie skierowana do właściwego projektanta systemu w celu podjęcia decyzji, albo będziesz mieć swobodę w realizacji swojej sugestii. Jako młodszy programista martwię się bardziej o naukę działania twojego przedsiębiorstwa niż dług techniczny - a jeśli znasz ten pierwszy, to jak sobie poradzić z tym drugim, powinno być oczywiste.

Nigdy nie słyszałem o organizacji, która nie chciałaby, aby uczestniczyli w niej pracownicy. Mówisz, że zarabiasz tylko za wykonywanie zadań. Szczerze wątpię, czy masz na myśli właściwe zadania. Ponieważ otrzymujesz wynagrodzenie za pisanie dobrego oprogramowania.

Weź na siebie odpowiedzialność. Powiedz „nie”, aby dodać funkcje, jeśli nie możesz obsługiwać bazy. Poradzić klientowi swoją wiedzę. Wciśnij hamulce teraz, zanim będzie za późno i musisz wyrzucić cały projekt, ponieważ nie będzie już można go utrzymać.