Jak mogę ustawić refaktoryzację jako priorytet dla mojego zespołu?

57

Baza kodów, z którą codziennie pracuję, nie ma zautomatyzowanych testów, niespójnych nazw i mnóstwa komentarzy, takich jak „Dlaczego to jest tutaj?”, „Nie jestem pewien, czy jest to potrzebne” lub „Ta metoda nie jest odpowiednio nazwana”, a kod jest zaśmiecony „Listy zmian”, mimo że korzystamy z kontroli źródła. Wystarczy powiedzieć, że nasza baza kodów mogłaby użyć refaktoryzacji.

Zawsze mamy zadania naprawiania błędów lub dodawania nowych funkcji, więc nie trzeba poświęcać czasu na ulepszanie kodu, aby był on lepszy i bardziej modułowy, i nie wydaje się to mieć wysokiego priorytetu.

Jak mogę wykazać wartość refaktoryzacji, aby została dodana do naszych list zadań? Czy warto po prostu refaktoryzować, kiedy idę, prosząc o wybaczenie, a nie o pozwolenie?

Joseph Garland
źródło
Dokonaj
4
Nie traktuj refaktoryzacji jako osobnego zadania - nie jest.
Vetle
2
Listy zmian w kodzie powodują, że chcę płakać ... Przepraszam za twoją stratę.
Mark Canlas
@Mark Canlas Myślałem tak samo, dopóki nie napotkałem 20-letniej bazy kodu z dosłownie setkami zmian w kontroli źródła. Powodzenia w ustaleniu, dlaczego (a nawet jeśli) określony blok kodu został zmieniony przy użyciu tylko historii kontroli źródła
Michael J.
@Michael Co sprawiło, że tak trudno? Zasadniczo kilka operacji obwiniania / adnotacji powinno doprowadzić cię do odpowiedniego zatwierdzenia, bez względu na to, ile zmian zostało wprowadzonych. („Setki” zmian w ciągu 20 lat są małe, BTW.)
Marnen Laibow-Koser

Odpowiedzi:

51

„Lepiej prosić o wybaczenie niż pozwolenie” jest prawdą.

Po co się tym martwić? Po prostu refaktoryzuj najstraszniejsze części.

Wiesz już, jakie są najbardziej kosztowne błędy, prawda?

Jeśli tego nie zrobisz, krok 1 polega na pozytywnym i jednoznacznym zdefiniowaniu najbardziej kosztownego, złożonego, pozbawionego błędów i zainfekowanego błędami kodu problemu.

Zidentyfikuj liczbę zgłoszeń problemów, godziny debugowania i inne bardzo konkretne, bardzo wymierne koszty .

Następnie napraw coś na liście problemów związanych z wysokimi kosztami .

Kiedy musisz poprosić o wybaczenie, możesz wskazać na redukcję kosztów.


W przypadku braku świadomości refaktoryzacja wymaga testów jednostkowych w celu wykazania, że ​​zachowania przed i po są zgodne. Najlepiej byłoby, gdyby był to zautomatyzowany, zakodowany test, na przykład test jednostkowy.

Oznacza to wybranie jednej rzeczy. Napisz test jednostkowy. Napraw to jedno. Dokonałeś dwóch ulepszeń. (1) napisał test i (2) naprawił kod.

Powtarzać.

S.Lott
źródło
4
Jeśli to zrobisz, zdobądź dane, zanim zaczniesz, a następnie prosząc o wybaczenie, masz dowody potrzebne do utrzymania pracy.
mattnz
15
„Po co się tym martwić? Po prostu refaktoryzuj najstraszniejsze części.” To będzie bardzo niebezpieczna rada bez testów jednostkowych. W połączeniu z twoją inną radą, aby prosić o wybaczenie, a nie o pozwolenie, OP może prosić o wybaczenie na dużą skalę. Poczekaj, aż bilet zostanie otwarty z powodu niezamierzonej zmiany zachowania, którą można prześledzić do nieautoryzowanego refaktoryzacji. Istnieje spora szansa, że ​​winą za to będzie praktyka refaktoryzacji, a nie brak testów jednostkowych, a wtedy będzie to wieczny „dowód” w tym biurze, że „refaktoryzacja jest zła”.
PeterAllenWebb
2
Poza tym rzadko kiedy widziałem firmę, która korzystała z testów jednostkowych, więc jak możesz zacząć refaktoryzować w takiej sytuacji? Wydaje się to być samowystarczalną spiralą spadkową: nie można refaktoryzować, ponieważ nie ma testów, nie można pisać testów, ponieważ baza kodów jest zbyt duża i / lub nie ma czasu poza pisaniem nowych funkcji, aby wrócić i napisać testuje kod napisany od lat, więc nigdy nie można niczego refaktoryzować, więc kod po prostu wzdycha i gnije, aż się zawali.
Wayne Molina
8
W większości przypadków odpowiedź brzmi: „Zostaw i znajdź kompetentnych ludzi, którzy rozumieją, jak być prawdziwym profesjonalistą, a nie hack”. :)
Wayne Molina
4
W pewnym momencie okropny lub trudny w utrzymaniu kod sam jest błędem. Twórz elementy zaległości i nadaj im priorytet. Pracuję w zwinnym środowisku, w którym od czasu do czasu wykonujemy krótki sprint stabilizacyjny, gdy klient jest zbyt przewiewny, aby dać nam specyfikę lub trenuje. Nie przestajemy, ponieważ są niedostępne. A kiedy zaczyna się kolejny sprint, mieliśmy czas na zapoznanie się z wzajemnym udziałem i dokładniejsze oszacowanie naszych wysiłków. Musisz tylko gdzieś zacząć, nawet mały, i iść dalej. Nie pogarszaj tego, kontynuując styl, gdy jesteś przy nim.
Erik Noren,
32

Postępuj zgodnie z zasadą harcerza: opuść kemping (kod) trochę lepiej niż go znalazłeś. Nigdy nie słyszałem o tym, żeby ktoś pisał o drobnych poprawkach kodu „podczas gdy tam byli”.

Karl Bielefeldt
źródło
7
Silnie zależy od tego, jak blisko jesteś terminu. Zmiana biblioteki może unieważnić wszystkie poprzednie testy.
3
Dobra uwaga, @ Thorbjørn. Coś takiego prawdopodobnie nie sklasyfikowałbym jako „małej” poprawy, ponieważ ma duży zakres wpływu.
Karl Bielefeldt
jeśli zdarzy ci się przejść obok funkcji, którą można nieco poprawić. Po prostu nie wiesz, że jest on umieszczony we wspólnej bibliotece?
@ Thorbjørn Powiedziałbym, że powinieneś dobrze wiedzieć, gdzie ta funkcja jest używana. Jeśli dany plik źródłowy jest kompilowany dla czegoś wewnętrznego, tzn. Masz pełny dostęp do wszystkich jego wywołujących, nie widzę problemu z jego naprawieniem i aktualizacją miejsc, w których jest wywoływany w razie potrzeby. Jeśli plik źródłowy jest kompilowany jako część biblioteki, w której nie można zmienić interfejsu API, można przynajmniej naprawić szczegóły implementacji.
Maks.
Widziałem tego rodzaju komentarze „trzeba to zreformować” wkradające się do kodu, który jest ponownie używany w innych miejscach, ale gdzie nie jest jasne, które to są. Zazwyczaj programista nie chce poświęcać czasu na analizę wpływu i umieszcza komentarz, aby złagodzić swoją winę.
Joeri Sebrechts,
23

Przyjmę być może zbyt cyniczny punkt widzenia.

Refaktoryzacja jest tak trudną pigułką do przełknięcia. Otrzymujesz odpowiedzialność i winę, a owoce twojej pracy często trafiają do kogoś innego, kto opiera się na twoim czystym kodzie.

Powiedziałbym, że jeśli takie praktyki inżynierskie stały się kulturą w twojej firmie, być może będziesz musiał walczyć na wyższym poziomie. Tak naprawdę nie walczysz o refaktoryzację, walczysz o doskonałość inżynieryjną, a taka zmiana pojawia się dopiero w zarządzaniu, gdy uderza ją w twarz. W tym scenariuszu prawdopodobnie będą szukać na zewnątrz samochodu najlepszych praktyk, a wszystkie twoje wspaniałe pomysły i tak zostaną zebrane.

Rozważ dołączenie do innej firmy, w której poważnie podchodzą do praktyk inżynierskich.

Kevin Hsu
źródło
2
Z mojego doświadczenia wynika, że ​​doskonałość inżynierska rzadko płaci rachunki. Jest to działanie równoważące, w którym tylko kilku programistów jest dobrych. Pod warunkiem, że OP nie dąży do nadwyżki inżynierii, twoje komentarze są ważne.
mattnz
8
To prawie zawsze najlepsza rada IMO. Jeśli firma nie rozumie, dlaczego posiadanie wysokiej jakości kodu jest czymś, na co należy zachęcać i nie powinno być postrzegane jako strata czasu, jest to stracone przedsięwzięcie - nie są wystarczająco inteligentne, aby zrozumieć prawdziwe programowanie.
Wayne Molina
17

Zauważam, że wiele plakatów tutaj wydaje się być przekonanych, że problem w zarządzaniu - podczas gdy pytanie nie wspomina o tym.

Chciałbym pójść dalej: moim zdaniem kiepska baza kodu prawie nigdy nie jest bezpośrednią winą zarządzania. Kierownictwo nie napisało tego kodu, tak zrobili programiści (w mojej firmie są wyjątki, w których niektórzy z naszych obecnych kierowników napisali początkową bazę kodu). Dlatego problem kultury leży po stronie programistów - jeśli chcą, aby kultura się zmieniła, sami będą musieli się zmienić.

Staram się przekazać tę realizację i zmianę nastawienia także „moim” programistom. Ilekroć pytają mnie „kiedy będziemy mieli czas na refaktoryzację?”, Jestem zaskoczony i odpowiadam „powinieneś już cały czas refaktoryzować!”. Uważam, że jedynym sposobem na utrzymanie bazy kodu w dobrej kondycji jest trzykrotność:

  1. Zawsze dodawaj tylko zdrowy kod.
  2. Zawsze naprawiaj niezbyt zdrowy kod, gdy tylko go zobaczysz.
  3. Jeśli z powodów związanych z terminem nie możesz zrobić 1 lub 2, zawsze masz listę problemów „napraw natychmiast po terminie” i nie akceptuj żadnych usprawiedliwień, że nie przepracowałeś tej listy po terminie.


Niezmiennie następna uwaga od deweloperów brzmi „ale jak mamy na to czas - nie mamy teraz czasu?”. Jedyną poprawną odpowiedzią (ponownie IMHO) jest „nie masz czasu, aby tego NIE robić”. Jeśli nie utrzymasz bazy kodów w dobrej kondycji, zauważysz, że czas realizacji jest coraz dłuższy, harmonogramy stają się coraz bardziej nieprzewidywalne, błędy stają się bardziej nieprzyjemne, a wartość spada.

Największa zmiana nastawienia, którą musisz wprowadzić w zespole programistycznym, polega na tym, że „jakość” nie jest czymś, co robisz w określonym momencie („kiedy mamy czas na refaktoryzację”) - jest to coś, co musisz robić CAŁO.

Wreszcie historia ostrzeżenia. Jeśli zostanie naciśnięty, zaprzeczę, że to się kiedykolwiek wydarzyło. W firmie, w której pracowałem, istniała długoletnia aplikacja z dużą, starszą bazą kodów, która powstała ponad 10 lat temu. Wielu programistów, w tym ja, uważało, że ta starsza baza kodów była zła lub przynajmniej nieaktualna, a nie najnowocześniejsza. Lobbowaliśmy więc za dużym projektem refaktoryzacji i rozpoczęliśmy projekt przepisywania, po którym wierzyliśmy, że wszystko będzie lepiej.
Pracowaliśmy długo i ciężko, wdrażając prawie wszystko w nowy i nowoczesny sposób, wykorzystując nowe biblioteki, nowe funkcje językowe. Pod koniec dołożyliśmy ogromnych starań, aby zebrać wszystko w całość, aby umożliwić nową edycję długoletniej aplikacji z nową i ulepszoną bazą kodu.
Zgodnie z oczekiwaniami, nowe wydanie miało pewne problemy z ząbkami, z powodu nowych bibliotek, których jeszcze nie znaliśmy, oraz pewnych interakcji w naszym kodzie, których nie przewidzieliśmy. W końcu udało nam się jednak doprowadzić wersję do tego samego standardu, co nasze poprzednie wersje, i to na wyciągnięcie ręki. Odetchnęliśmy z ulgą po naszym „sukcesie”. Następnie podgrupa programistów wróciła do zarządzania, prosząc o nowy projekt refaktoryzacji, ponieważ nasz nowy kod nie był taką srebrną kulą, jakiej się spodziewali, i zobaczyli okazje do całkowitego przepisania niektórych rzeczy ...

Morał tej historii: często rzeczy nie są tak zepsute, jak się wydają, a „rozpoczęcie od nowa” zwykle oznacza, że ​​będziesz wymieniał znany zestaw problemów z co najmniej tak samo włochatym nieznanym zestawem problemów. Refaktoryzuj jedną część na raz!

Joris Timmermans
źródło
2
Myślę, że jest to przypadek modularyzacji, jak wspomniałem w mojej odpowiedzi, IMO może rozwiązać niektóre problemy, dzieląc rzeczy na mniejsze aplikacje, jeśli to możliwe, możesz przepisać jedną część co tydzień, jeśli chcesz, wychodząc same moduły stabilne
programmx10
Ten artykuł jest bardzo trafny: blog.objectmentor.com/articles/2009/01/09/…
Garrett Hall
Zobacz także rzeczy, których nigdy nie powinieneś robić od Joela Spolsky'ego.
Jan Hudec
Jestem za radą, że „nie masz czasu, aby NIE refaktoryzować”. Ale twierdzić, że jest to problem dewelopera? Czy ty żartujesz? Nie mogę powiedzieć, ile razy kierownictwo (nieprogramiści) dosłownie dzwoniło do mnie do biura, żeby przestać refaktoryzować, zostawić kod w najnowszej wersji i szybko zrobić coś innego. Mamy kilku programistów stale argumentujących, że powinniśmy dokonać refaktoryzacji, ale zarząd dosłownie tego nie docenia. Jest to powszechne, gdy menedżerowie są pracownikami technicznymi w niektórych domenach innych niż oprogramowanie.
ely
Z mojego doświadczenia wynika, że ​​zawsze jest to problem z zarządzaniem. Zarząd ma za zadanie zarządzać ludźmi, aby właściwie wykonywali swoje zadania. Jeśli programiści nie wykonują poprawnie swoich zadań (a nie pisanie kodu jakości dokładnie to oznacza), mamy poważny problem z zarządzaniem!
Kaiserludi
12

Ktoś mi kiedyś powiedział, że kiedy idę na rozmowę kwalifikacyjną, nie powinienem zapominać, że przeprowadzam również wywiad z firmą. Czy to miejsce, w którym chcę pracować? Czy robią recenzje kodu? Czy mają zautomatyzowane testy integracyjne? Testy jednostkowe? Co myślą o programowaniu w parach? Osobiście znajdę inną pracę i tym razem nie zapomnę też zadać pytań.

Kevin
źródło
Dobra rada, ale zadawanie pytań nie zawsze działa. Przeprowadziłem wywiad z niektórymi firmami, które kłamały na ten temat - np. Mówiąc, że używają kontroli wersji, ale w ogóle nie jest skonfigurowana poprawnie i nikt tak naprawdę nie wie, jak z niej korzystać, mówiąc, że przeprowadzają testy, ale nie ma testów jednostkowych, mówiąc, że korzystaj z najnowszej i najlepszej technologii, ale tak naprawdę nie korzystasz z żadnych funkcji w najnowszej wersji (ani żadnej wcześniejszej wersji).
Wayne Molina
5
@Wayne M: W takim przypadku zacznij od razu szukać nowej pracy. Jeśli okłamali cię w wywiadzie, jak zamierzają cię leczyć później?
David Thornley,
1
Zgoda, ale niestety często łatwiej powiedzieć niż zrobić.
Wayne Molina
@WayneM Dokładnie. Doświadczyłem tego samego. Zapytałem o kreatywne możliwości prowadzenia badań matematycznych w pracy, a firma w zasadzie skłamała, aby mnie zaakceptować, a następnie utknęła w projektach, o których pomyślałem, że zlikwidowałem, pytając podczas wywiadów. Rada „szukaj nowej pracy” jest dość płaska - oczywiście zrobię to, ale po prostu nie stanowi żadnego „rozwiązania” tego problemu.
ely
6

Znajdź szczerze inną firmę. Takie ulepszenia w procesie rozwoju wymagają ogromnych skoków kulturowych, że zajmie to dużo czasu, zanim wszyscy znajdą się na tej samej stronie, a do tego czasu nie będziesz się tak przejmować.

Jeśli czujesz, że wciąż masz w sobie walkę i jeszcze się nie poddałeś, to wykonaj ostateczny atak. Postaraj się uzyskać jak najwięcej wsparcia od podobnie myślących członków zespołu, ujawnij swoje wyczerpanie przełożonym, którzy dbają o twoje samopoczucie, całkowicie obejdź i zdystansuj każdego, kto mógłby się sprzeciwić twoim przekonaniom, i spróbuj wcisnąć kilka godzin obowiązkowej refaktoryzacji w planowanie nowego projekty / funkcje.

Jeśli jesteś pasjonatem tego, co robisz i dbasz o swoją firmę, byłby to godny pochwały wysiłek po twojej stronie. Jeśli nie jest to doceniane, uszanuj siebie i wyskocz przed nim, zanim zmienisz się w pustego programistę.

Filip Dupanović
źródło
5

Gdybym musiał wprowadzić jedną praktykę, aby poprawić sytuację w tego rodzaju kontekście, byłyby to recenzje kodu. Recenzje kodu są

  • ogólnie intuicyjnie akceptowane przez programistów jako czynnik zapewniający lepszy kod, mniej błędów itp.
  • współpracujący i demokratyczny
  • nie jest to zbyt czasochłonne, jeśli odpowiednio je odtwarzasz
  • dobre miejsce na refaktoryzację, jeśli nie masz na to czasu podczas „normalnego” rozwoju
  • całkiem skuteczny koń trojański, który stopniowo wprowadza wszelkiego rodzaju najlepsze praktyki w zakresie projektowania kodu, testowania jednostkowego ...

Nie musisz systematycznie przeglądać kodu, tylko na początku, gdy popełniasz duże / złożone części kodu.

Oczywiście, jeśli uważasz, że potrzebujesz oficjalnego poparcia przed wprowadzeniem recenzji kodu, być może będziesz musiał najpierw przekonać swojego szefa, że ​​baza kodu prawdopodobnie się zawali, jeśli rzeczy pozostaną takie, jakie są.

guillaume31
źródło
2
To zakłada, że ​​inni znają dobre praktyki rozwoju. Kiedyś miałem pracę, w której inni członkowie zespołu nawet nie wiedzieli, dlaczego moja droga była bardziej skuteczna; mój dobrze napisany kod, który był zgodny z SOLID i zastosowanymi wzorami projektowymi, został w rzeczywistości odrzucony podczas „przeglądu kodu”, ponieważ był inny, a starszy programista nie zrozumiał go w porównaniu z resztą stylu zespołu polegającego na stosowaniu zdarzeń związanych z kodem i kod_kodu / folder.
Wayne Molina
Często możesz rozwiązać takie trudności, prosząc ludzi, aby po prostu spróbowali i przekonali się, czy to działa. Jeśli odmówią tego lub nadal nie widzą korzyści, muszę przyznać, że prawdopodobnie czas odejść.
guillaume31
1
Kiedyś powiedziano mi, że moja droga jest „bardziej wyrafinowana”, ale musiałem złożyć skargę, że trudniej ją zrozumieć. Innym sposobem FWIW było skopiowanie pliku 300 linii, zmiana dwóch linii i zatwierdzenie. Uzasadnienie kopiowania / wklejania w tym przypadku (i zazwyczaj z mojego doświadczenia) brzmi: „w ten sposób wiesz, że niczego nie złamałeś”.
Kevin
4

Oto, co robię w takich sytuacjach (w ciągu 15 lat mojej kariery jako programisty prawie codziennie napotykałem taki kod)

  1. Dawaj dobry przykład - upewniam się, że ponownie uwzględniam kod, którego dotykam. Bezwzględnie usuwam stary skomentowany kod i duże akapity komentarzy.
  2. Proś o zmianę faktury za każdym razem, gdy poproszę o sprawdzenie zmiany kodu, bez której nie zatwierdzam recenzji kodu.
  3. Powoli ludzie widzą zmianę, gdy kod staje się bardziej uproszczony, bardziej czytelny, a przez to mniej błędny. To wymaga czasu, ale powoli cały zespół docenia i przyjmuje praktykę.

Kierownictwo nigdy nie przeznacza czasu na ponowny faktoring kodu (nigdy nie ma wystarczających zasobów!), Więc robienie tego powoli i systematycznie jest właściwym podejściem.

Ciekawy
źródło
Nie przeszkadza mi nawet, jeśli podczas re-faktoryzacji kodu wkradną się od jednego do dwóch błędów, takie defekty są wychwytywane i naprawiane znacznie szybciej i łatwiej w czystszym / szczuplejszym kodzie!
Ciekawy
3

Poproś kierownictwo o przeprowadzenie badań dotyczących „długu technicznego”. Odwołaj je również do „Teorii rozbicia okna”, oba te efekty mają bezpośredni wpływ na wydajność, jakość i morale.

„Czyste miejsce pracy to bezpieczne i produktywne miejsce pracy”, a każdy wkład w bałagan potęguje bałagan w sposób wykładniczy, a nie liniowy.

Jeśli sytuacja nie zostanie rozwiązana, w końcu przekroczysz punkt bez powrotu, w którym stanie się to ekonomicznie niewykonalne, postępując z nią stopniowo, zanim to nastąpi, korzyści odbędą się, dając ci więcej paliwa, aby poradzić sobie z problemem w trakcie podróży.

znak
źródło
3

Wygląda na to, że twoje problemy są bardziej ogólne.
Problem refaktoryzacji jest zarówno objawem, jak i potencjalną ulgą od części problemu.

Kierownik ds. Oprogramowania i zespół przydzielają czas zespołowi

Z mojego doświadczenia wynika, że ​​możesz napotykać problem, który nazywam „każdy jest menedżerem oprogramowania”. Menedżerowie produktu, kierownicy projektów, a czasem inżynierowie i testerzy systemów mogą być znani z próby zarządzania mikro programistami, którzy prawdopodobnie mają już doświadczonego menedżera oprogramowania. Możesz nawet mieć kilku członków swojego zespołu, którzy uważają, że ich rolą jest zarządzanie.

Jeśli jesteś menedżerem oprogramowania, dokonaj zleceń refaktoryzacji, które chcesz, lub jeszcze lepiej, poproś zespół o zaproponowanie refaktoryzacji do zatwierdzenia. Aby nie zarządzać mikromaningiem, możesz mieć wytyczne dotyczące wieku / autora / rozmiaru / kontekstu kodu, który ma być refaktoryzowany, który można dowolnie refaktoryzować vs. wymagać zgody. Jeśli członek twojego zespołu chce masowo zreformować cztery duże klasy skomplikowanego starego kodu, którego nie napisał, a które nie są częścią jego funkcji, jego dwutygodniowe przekierowanie jest twoim problemem, więc potrzebujesz szansy, aby powiedzieć „nie”.

Możesz się przekraść, ale myślę, że lepiej jest po prostu ostrożnie budować swoje szacunki z czasem na analizę, projektowanie, kodowanie, wiele form testowania (przynajmniej jednostki i integracji), refaktoryzację i ryzyko, jak sądzono historycznie i przez brak doświadczenie lub przejrzystość związane z zadaniem. Jeśli byłeś zbyt otwarty na temat pracy swojego zespołu (lub masz członków w swoim zespole, którzy są), rozsądne może być wąskie kanały komunikacji, aby przechodzili przez ciebie i omawiali zasoby i wyniki, a nie metody.

Wczesne wybory projektu Utwórz błędne koło do refaktoryzacji

Konserwacja oprogramowania jest trudna. Podwójnie trudno jest, jeśli inni w organizacji dokonują wyborów na własny koszt. To źle, ale nie jest nowe. Zajmuje się tym Barry Boehm, jeden z naszych wielkich twórców oprogramowania, który przedstawia model zarządzania, który określa jako Teoria W.

http://csse.usc.edu/csse/TECHRPTS/1989/usccse89-500/usccse89-500.pdf

Często programiści są wkurzeni, aby produkować zgodnie z podejściem do zarządzania Theory-X, które mówi, że pracownicy są w zasadzie leniwi i nie będą działać, chyba że zostaną zmuszeni do poddania się. Boehm podsumowuje i kontrastuje swój proponowany model w następujący sposób:

„Zamiast charakteryzować menedżera jako autokratę (Teoria X), trenera (Teoria Y) lub facylitatora (Teoria Z), Teoria W charakteryzuje podstawową rolę menedżera jako negocjatora między jego różnymi okręgami wyborczymi i pakietem rozwiązań projektowych z warunkami wygranej dla wszystkich stron. Poza tym menedżer jest także wyznacznikiem celów, monitorem postępów w osiąganiu celów i aktywistą w poszukiwaniu codziennych konfliktów między projektami typu wygrana-przegrana lub przegrana-przegrana, konfrontując je, i zmieniając je w sytuacje korzystne dla obu stron ”.

Szybka i brudna często jest po prostu brudna

Boehm wskazuje dalej, dlaczego programiści z zespołu konserwacyjnego są tak nieszczęśliwi.

„Zbudowanie szybkiego i niechlujnego produktu może być tanią, krótkoterminową„ wygraną ”dla twórcy oprogramowania i klienta, ale będzie to„ strata ”dla użytkownika i opiekuna”. Należy pamiętać, że w modelu Boehm klient jest raczej administratorem umowy niż użytkownikiem końcowym. W większości firm myśl o menedżerze produktu jako o surogacie klienta, a może o osobie, która kupuje produkt na liście funkcji.

Moim rozwiązaniem byłoby, aby nie wypuszczać pierwotnego zespołu programistów (lub przynajmniej oryginalnego leadu), dopóki kod nie zostanie zrefaktoryzowany, aby przynajmniej spełniał standardy kodowania.

Uważam, że dla klienta rozsądne jest uznanie menedżera produktu za surogat klienta, a grupę osób nagradzanych za dostarczenie czegoś szybkiego i brudnego można z pewnością poszerzyć, więc istnieje duży wybór, aby robić rzeczy w niewłaściwy sposób.

Refaktoryzacja nie podlega negocjacji

Nie wycofuj się z roli menedżera oprogramowania. Powinieneś mieć uprawnienia i dyskrecję, aby wykorzystać czas swojego zespołu na doskonalenie procesów i produktów. W tej roli może być konieczne negocjowanie wyborów, aby Twój zespół był bardziej profesjonalny. Jednak jeśli chodzi o proces, nie negocjuj z marketingiem, ponieważ z mojego doświadczenia jest to przegrana gra. Negocjuj z kierownictwem inżynieryjnym. To pokazuje, że masz wizję. Budowanie profesjonalnego zespołu oprogramowania jest przedłużeniem ich roli i jest o wiele bardziej prawdopodobne, że będzie postrzegane jako korzystne dla wszystkich.

DeveloperDon
źródło
2

Zawsze możesz po prostu poczekać. W końcu zespół spóźni się z wystarczającymi terminami i wyprodukuje wystarczająco dużo błędów, aby zarząd podniósł ręce i powiedział, że na Boga coś lepiej się zmieniło!

Dobra, to ryzykowna propozycja. Ale tak naprawdę wydarzyło się w naszym sklepie kilka lat temu (część trudności polegała na komunikowaniu się z zarządem na temat terminów, ale to inna historia) i jest to główny powód, dla którego mamy teraz dziesiątki tysięcy automatycznych testów, współdzielenie kodu, wolność refaktoryzacji, gotowość do usuwania martwego kodu i wydania najwyższej jakości, jakie kiedykolwiek mieliśmy.

Być może najbardziej zaskakujące jest to, że nikt nie stracił pracy w tym procesie - coś, co zawdzięczam naszemu szefowi, który przyszedł do nas, i konsultantowi, który argumentował za refaktoryzacją i ciągłą integracją w naszym imieniu. Zawsze brzmi to bardziej przekonująco, gdy mówi to ktoś z zewnątrz.

Joe White
źródło
Zgadzam się, ale w przypadku OP naprawdę wygląda na to, że pracuje z grupą niekompetentnych hacków, więc kiedy wszystko się wokół nich rozbije, to nigdy nie zatoną w tym, ponieważ nie zmienili tego gównianego kodu, ponieważ gdyby mogli to zrozumieć kod nie byłby tak zły, jak się wydaje. Prawdziwi programiści znają zalety refaktoryzacji od samego początku i podejmują kroki, aby to zrobić od samego początku.
Wayne Molina
1

Myślę, że odpowiedź na pytanie, jak znaleźć czas, zależy od tego, dlaczego chcesz zmienić kod.

Jeśli to działa, nie ma potrzeby specjalnego refaktoryzacji i możesz to zrobić po dotknięciu tej części kodu. Dlatego nie potrzebujesz na to specjalnego czasu.

Jeśli to spowolni rozwój twojego zespołu, musisz porozmawiać o tym z liderem zespołu i stworzyć specjalne zadanie do refaktoryzacji i że będziesz miał czas.

To samo dotyczy szybkości działania i innych przypadków, jeśli refaktor może coś ulepszyć, a nie tylko „dobrze wygląda kod” lub twoją opinię o tym, jak powinien wyglądać kod i zapewnić rzeczywistą korzyść, stworzyć zadanie lub porozmawiać z osobą odpowiedzialną za to.

Dainius
źródło
1

Śmiałem się trochę ze sposobu, w jaki opisałeś rzeczy, ponieważ to brzmi dość podobnie do bazy kodu, nad którą pracuję, więc myślę, że nasze sytuacje są bardzo podobne. Na szczęście w mojej sytuacji mam wybiegającego w przyszłość menedżera, który zdecydował, że najlepszym sposobem na ulepszenie bazy kodu jest modularyzacja przy użyciu nowoczesnych ram programistycznych, a nie tylko refaktoryzacja całej bazy kodu. W ten sposób kłopotliwe miejsca głównej aplikacji można przepisać jako osobne moduły, a następnie zintegrować z główną aplikacją (ale nadal być zasadniczo niezależnym). Może to być podejście, które chcesz wprowadzić, ponieważ nie wymagałoby to refaktoryzacji całej (prawdopodobnie dużej?) Bazy kodu, z którą pracujesz.

Oczywiście, mogę trochę odejść od tego, co mówisz, ponieważ być może twoja baza kodu nie jest tak zła, jak ta, z którą pracuję, w takim przypadku powiedziałbym, dlaczego nie robić małych optymalizacji podczas pracy? Twórcy w moim zespole nie mają problemu z usuwaniem głupich lub nieaktualnych komentarzy i rzeczy tego rodzaju i nie sądzę, że powinno to wymagać wkładu ze strony kierownictwa, ponieważ zwykle programiści mają pewne uprawnienia do optymalizacji rzeczy w razie potrzeby.

Jeśli podstawa kodu jest naprawdę delikatna, musisz być ostrożny i może to być powodem, dla którego mogą nie chcieć przeprowadzać poważnego refaktoryzacji, ponieważ może to skończyć się projektem trwającym miesiąc i prawdopodobnie wymagałoby rozgałęzienia projektu i umieszczenia na nim deweloperów projekt i odejmowanie od innych zadań programistycznych, takich jak natychmiastowe poprawki błędów, które mogą powodować utratę klientów itp

Biorąc wszystko pod uwagę, o ile inni mówią, że należy rzucić palenie itp., Myślę, że to zależy od tego, jak kierownictwo postrzega rzeczy, jeśli rozumieją sytuację i zdają sobie sprawę, dlaczego niektóre rzeczy mogą trwać dłużej niż powinny, to może być dobrze, ponieważ jeśli chodzi o środowisko pracy, ale jeśli ciągle docierają do ciebie z powodu zaległości w pracy, może to z czasem stać się szkodliwe. Mam szczęście, że mam zarząd, który w zasadzie zdaje sobie sprawę, że aplikacja to bzdura, ale ma wielu klientów i przynosi pieniądze, więc nadal jest cenna i warta naprawiania błędów, nawet jeśli tylko na krótko .

programmx10
źródło
1

Twoim głównym problemem jest to, że kody nie są wystarczająco widoczne.

Suggets używam narzędzia do ciągłej integracji, takiego jak Jenkins , oraz zintegrowanego z nim narzędzia do analizy kodu statycznego, które mierzy złożoność cykliczną, standardy nazewnictwa, długość kodu itp.

Gdy programista dokonuje zmiany, Jenkins przeprowadza testy jednostek, uruchamia na nim narzędzie do analizy kodu statycznego i generuje raport internetowy, który każdy może zobaczyć, ze statusem koloru przypominającym sygnalizację świetlną.

Gdy jakość kodu jest widoczna dla wszystkich (zwłaszcza lidera zespołu i szefa), a kontrola wersji i testy jednostkowe są dostępne, aby mieć twoje plecy ... ludzie zachęcani są do refaktoryzacji.

Tulains Córdova
źródło
1

Kod przechodził powoli przez wiele małych zmian. Trzeba będzie również to naprawić.

Możesz to zrobić na bieżąco - przede wszystkim - zwiększyć wszystkie szacunki o 10%, aby umożliwić ulepszenie kodu i długoterminową konserwację. Jeśli ktoś narzeka, zapytaj go, czy lepiej sprawdzać olej w silniku samochodowym co tydzień, czy też czekać, aż silnik całkowicie się zablokuje.

Spotkaj się i ustal spójne standardy kodowania.

Przedstaw podstawowe zasady, z których będziesz korzystać podczas pracy:

Ilekroć nowy kod jest wprowadzany do klasy, należy napisać automatyczne testy, aby udowodnić, że klasa działa (nie tylko nowy kod).

Ilekroć błąd zostanie naprawiony, należy napisać automatyczne testy, aby udowodnić, że klasa działa (nie tylko poprawiony kod).

Za każdym razem, gdy programista modyfikuje plik, musi naprawić wszystkie ostrzeżenia kompilatora w tym pliku i zaktualizować kod, aby spełniał nowe standardy kodowania.

Po pewnym czasie najczęściej używany kod będzie aktualny i objęty automatycznymi testami. Starszy kod zostanie zaktualizowany po zmianie, jeśli nigdy nie zostanie zmieniony, nie musisz się o to martwić.

Ważną rzeczą jest wbudowanie tych nawyków w standardowe zadania kodowania, aby żadne z nich nie poświęcało zbyt wiele czasu na „prawdziwą” pracę, ale wszystkie zapewniają rzeczywiste korzyści. Nie próbuj tworzyć projektu z refaktoryzacji starego kodu, jest to przerażający, nudny, skrzywdzony ból, który będzie wyglądał jak marnowanie czasu na non-technies!

Stefan
źródło
0

Sposobem na zdobycie potrzebnych zasobów (czasu) jest skupienie się na dostosowaniu zdolności i pożądania. Twój szef kieruje się celami (zazwyczaj zyski lub czasy dostawy nowych funkcji) i widzi refaktoryzację jako inżynierów marnujących czas i pochłaniających te cele. Musisz znaleźć sposób, aby przekonać go, że cele zostaną osiągnięte i przekroczone, jeśli spędzisz czas na refaktoryzacji.

Pierwszym krokiem jest więc sprawdzenie, jaki ból odczuwa Twój szef. Zidentyfikuj jego największe problemy. Następnie dowiedz się, jak to zrobić, i jak rozwiązać jego problemy, i przedstaw solidne uzasadnienie biznesowe. Skorzystaj z systemów śledzenia defektów i planowania projektu (przekroczenia czasu), aby dostarczyć dowodów na to, gdzie leżą problemy. Potrzebujesz faktów, a nie uczuć. Bez metryk (liczba błędów / moduł, koszt ich naprawy) refaktoryzacja jest po prostu programistą, który gra na czyimś kosztem. Twój szef da ci potrzebne zasoby tylko wtedy, gdy będziesz w stanie udowodnić, że jest to uzasadnione.

Kod bzdury jest często zbyt drogi do naprawienia. Bez zautomatyzowanych testów regresji koszt testowania zrestrukturyzowanego kodu jest niezwykle wysoki.

Przez większość czasu widziałem zły kod, który naprawdę wymagałby refaktoryzacji, było wiele nieudokumentowanych funkcji i złożoności wymagań, których nie można zrozumieć od samego początku. Nie jest to niewielkie przedsięwzięcie, a moje doświadczenie jest o rząd wielkości trudniejsze do oszacowania kosztu pracy refaktoryzacyjnej niż dodanie nowej funkcji.

Powstrzymałbym się przed zrobieniem tego za plecami bossów (jeśli nie został złamany, a ty go złamałeś, jak to wygląda) - napraw kod, który i tak wymaga zmiany, ale jeśli nie jest zepsuty, nie rób tego napraw to.

mattnz
źródło
2
Jeśli chodzi o zachowanie rozsądku - musisz zrozumieć, co motywuje ludzi w organizacji. Kiedy zrozumiesz małe rzeczy, takie jak szef nie dba o to, jak wygląda kod, staje się łatwiejsze. Jeśli to nie zadziała, zmień zadania lub zaangażuj się w projekt open source i refaktoryzuj wszystko, co chcesz.
mattnz
3
„Jeśli się nie zepsuło, nie naprawiaj” to najgorsze powiedzenie w całej naszej dziedzinie i należy je całkowicie usunąć z języka. Sprzyja leniwym zachowaniom i zachęca do kultury wspólnego hakowania, a nie robienia tego we właściwy sposób, a przez skojarzenie uniemożliwia to, by kiedykolwiek zrobiono to dobrze w przyszłości. To podejście jest rakiem.
Wayne Molina
1
Zobacz mój powyższy komentarz, dlatego.
Wayne Molina
2
@Wayne M: Nie sądzę, że Mattnz mówi „nie naprawiaj nigdy”, myślę, że mówi „nie naprawiaj tego, chyba że jest to dobre dla organizacji i możesz zbudować wsparcie”, co jest bardzo ważne inny i całkiem rozsądny, IMO.
PeterAllenWebb
3
@Wayne M: dobrze powiedziane! Powiedzenie „jeśli się nie zepsuło, nie naprawiaj”, a słowo „refaktoryzacja” po prostu nie pasują do siebie. Istotą refaktoryzacji jest to, że tworzenie oprogramowania nie jest po prostu czarno-białym światem, w którym „zepsute” i „naprawione” są absolutne.
Carson63000,
0

O dziwo nikt nie wspomina o tym:

Aby wszystko stało się priorytetem, ułatw je: Uzyskaj dobre narzędzie do refaktoryzacji.

Istnieją doskonałe narzędzia do refaktoryzacji (przynajmniej dla .NET afaik). Aha, i nie zapomnij wcześniej napisać testów jednostkowych (jak już zauważyli inni).

Powodzenia!

Marcel
źródło