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

20

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.
Joseph
źródło
3
@gnat, myślę, że pytania są powiązane (szczególnie ostatnie), ale nie dublują się. Widzę to pytanie jako „Biorąc pod uwagę, że architekt systemu nie jest implementatorem, a implementatorzy nie mają widoku systemu na wysokim poziomie, w jaki sposób można zapewnić, że implementacje są wystarczająco elastyczne lub skalowalne?”
MetaFight,
1
Zastanawiasz się, jak ogólnie walczyć z długiem technicznym, czy pytasz, jak walczyć z długiem technicznym, gdy pełnisz rolę kodera bez przypisanej odpowiedzialności za ulepszenie architektury?
Doc Brown
2
@JosephtheDreamer Tak, istnieje wiele rzeczy, które można zrobić, aby poprawić kod źródłowy, ale w swoim pytaniu stwierdziłeś, że problemem jest brak uprawnień do działania w przypadku jakichkolwiek zmian. Mógłbym opowiedzieć o wszystkich najlepszych praktykach, ale jeśli nie możesz zainwestować ogromnej ilości czasu w ich wdrożenie, to po co? ;)
Reactgular
2
Ale zadania pochodzą od wyższych ludzi ” - co powstrzymuje cię przed powierzeniem sobie innych zadań niż „ Nie otrzymuję za to zapłaty ” dzisiaj? Jeśli zachowujesz się jak pszczoła robotnicza przyjmująca polecenia, będziesz traktowany jak jeden.
JensG

Odpowiedzi:

22

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:>
http://i.stack.imgur.com/ARBSs.jpg


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” 1 ...

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ć.

komar
źródło
7
+1 Dobra rada, ale śledzenie problemów w środowisku, które nie obejmuje procesu, staje się po prostu czarną dziurą. Co dobrego, to śledzenie problemów jednej osoby. W najlepszym razie wymyślna lista rzeczy do zrobienia.
Reactgular
@MathewFoscarini przed opublikowaniem, wyjaśniłem to w OP w komentarzach (w mojej odpowiedzi pod linkiem „Twój system śledzenia problemów”) - „Tak, stąd„ zadania ”(problemy, bilety, jakkolwiek je nazwiesz) ...” Nie byłbym również tak pesymistyczny w sprawach „czarnej dziury”, na dłuższą metę rzeczy mają tendencję do zmiany, szczególnie jeśli deweloperzy „najniższego poziomu” podejmą inicjatywę i zainwestują wysiłki w utrzymanie trackera i samodzielne promowanie jego użycia (czy zostało to tam zrobione )
komar
A na dodatek widziałem ludzi obwinianych za zanieczyszczenie systemu biletowego (= otwieranie „zbyt wielu” biletów). Jeśli kultura nie pasuje, żaden system biletów nie pomoże. Niestety, technicznie ludzie szukają raczej narzędzia technicznego niż rozwiązania, a inni ludzie uważają go za dobrą radę, ponieważ pasuje do ich procesu myślenia.
JensG
1
@JensG „ludzie są obwiniani za zanieczyszczenie systemu biletowego” - jest to znane zjawisko, prawdopodobnie zasługujące na specjalne pytanie (a może już zostało zadane i udzielono odpowiedzi, nie szukałem). Jeśli kultura nie pasuje, konieczne są dodatkowe szczególne wysiłki, aby system biletowy stał się pomocny (jak napisałem w poprzednim komentarzu, już to robiłem).
komar
8

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.

JensG
źródło
8

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).
svidgen
źródło
Ta odpowiedź jest dokładnie tym, co bym zrobił. Nie umieszczam drobnych zadań refaktoryzacyjnych w narzędziu do śledzenia problemów. Właśnie refaktoryzowałem. Umieszczenie każdego drobnego zadłużenia technicznego w zaległościach po prostu tworzy ogromną listę problemów, co utrudni im uzyskanie widoczności, a zanim ktokolwiek zacznie pracować nad takim zadaniem, problem może zniknąć, zmienić formę , pogorszyła się, przeniosła lub kto wie co. Jeśli zajmie to 5 minut, po prostu to napraw!
Brandon,
5

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.

DougM
źródło
2
„Dług techniczny rzadko powoduje upadek przedsiębiorstwa kończący zatrudnienie”. Nie byłbym taki pewien. Przyczyną niepowodzenia wielu projektów oprogramowania jest dług techniczny.
Euforii
2
Projekt nie jest przedsięwzięciem @Euphoric. Mozilla nie jest zlikwidowana tylko dlatego, że Sunbird nigdy nie wystartował. Jeśli twój projekt się nie powiedzie, przejdziesz do nowego projektu z tym samym pracodawcą. Jeśli Twoje przedsiębiorstwo zawiedzie, musisz znaleźć nową pracę.
DougM
Ta odpowiedź jest bardzo błędna. Widziałem, jak dług techniczny niszczy produkt dla przedsiębiorstw. A jeśli chodzi o „technicznie dług nie jest dosłownie twoim problemem”, na kim spoczywa odpowiedzialność, jeśli nie twórcy oprogramowania?
Brandon
2

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ć.

winkbrace
źródło
4
czy to tylko Twoja opinia, czy możesz jakoś to zrobić? Na poziomie OP („najniższym”) „naciśnięcie hamulca, mówiąc„ nie ”z mojego doświadczenia rzadko okazało się w porządku. Ani dla projektu, ani dla kariery. Patrząc wstecz, wyraźnie przypominam sobie przypadki, w których coś mi umknęło , gdy „odmówiłem” wbrew wizji starszych kolegów / kierownika / menedżera
komnata
Jeśli chodzi o zasoby ludzkie, pozostawienie ludzi za biletami do pracy bez właściwego uwzględnienia ich obaw związanych z wartością pracy może zakończyć się katastrofą. Szczęśliwi pracownicy pracują więcej za mniej, jest na to dowód ekonomiczny. Hamowanie jest okazją do nauki zarówno dla juniorów, jak i kadry kierowniczej. Hamowanie jest tym, jak startupy mogą być tak kompetentne w tak krótkim czasie, że nie mamy cholernych biletów. Może powodować konflikt, ale konflikt jest częścią cholernego życia. Dbanie o jakość powinno być wysłuchane i egzekwowane, więc jestem po stronie hamulców.
Arthur Havlicek
2
Polecam lekturę, która traktuje o wzmacniaczach niskiego poziomu wzmacniających joelonsoftware.com/articles/TwoStories.html
Arthur Havlicek