Jak ważne jest czyszczenie kodu innej osoby w obliczu napiętego terminu? [Zamknięte]

(Mówię o kodzie HTML / CSS (nie językach programowania), ale myślę, że mamy również ten sam problem, co w przypadku programistów).

Jestem starszym projektantem front-end w zespole i często muszę przerabiać wyniki moich juniorów w napiętych terminach.

Mam do czynienia z 2 problemami:

1. Ich styl kodowania to trochę bałagan.
2. Estetyka nie jest dobra.

Uważam, że ich styl kodowania to mieszana torba bez odpowiedniej konwencji / standardu. Jestem rozdarty między czyszczeniem kodu a po prostu zajmowaniem się jego kodem (nawet kopiowaniem, jak to robią).

Śledzenie ich stylu kodowania jest frustrujące, ponieważ czuję, że mogę nauczyć się złych nawyków. Ale to jest najszybszy sposób dotrzymania terminu.

Dla osób z dużo większym doświadczeniem, co jest bardziej skuteczne? Czy powinienem zachować sprzątanie na później? Lub sprzątanie po drodze, gdy wprowadzam zmiany?

(Nie chcę jednak brzmieć arogancko, ale taka jest rzeczywistość. Napisanie lepszego kodu zajmie im więcej lat. Wiem, pisałem niechlujny kod, kiedy zaczynałem.)

Uważam, że źle patrzysz na problem - tracisz świetną okazję do nauczenia juniorów, jak pisać lepszy kod.

Jeśli zwykle piszesz na nowo swój kod, możesz sprawić, że juniorzy mają wrażenie, że nie cenisz ich pracy, co obniży ich morale i nie pomoże im lepiej kodować następnym razem.

Uważam, że lepszym podejściem jest dodanie do procesu rozwoju zespołu zadania przeglądu kodu. Nie musi to dotyczyć każdego kawałka popełnionego kodu i nie musi (twierdzę, że nie powinien) być przeprowadzane tylko przez ciebie - za każdym razem, gdy członek twojego zespołu kończy wystarczająco duże zadanie, powinien sparować z jednym (lub więcej) z kolegami z zespołu, wyjaśnić im kod i otrzymać konstruktywną opinię i krytykę na temat jego projektu, stylu kodowania, możliwych błędów i problemów bezpieczeństwa itp.

Gdy kolega z zespołu recenzującego kod jest tobą, nauczy się dużo więcej od twojej wiedzy niż wtedy, gdy po prostu ponownie napiszesz jego kod (mają szansę usłyszeć powód, dla którego kod powinien zostać zmieniony), i może rzucić mniej obrażeń.

Danie im okazji do przeprowadzenia przeglądu kodu jeszcze bardziej poprawi ich umiejętności - zobacząc, jak inni ludzie piszą kod i dlaczego - oraz zwiększy ich samoocenę.

Nauczą się również dużo, jeśli dasz im szansę na sprawdzenie twojego kodu. Ty też możesz się czegoś nauczyć - więc nie rób tego tylko na pokaz!

Powiedziałem to już wcześniej i powtórzę „działający kod jest cenniejszy niż ładny kod”.

Jeśli zmienisz kod, istnieje duże prawdopodobieństwo, że zmienisz jego zachowanie, jeśli jest to kod testowany, właśnie unieważniłeś cały wysiłek testowy i będziesz musiał powtórzyć testy.

Z całą pewnością zachęcaj swoich juniorów do pisania czystego, zrozumiałego kodu, ale jeśli zamierzasz ponownie napisać wszystko, co piszą, marnujesz pieniądze pracodawców kilka razy. Muszą zapłacić za twoich juniorów, a następnie zapłacić za zrobienie tego, co już zapłacili juniorom, a następnie zapłacić za ciebie jeszcze raz za pracę, za którą faktycznie cię zatrudnili.

• Krótka odpowiedź brzmi: nie. Kiedy czasy są ciężkie, czasami musisz po prostu opuścić głowę i wziąć estetyczny pocisk. ;)

• Bardziej pragmatyczną odpowiedzią jest ustalenie terminu. Budżet na godzinę, aby przejść i wyczyścić jeden konkretny aspekt kodu. Następnie sprawdź to i zrób prawdziwą pracę. Ale bądź ze sobą szczery w kwestii ograniczania tego.

• Czasami jednak odrobina sprzątania przyspiesza pracę. Nawet niektóre szybkie zmiany typu „szukaj i zamień” sprawiają, że wszystko jest bardziej dostępne.

• Uważaj na wojny stylowe. Zwłaszcza w przypadku napiętego terminu, jeśli zamierzasz cofnąć pewne preferencje stylistyczne, które drugi programista po prostu przerwie, to znowu lepiej zaczekaj, aż będziesz miał czas, aby naprawdę ustalić, w jaki sposób chcesz rozwiązać te problemy. problemy stylistyczne we współpracy. (Co oznacza, że ​​niektórzy dają i biorą.)

Ale w odpowiedzi jest wartość oceny. Powiedziałbym „umiarkowanie” ważne. Czysty kod naprawdę może przyspieszyć pracę, a jakość kodu jest przecież częścią dostarczanego produktu. Nie sądzę, że mogę dotknąć kodu (nawet własnego) bez poświęcania czasu na czyszczenie. Ale upewnij się, że zamieszanie ze stylem i formatem oraz wojny o styl nie stają się ważniejsze niż wprowadzenie kodu do produkcji.

Przy ustalaniu kodu i po upływie terminu stosuję zwykle dwie reguły:

Kod jest okropny, ale można znaleźć problem w rozsądnym czasie i go naprawić

Naprawiam problem, a resztę pozostawiam nietkniętą .

Kod jest tak niechlujny, że naprawdę trudno jest znaleźć problem. Naprawienie czegoś powoduje natychmiastowe przerwanie czegoś innego. Prawdopodobnie szybciej byłoby napisać ten kod od zera niż go naprawić.

Potem nie mam innego wyboru niż przepisanie / refaktoryzacja, dopóki kod nie będzie wystarczająco czysty, aby zlokalizować i naprawić błąd.

Graniczny przypadek jest:

Kod jest niechlujny i naprawdę zły. Nadal można naprawić błąd w rozsądnym czasie, ale struktura kodu naprawdę utrudni jego utrzymanie. Każda nowa funkcja najprawdopodobniej wprowadzi nowe błędy lub spowoduje znaczny spadek wydajności.

W takim przypadku kod ma zostać naprawiony, ale tylko wtedy, gdy nowe funkcje mają zostać zaimplementowane, włączone w czasie bezczynności, nigdy w czasie usuwania błędów w obliczu terminu!

Byłbym zainteresowany, aby dowiedzieć się, w którym momencie procesu znajdujesz ten problem?

Ściśle mówiąc, w tym magicznym idealnym świecie, w którym nikt z nas nie mieszka, cały kod promowany lub wdrażany powinien być idealny. Nie zawsze trzeba być pragmatycznym.

Jeśli jednak masz proces sprawdzania kodu, powinien on to podkreślić przed testowaniem. Jeśli ciągle dotrzymujesz terminów, czy problemy z oszacowaniem dostawy oznaczają, że kluczowy element każdego procesu programistycznego - tj. - przeglądu kodu - zostaje uduszony?

Twoi juniorzy nigdy nie nauczą się siadać i przyswajać lepsze sposoby robienia rzeczy, jeśli nie poświęcisz czasu, aby uczynić to częścią ich procesu twórczego. Wydaje mi się, że tego nie robisz.

Zależy od ogólnej kultury. Jeśli napięte terminy są sporadyczne, zaakceptuj, że będziesz musiał zrobić porządki później. Jeśli są one stałe, to strukturalnie budujesz dług techniczny i powinieneś podjąć problem zarządzania. Jeśli nie odniosą się do twoich obaw, lepiej zacznij szukać innej możliwości pracy, ponieważ kultura firmy najprawdopodobniej wkrótce spełni zasady darwinowskie.

Aby w przyszłości ograniczyć problem, opracuj wewnętrzny dokument dotyczący standardów i praktyk kodowania, którego muszą przestrzegać wszyscy pracownicy.

W przypadku bieżącej partii wyczyść kod zgodnie z dokumentem S&P podczas refaktoryzacji kodu, ale tylko podczas refaktoryzacji.

Jestem dość niedoświadczony w programowaniu. Jednak jako student często zobowiązuję się do wzajemnej oceny i partnerstwa przy projektach. Jeśli będzie wystarczająco dużo czasu, aby ukończyć projekt, posprzątam kod członka zespołu dla jasności i czytelności. Najczęściej trudno mi nawet przesiać pierwsze 100 wierszy. W takich przypadkach jestem więcej niż chętny, aby pomóc w nauczeniu innych programistów lepszych nawyków i kodowania. Jeśli po prostu nie ma wystarczającej ilości czasu, po prostu kopiuję / wklejam i pracuję nad swoimi projektami, aby rozwiązać problem ich słabych interfejsów. Później z pewnością udzielę wielu porad na temat techniki kodowania. Jeśli chodzi o recenzowanie, konstruktywna krytyka (bez względu na to, jak niepożądana) przynosi korzyści zarówno jemu, jak i mnie na dłuższą metę.

Ogólnie rzecz biorąc, jeśli masz czas do stracenia, naucz go, jak prowadzić swoją pracę, aby wszyscy byli pożyteczni. Poświęć chwilę i naucz ich, co dla ciebie zadziałało, a co nie. Jeśli nie masz czasu, wyczerpaj się na chwilę ich pracą i koniecznie wróć do nich, gdy będziesz miał okazję. Poinformuj ich, że istnieją lepsze sposoby robienia rzeczy, zwłaszcza jeśli będziesz z nimi współpracować w przyszłości.

Poprawa ogólnej jakości jest znacznie lepsza niż użycie jednej osoby jako „filtra” dla większej grupy. W tej notatce:

• Programowanie w parach działa jak udoskonalona wersja recenzji kodu dla zrozumienia, jak się rozwijać - to jak różnica między czytaniem a robieniem, mówieniem i pokazywaniem. Obserwowanie ewolucji kodu i szybkie omawianie zmian jest niezwykle pomocne w zrozumieniu nie tylko tego, jak, ale dlaczego refaktoryzacji i dobrego kodu. Z mojego doświadczenia wynika, że ​​jest to szybsze niż rozwijanie się w pojedynkę, ponieważ pomysły są nieustannie rzucane, co kończy się ogólnie wyższą jakością i lepszym zrozumieniem zarówno kodu, jak i sposobu myślenia drugiej osoby.
• Narzędzia do linowania mogą sprawdzić, czy przestrzegany jest styl kodowania. To uczy każdego, jak formatować kod, a błędy powinny szybko odpadać, gdy programiści zapamiętają standard.
  • Włącz tę część procesu kompilacji, aby upewnić się, że została naprawiona przed zatwierdzeniem.
  • Użyj szablonów językowych, aby zapewnić osobne sprawdzanie kodu CSS, HTML, JavaScript i kodu po stronie serwera.
• Narzędzia sprawdzania poprawności mogą sprawdzić, czy generowane dane wyjściowe są rozsądne. Powinny one również stanowić część procesu kompilacji.

Najlepszą praktyką byłoby posiadanie przewodnika po stylu kodowania i regularne przeglądy, abyś, gdy zbliża się termin, nie miał do czynienia z tym problemem.

Moim zaleceniem jest wykazanie się przywództwem i kierowanie regularnym przeglądem kodu. Zarządzanie nie jest wypychane z góry, aby zapewnić regularne przeglądy kodu, ale z mojego doświadczenia wynika, że ​​będą pod wrażeniem, gdy programista podejdzie do planowania i przeprowadzania regularnych przeglądów kodu.

Jest wiele korzyści dla twojego ludu, który:

• nauczyć się lepszego stylu
• postępuj zgodnie z lepszymi praktykami
• nauczyć się badać, co robią

I kilka korzyści dla siebie, będziesz:

• bardziej wydajny podczas debugowania w ostatniej chwili (co zawsze się zdarza)
• uznany zarówno jako ekspert, jak i lider zarówno przez zespół, jak i kierownictwo

Widzę przyczynę w odpowiedzi „nie naprawiaj tego, co działa” i „nie marnuj czasu na to, co nie jest ważne dla klienta”. Premierzy martwią się ryzykiem i jest w porządku.

Rozumiem również, że większość ludzi nie przyjmuje tego rodzaju poprawek dobrze. Też to rozumiem.

Powiedziałem to, uważam, że większość terminów jest sztuczna. Prawdziwe systemy żyją coraz dłużej niż terminy, a zły projekt, który dziś robisz, będzie cię zwalczał na zawsze. Ludzie biegną, aby dostarczyć coś w ciągu kilku miesięcy i spędzają lata po tym, podejmując błędne decyzje w kodzie uruchomionym podczas produkcji.

Dług technologiczny to słowo. Pewnego dnia wróci i ktoś za to zapłaci.

IMO, więc myślę, że masz rację, naprawiając zepsuty projekt, a bycie profesjonalistą (specjalnie dla juniorów) oznacza również, że musisz wiedzieć, jak krytykować i jak się z niego uczyć, nawet jeśli nie jest to grzeczne. W rzeczywistości większość życia i tak nie jest grzeczna.

Każda prosta odpowiedź będzie skrajna. Oczywiście są przypadki, w których termin jest tak napięty, że musisz użyć brzydkiego kodu, a są przypadki, w których kod jest tak brzydki, że warto go nie dotrzymać, aby go poprawić. Potrzebne są metody oceny, w którym się znajdujesz, i być może metody ustalania realistycznych terminów, które dają czas na napisanie lepszego kodu.

Nie zapisuj czyszczenia na później. O ile zwykle nie masz okresów, które nie mają nic do roboty oprócz refaktoryzacji, nie ma „późniejszego”, w którym uporządkowanie kodu będzie miało wyższy priorytet niż obecnie. Rutyna to „czerwony, zielony, refaktor”, a nie „czerwony, zielony, zrób coś zupełnie innego przez dwa tygodnie, refaktoryzator”. Realistycznie nie zmienisz kodu, dopóki następnym razem nie wrócisz do niego z jakiegoś innego powodu, i prawdopodobnie wtedy też będziesz w terminie. Twoje prawdziwe opcje to naprawić to teraz lub zostawić.

Oczywiście dobrze napisany kod jest lepszy niż źle napisany kod, zakładając, że planujesz go przeczytać ponownie. Jeśli nie planujesz go nigdy więcej czytać, nie sprzątaj go . Wyślij pierwszą rzecz, która przejdzie testy. Ale to dość rzadki scenariusz, dla większości programistów dzieje się to w przybliżeniu nigdy. Ignorując tę ​​sprawę, tylko Ty masz szczegóły swojej prawdziwej sprawy, aby ocenić, ile kosztuje naprawić, a ile kosztuje (w przypadku zwiększonej przyszłej konserwacji), aby go nie naprawić.

Są pewne rzeczy, które nie są trudniejsze do naprawienia w momencie, gdy kod wymaga konserwacji, niż do naprawy teraz. Naprawdę nie przynoszą one wiele korzyści teraz. Najbardziej oczywiste są trywialne do naprawienia (błędy białych znaków itp.), Więc trudno sobie wyobrazić, że masz czas, aby zadać to pytanie, ale go nie naprawić ;-) Dla tych, którzy nie są trywialni i są tego rodzaju, to OK , masz kod, który nie jest idealny, ale musisz być pragmatyczny. To działa, a ty dotrzymujesz terminu. Użyj tego.

Są pewne rzeczy, które są teraz znacznie łatwiejsze do naprawienia niż będą później, gdy (a) nie będą tak świeże w umysłach wszystkich; (b) napisano inne rzeczy, które na nich polegają lub imitują je. Są o wiele bardziej wartościowe do naprawienia, więc uszereguj je priorytetowo. Jeśli nie masz czasu na ich naprawę, musisz naciskać jak najdłużej na dłuższe terminy, ponieważ budujesz dług w bazie kodu, który prawdopodobnie będziesz musiał spłacić przy następnej wizycie kod.

Preferowaną metodą naprawy kodu jest proces przeglądu. Skomentuj problemy, które masz z tym związane, i odeślij je do juniora w celu zmiany . Możesz podać przykłady tego, co masz na myśli, i zostawić młodszego, aby znalazł wszystkie przypadki w kodzie, którego dotyczą, ale nie po prostu dokończ dla nich kodu. Jeśli to zrobisz, nie dajesz im możliwości poprawy.

Powinieneś napisać typowe problemy w przewodniku po stylu, który mówi „nie rób tego, rób to zamiast tego” i wyjaśniaj dlaczego. Ostatecznie dopuszcza się, aby „w celu uczynienia naszego kodu estetycznie spójnym”, ale jeśli nie jesteś przygotowany na spisanie reguł z pewnym uzasadnieniem, prawdopodobnie nie powinieneś ich egzekwować. Po prostu zostaw każdego programistę do wyboru.

Wreszcie, strzeż się tendencji do ulepszania rzeczy w nieskończoność. Zwroty maleją, a Ty musisz uczyć się przez doświadczenie, gdzie są nadal dobre. Jest absolutnie niezbędne, abyś sformułował realistyczne wyobrażenie o tym, co jest wystarczająco dobre, w przeciwnym razie nie możesz mieć negocjacji, w których upewnisz się, że twoje terminy dają ci czas na stworzenie „wystarczająco dobrego” kodu. Poświęć czas na rzeczy, które nie są wystarczająco dobre.

Jak wielu powiedziało wcześniej, cokolwiek rzucisz w powietrze, zawsze zejdzie na dół. Wierzę w silną jednolitość w bazie kodu. Oczywiście niektóre rzeczy naprawdę nie mają tak wielkiego znaczenia. Konwencje nazewnictwa zmiennych lokalnych na przykład w ramach procedury. Jednak w przypadku jakichkolwiek elementów strukturalnych należy go naprawić od razu, przed ostatecznym scaleniem z głównym pniem. Może być trochę tandetny, gdy spojrzysz na indywidualną procedurę lub klasę, ale jeśli wszyscy popełniają „nieco brzydki” kod, to naprawdę szybko staje się naprawdę brzydki jako całość.

Brzydki kod, który działa często działa dobrze 90% czasu, ale rozpada się na krawędziach. Upewnienie się, że tak nie jest, jest zwykle dość proste, przestrzegając tylko kilku prostych zasad. Po pierwsze, dla każdego programisty powinno być obowiązkowe zdefiniowanie i udokumentowanie dokładnych ograniczeń dla każdej procedury lub bloku funkcjonalnego, który tworzą.

Po drugie, dla każdej procedury powinien istnieć test na te ograniczenia. Powinien to być prosty test jednostkowy, który programista może (i musi) uruchomić lokalnie zgodnie ze swoją procedurą przed zatwierdzeniem. Oczywiście łatwiej jest to zarządzać za pomocą odpowiedniego pakietu testowego, ale nawet bez testu należy napisać i ewentualnie popełnić w częściowej klasie, którą można wykluczyć z kompilacji.

Po trzecie, zestaw standardowych środowisk programistycznych ze wstępnie skonfigurowanymi narzędziami jest nieoceniony. Serwer TS jest do tego doskonały. Każdy ma te same dokładne narzędzia (i wersje), te same konfiguracje i te same aktualizacje. Zainstaluj narzędzie do refaktoryzacji, takie jak CodeRush lub Resharper, wstępnie skonfigurowane do twoich standardów i poinstruuj programistów, że odrzucisz wszelkie zatwierdzenia, które nadal mają ostrzeżenia. Teraz możesz wykorzystać czas na sprawdzenie kodu swojego zespołu, aby ulepszyć zestaw reguł na podstawie ich opinii, a Twój zespół chętnie poprawi się bez konieczności ciągłego sprzątania. Programiście łatwiej jest również przyjąć krytykę kodu z odpowiednio skonfigurowanego narzędzia niż od kolegi lub szefa, gdzie standardy mogą wydawać się arbitralnie zdefiniowane lub źle zrozumiane. Jeśli IDE mówi ci, że twój kod jest tandetny, nikt się z tym nie pokłóci i zostanie to naprawione. Przekonasz się, że jakość kodu gwałtownie wzrośnie, a zespół jako całość poświęci DUŻO mniej czasu na refaktoryzację i czyszczenie po kilku tygodniach. Programiści przyzwyczają się również do zasad i przestaną pisać bzdury.

Wreszcie, prostym rozwiązaniem tutaj jest po prostu zachęcenie programistów do poprawy. Programiści są z definicji konkurencyjni. Każdy chce mieć najładniejszy lub najszybszy kod. Dobrym sposobem na zmotywowanie wszystkich, poprawę produktywności i wyeliminowanie niekompetentnych jest obliczenie tygodniowo ważonej tablicy wyników dla wszystkich, na przykład biorąc punkty za odrzucone zobowiązania i przekroczone terminy. Pokaż najwyższą literę N na cotygodniowym spotkaniu zespołu, a może nawet zapłać lunch temu, kto pierwszy w średnich miesięcznych.

Sugeruję użycie narzędzia do recenzji. Jeśli masz repozytorium oparte na Git, możesz użyć narzędzia do przeglądania Gerrit . Po kilku odrzuconych zatwierdzeniach zespół pozna standardy, których chcesz przestrzegać, a przyszłe zatwierdzenia nie będą wymagać od ciebie żadnej dodatkowej pracy.

Zobowiązania będą czekać na twoją akceptację. Jeśli zobaczysz jakieś wiersze, które powinny zostać przepisane, możesz pisać komentarze, a twoi koledzy z zespołu mogą samodzielnie naprawić kod na podstawie twoich wymagań. To naprawdę dobry sposób na poznanie standardów kodowania członków zespołu .