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

38

(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.)

Kot i mysz
źródło
1
Jeśli masz taką opcję, zajrzyj do produktów JetBrains (Re-Sharper dla C #, IntelliJ dla Java, a nawet niektórych „dynamicznych” języków), które mogą wprowadzać zmiany idiomatyczne w całym projekcie, przy niewielkim nakładzie czasu. (Można go również wykorzystać do interaktywnego uczenia młodszego, co jest idomatyczne. Ale upewnij się, że ty i oni zgadzacie się na te same ustawienia dla projektu. (I upewnijcie się, że robicie to wszystko w osobnym zatwierdzeniu, abyście nie pomieszali zmiany merytoryczne i kosmetyczne w tym samym zatwierdzeniu),
David Bullock,
2
Wdrożenie przewodnika po stylu / minimum? Mam na myśli, że nie będą pisać lepszego kodu, ale każdy jest w stanie postępować zgodnie z wytycznymi, które wymagają pisania prostych rzeczy w jeden konkretny sposób.
Peteris,
10
Widzę już, że masz problem z brakiem pracy zespołowej. Powinieneś kształcić i pielęgnować młodzież; nie tylko przepisuje swój kod i narzeka.
James
3
@Ramhound odkąd Turing opracował Maszynę Turinga. Ale wracając do rzeczy, jeśli jesteś seniorem, który powinien sprawić, by juniorzy cię wysłuchali. Naucz ich, jak postępować właściwie (lub w sposób przekonujący). Ale ważne jest, aby zapytać o opinię, a może mają jakieś pomysły, jak zrobić to lepiej. Również jeśli używasz surowego CSS do każdego nietrywialnego projektu, robisz to źle, postaraj się, aby Twój projekt przyjął LESS lub SASS.
Hoffmann

Odpowiedzi:

79

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!

Uri Agassi
źródło
W 100% się z tobą zgadzam, jednak zastanawiam się, jak to zastosować w obliczu napiętych terminów. Czy sugerujesz robienie recenzji kodu, nawet jeśli mogą one pochłonąć więcej naszego cennego ograniczonego czasu (zarówno w procesie recenzowania, jak i poprawek wprowadzonych po recenzji)?
Phil
3
Nie sądzę, że członek zespołu powinien zmienić pracę innego członka zespołu bez jego współpracy / zgody. Osoba, która napisała kod, powinna być za niego odpowiedzialna i chyba że kod zawiera błąd krytyczny, a oryginalny program piszący jest niedostępny, napięty harmonogram nie jest powodem do zmiany kodu innej osoby. Jeśli uważasz, że kod jest zbyt nieuporządkowany - przekaż go programistom i powiedz mu, aby wyczyścił go w następnej wersji.
Uri Agassi
23
@Phil Przy obliczaniu terminu należy wziąć pod uwagę czas na sesje przeglądu kodu. Nie jest to dodatkowy krok na szczycie procesu rozwoju - jest integralną częścią procesu rozwoju.
dj18
2
Ponadto szkolenie juniorów za pomocą przeglądu kodu może mieć teraz pewien czas (co, jak mówi dj18, powinno być uwzględnione w twoich terminach i szacunkach), ale zostanie spłacone w odpowiednim czasie wiele razy, ponieważ pozwala ci to zrobić bardziej oryginalne dzieło. Jeśli twoje terminy są tak napięte, że nigdy nie masz okazji tego zrobić, to pachnie raczej spiralą śmierci ...
Julia Hayward
2
@JustinPaulson nie zrozum mnie źle - fakt, że ktoś napisał jakiś kod, nie czyni tego kodu „jego”. Tydzień później jakiś inny członek zespołu dostanie zadanie, które wymagać będzie od niej modyfikacji tego kodu, a ona zdecydowanie powinna zmienić kod na swoje potrzeby. Nie widzę jednak przypadku użycia, w którym ktoś powinien „wyczyścić” czyjś kod w celu wyczyszczenia, zwłaszcza nie w ostatniej chwili w krótkim terminie.
Uri Agassi
29

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.

James Anderson
źródło
11
„jeśli jest to testowany kod, właśnie unieważniłeś cały wysiłek testowy i będziesz musiał powtórzyć testy”. Nie, nie unieważniono żadnego wysiłku testowego. Musisz tylko ponownie uruchomić testy, które i tak powinieneś zrobić dla każdego zatwierdzenia. Jeśli trwa to tak długo, że uważa się to za niemożliwe, testy są gówniane i powinny zostać naprawione.
l0b0
7
Warto zauważyć, że ciągłe pisanie niechlujnego kodu, aby „sprawić, by działało”, doprowadzi do powstania dużej kuli błota . W porządku, jeśli jest to wyjątek, a nie reguła. Jeśli stanie się to regułą, powinieneś porozmawiać z szefem, że terminy nie są jedyną rzeczą do rozważenia.
Neil
20
Problem polega na tym, że brzydki kod szybko przekształca się w uszkodzony kod.
Telastyn
1
@ramhound - jasne, ale OP (i prawie wszyscy inni) nie mówią o kodzie, który po prostu używa starych standardów - chodzi o niezręczny, niespójny, tandetny kod.
Telastyn
1
@JamesAnderson Jest to perspektywa niezwykle krótkowzroczna. Kod jest zapisywany raz, ale zachowuje się go przez cały okres użytkowania produktu. Większość kodowania to refaktoryzacja. Jak długo faktycznie zapisujesz kod na pustym ekranie, zanim go poprawisz i zobaczysz, czy działa zgodnie z oczekiwaniami? Dlatego dokonujesz refaktoryzacji, nawet w pierwszej godzinie po rozpoczęciu nowej klasy. Koszt refaktoryzacji brzydkiego kodu w kolejnych poprawkach i udoskonaleniach znacznie przewyższy koszt poświęcenia czasu na przegląd kodu i przesunięcie zespołu w stronę jednego, wyraźnego standardu.
Scott Shipp,
16
  • 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.

Obrabować
źródło
9

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!

Żeglarz naddunajski
źródło
Problem z „przypadkiem granicznym” polega na tym, że inne moduły mają tendencję do wyskakiwania, które korzystają z tego kodu. W związku z tym bardzo ryzykowna jest zmiana, ponieważ inne moduły mogą teraz polegać na „niepoprawnym / niepożądanym” zachowaniu. W rezultacie utknąłeś z kodem, który jest naprawdę trudny w utrzymaniu, co powoduje, że czujesz dreszcze za każdym razem, gdy go widzisz, i sprawia, że ​​chcesz iść gdzie indziej do pracy. Co najmniej zły kod musi zostać zablokowany przez kogoś, kto wie, co robi. W ten sposób można to naprawić w późniejszym czasie bez ponoszenia tak dużego ryzyka, jak po prostu pozostawienie go, dopóki ktoś nie zdoła go obejść.
Dunk
6

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.

kuszenie
źródło
4

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.

użytkownik1703394
źródło
3

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.

Casey
źródło
Pracowałem dla kilku dużych, bardzo zorientowanych na proces firm, które były gotowe wydać mnóstwo pieniędzy, aby zapewnić przestrzeganie standardów i praktyk kodowania. NIGDY NIE BYŁY, dopóki automatyczne narzędzia nie zaczęły ich egzekwować.
Dunk
@Dunk Czy wojsko USA liczy się jako „duże i zorientowane na proces”? Używają S & Ps przez cały czas: stroustrup.com/JSF-AV-rules.pdf
Casey
Z pewnością liczą się one jako złoty standard kodowania standardów i praktyk. Każda umowa tego wymaga. Jednak chociaż firmy starają się przestrzegać swoich standardów i praktyk, nie dzieje się to w sposób niezawodny i konsekwentny. Po prostu dzieje się zbyt wiele. Dlatego zautomatyzowane narzędzia są niezbędne, jeśli chcesz uwzględnić słowo „musisz” w swojej sugestii, tak jak to zrobiłeś. DOD uznał niemożność przestrzegania standardów metodami ręcznymi i dlatego kongres uchwalił ustawę w 2011 roku, która wymaga od kontrahentów obrony, aby zaczęli korzystać z automatycznych narzędzi do przeprowadzania tych kontroli.
Dunk
BTW, nie mówię, że nie ma potrzeby kodowania standardów i praktyk. Jest absolutnie taka potrzeba. Mam tylko spór w części „wszyscy pracownicy muszą podążać”, chyba że wspominasz także o egzekwowaniu tego za pomocą zautomatyzowanych narzędzi.
Dunk
@Dunk Zespół JSF-AV musiał to rozpoznać, dokument wyraźnie wspomina o użyciu zautomatyzowanych narzędzi jako sposobu egzekwowania S & Ps (w 2005 r.)
Casey
2

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.

Harrison McCullough
źródło
2

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.
l0b0
źródło
2

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
Aaron Hall
źródło
1
Problem z przewodnikami po stylu kodowania polega na tym, że mają tendencję do przekształcania się w książki. Większość ludzi chętnie uczy się i przestrzega dość skromnego zestawu zasad. Niestety, w pewnym momencie przewodniki te zawsze wykraczają poza możliwości uczenia się i zapamiętywania wszystkich zasad. Potrzebujesz narzędzia, które automatycznie sprawdzi styl, kropka. Przeglądy kodu nie powinny służyć do sprawdzania gramatyki, powinny służyć do wyszukiwania błędów i nieporozumień.
Dunk
Jako programista w Pythonie i lider przeglądu kodu wydrukowałem PEP 8 i przewodnik po stylu Python w Google co najmniej kilkanaście razy. Czegokolwiek programiści nie nauczą się od nich, znajdą się w tyle za tymi, którzy to robią. To powiedziawszy, zgadzam się, że sprawdzanie stylu jest również dobrą praktyką, jeśli możesz go wdrożyć.
Aaron Hall
Nie używam Pythona, więc nie znam dostępnych narzędzi, ale jeśli polegasz na recenzjach kodu w celu egzekwowania reguł stylu, tracisz setki (jeśli nie tysiące) godzin rocznie na coś, co można zrobić za Ciebie praktycznie bez kosztów czasu. Na pewno nie zdecydowałbym się na wdrożenie domowej wersji. Wydałbym pieniądze na zakup wersji komercyjnej, która będzie OSTROŻNIE lepsza niż cokolwiek, co można zbudować w domu z czasem. Nawet drogie narzędzia zwrócą się wielokrotnie.
Dunk
Python, jako że ma róg obfitości typu open source, ma wszystkie darmowe narzędzia (pylint, pep8, pyflakes), z których niektóre połączyliśmy i ulepszyliśmy, a ponieważ mamy tysiące programistów, naprawdę dobrze się skaluje.
Aaron Hall
1
: Miałem na myśli twój fragment „jeśli możesz go zaimplementować”. Jeśli możesz kupić moduł sprawdzania stylu, to jest to właściwy sposób. Jeśli Twój zespół może wdrożyć coś tak przydatnego w rozsądnym czasie, musi istnieć firma / oprogramowanie typu open source, które już to zrobiło. Tak więc kupowanie go byłoby znacznie bardziej opłacalne. Jestem pewien, że byłoby to lepsze i bardziej aktualne niż „nieprodukowana” domowa wersja. Jeśli masz tysiące programistów, bardzo nie doceniłem wielkości oszczędności, jakie zapewni automatyczne narzędzie do sprawdzania stylu / bezpieczeństwa.
Dunk
2

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.

Lew
źródło
0

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.

Steve Jessop
źródło
0

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.

Drunken Code Monkey
źródło
0

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 .

Kasper Ziemianek
źródło