Jak zrównoważyć jakość kodu z silnymi osobowościami programistów

Podczas przeglądów kodu w pracy widziałem kod i wzorce, które uważam za „sprytne”, choć niekoniecznie zwiększające ogólną jakość lub łatwość konserwacji bazy kodu. Wskazuję to na moją opinię i kontrargumenty mnie nie przekonują. Jestem trochę zaniepokojony, gdy ten kod przekształca się w repozytorium, a później w produkcję.

Chcę utrzymać spójny zespół, więc nie chcę tworzyć napięcia, mówiąc zbyt głośno o moich zastrzeżeniach. Chcę również stworzyć świetny produkt dla naszych klientów, nie będąc zbyt wybitnym.

Kto tradycyjnie ma władzę weta wobec tego, co jest rejestrowane i jak?

Jak działa kod, który jest zbyt zaangażowany / sprytny, aby można go było usunąć bez stawiania czoła?

Uwielbiam ten cytat:

„Debugowanie jest dwa razy trudniejsze niż pisanie kodu. Dlatego jeśli piszesz kod tak sprytnie, jak to możliwe, z definicji nie jesteś wystarczająco inteligentny, aby go debugować”. - Brian W. Kernighan

Z jednej strony powoduje to zmęczenie zbyt sprytnym kodem, ponieważ trudno będzie go później debugować i rozszerzyć.

Z drugiej strony sprytny kod, który działa, to świetny sposób na naukę. Prawdopodobnie dla całego zespołu. Co powiesz na zachęcenie autora do wygłoszenia krótkiej nieformalnej rozmowy na temat kodu swoim kolegom? Tylko upewnij się, że naprawdę działa zgodnie z przeznaczeniem i że ma sens w całym projekcie. Nie chcesz zamienić go w bezsensowną konkurencję!

Jeśli nie uważasz, że to wnosi wartość dodaną, zadaj pytanie kontrolne, pytając: „W jaki sposób możesz przefakturować tę część (masz testy, prawda?), Aby była bardziej czytelna?” Pamiętaj, aby wskazać, że trudniej jest stworzyć sprytny, czytelny kod, aby stworzyć nieprzeniknione samorodki.

Radzę zagrać w idiotę, kiedy nadejdzie czas na recenzje kodu, możesz śmiało powiedzieć, że nie masz pojęcia, jak to działa (jeśli twoje ego potrzebuje masażu, możesz powiedzieć, że nie miałeś czasu go rozgryźć ) i poproś programistę o wyjaśnienie. Kiedy skończy, możesz zasugerować, że zapisuje to wszystko jako komentarz do przyszłej konserwacji, z dorozumianą wskazówką, że jest zbyt skomplikowany, by uznać go za „dobry” kod.

Jeśli dobry kod jest nieco zbyt skomplikowany, większość ludzi dostanie podpowiedź, nie mówiąc nic o jakości kodu ani wiedzy programisty.

PS. Oczywiście większość tego kodu i tak będzie subiektywna, więc niemożliwie sprytny kod jednej osoby może być rozsądnym, a może nawet standardowym w branży algorytmem dla innego programisty, więc nie można oskarżać nikogo bezpośrednio o pisanie złego kodu (z wyjątkiem przypadków, gdy jest to oczywiste cholerstwo jak kontrahent, który skopiował tablicę bajtów na listę STL, przekazał ją do procedury szyfrowania, a następnie przekonwertował z powrotem na tablicę bajtów!)

Moją ogólną zasadą jest naginanie wytycznych dotyczących jakości kodu na rzecz silnych osobowości programistów. Używam go zawsze, gdy nie mam czasu na wystarczająco głębokie kopanie - przy okazji takie kopanie jest zwykle dość pracochłonne (więcej na ten temat poniżej).

Zasada ta oparta jest na osobistym doświadczeniu. Zacząłem (prawdopodobnie jak każdy neofita) od fanatycznego przestrzegania wytycznych i dogłębnej walki z każdym odchyleniem. Z czasem zdobyłem wystarczające umiejętności i nauczyłem się wystarczających sztuczek, aby wygrywać takie walki ze względną łatwością - co z kolei pozwoliło skupić się bardziej na poznaniu ogólnego wpływu moich „zwycięstw”. I o ile wiem, wpływ był raczej negatywny - ludzie, którzy „przegrali walkę” cierpieli i stali się mniej wydajni - i wiesz, fakt, że ich kod był w 200% zgodny z wytycznymi dotyczącymi jakości, nie zrekompensował tego.

To odkrycie spowodowało, że porzuciłem większość walk, co z kolei doprowadziło do większej ilości czasu na analizę problematycznych przypadków. I odkryłem, że kiedy kopię wystarczająco głęboko, zwykle gdzieś za mną jest interesujący problem projektowy, subtelny (lub niezbyt subtelny) problem, który ukrywał się za walczącymi osobowościami.

• To tak, jakby powiedzieć, że znajduję plik źródłowy o wielkości 31 KB przekraczający zalecany limit rozmiaru, czyli 30 KB. Moje opcje to albo spędzić kilka minut / godzin na walce, aby zmusić właściciela pliku do wyciśnięcia tego dodatkowego kilobajta, albo spędzić dzień lub dwa na zastanawianiu się i odkryciu, że, powiedzmy, istnieje biblioteka API, której można użyć zamiast wszystkich kod w tym pliku (aby można go było po prostu usunąć).

Takie odkrycie może czasami nie być zbyt przydatne z punktu widzenia użytkownika końcowego (choć czasem może mieć naprawdę głęboki wpływ), ale musi przyznać, że czerpię radość z tego, że pękanie takiej nakrętki sprawia, że ​​i tak jest to warte wysiłku ... i jako lukier na odchyleniu wytycznych ciasta również odchodzi bez walki. :)

Twoja organizacja powinna mieć dokument dotyczący wytycznych / standardów kodowania, który jest okresowo aktualizowany przy pomocy wkładu zespołu programistów. Dokument ten może określać szczegóły, takie jak: jak nazwać zmienne, jak sformatować kod i tak dalej. Dokument powinien również wyjaśniać wartości, których organizacja oczekuje od programistów na piśmie, w tym względne znaczenie takich rzeczy, jak czytelność, łatwość konserwacji, poprawność, wydajność i przestrzeganie standardów.

Przeglądy kodu należy przeprowadzać przy użyciu tego dokumentu standardów kodowania. Jeśli standardy kodowania mówią, że programiści wolą czytelność od zwięzłości, gdy oba są w konflikcie, to masz jakieś wsparcie w argumentowaniu przeciwko „sprytnemu” kodowi. Jeśli standardy tego nie mówią i uważasz, że powinny, to możesz spierać się o to w sposób abstrakcyjny na spotkaniu standardów kodowania, zamiast próbować rozgryźć, kiedy czyjeś ego jest na linii.

Ostatecznie czasami sprowadza się to do wezwania do osądu, a w takich przypadkach ostatnie słowo powinno należeć do osoby, która ostatecznie jest odpowiedzialna za kod i / lub produkt. Zazwyczaj jest to ktoś taki jak starszy programista, kierownik techniczny, kierownik projektu lub dyrektor inżynierii. Jeśli jesteś szefem i uważasz, że określony kod nie jest wystarczająco łatwy do utrzymania, nie powinieneś bać się tego powiedzieć. Możesz być dyplomatyczny w tej sprawie:

Sam, jestem pod wrażeniem twojej pomysłowości tutaj, ale martwię się, że może to być trochę zbyt sprytne. Będę potrzebował, abyś pracował nad nowym rozwojem za rok, zamiast go utrzymywać, i martwię się, że ktokolwiek musi go utrzymywać, może nie w pełni zrozumieć jego niesamowitość. Wiem, że nie lubisz tego robić, ale byłbym wdzięczny, gdybyś wrócił do prostej implementacji, o której rozmawialiśmy.

Z drugiej strony, jeśli nie jesteś facetem odpowiedzialnym, najlepiej wyjaśnij swoją pozycję i spróbuj przekonać resztę zespołu. Jeśli nie otrzymujesz wsparcia od menedżera, zaakceptuj, że to nie twoje połączenie, i przejdź dalej.

Na twoim miejscu (a ja czasami jestem jednym z tych inteligentnych) nie usunęłbym go, ale poprosiłem osobiście dowcipnego / sprytnego autora, aby bardzo dobrze udokumentował to w komentarzach i, jeśli to możliwe, aby zamieścił trochę dyskusji na temat alternatyw i prostsze pisma, których mógł użyć, wraz z przykładami.

Podkreślę, że tak jest najlepiej, ponieważ nawet on prawdopodobnie nie pamięta wszystkich kawałków, które tam są, w tych wierszach, za dwa miesiące.

Prawdopodobnie upuści inteligentny kod na rzecz najprostszego, gdy tylko będzie musiał go napisać, jako przykład.

Dlaczego miałoby to działać.

• Przyznałeś, że zależy ci na tym, co pisze ,
• okazałeś mu szacunek , pytając :
• powołując się na problemy z pamięcią / koncentracją, wymyślasz i rozkładasz mu scenariusz, w którym ten kod musi zostać zmieniony i nie może być, dopóki on wciąż pracuje dla firmy lub zespołu

(bez tej ostatniej aluzji, tego rodzaju prośba może zostać odebrana jako próba utowarowienia programisty , dzięki czemu można go zamieniać z dowolną inną małpą kodową w dowolnym momencie)

Z mojego doświadczenia wynika, że ​​zazwyczaj bardzo trudno jest uzyskać kod, który spełnia wszystkie wymagania poza bazą kodu.

Jednak następnym razem, gdy kod zostanie utrzymany, możesz łatwo argumentować, że zastąpiono go jako przyszły środek oszczędnościowy, ponieważ stary kod był trudniejszy w utrzymaniu.

Jeśli chodzi o władzę weta, zarząd ma to oczywiście.
Czasami są to zespoły lub komitety odpowiedzialne za jakość kodu, w którym to przypadku miałyby również taką moc.

Przydałby się również przykład „sprytnego” wzoru. Może po prostu przesadzasz ...

„sprytne” prawie nigdy nie jest złą rzeczą w mojej książce, ale mogę się zgodzić, że może istnieć śliski spadek między sprytnym a zawiłym.

Myślę, że podobnie jak wiele innych praktyk, odpowiedź zależy .

• Jeśli jest to wada, zdecydowanie należy ją naprawić.
• Jeśli kod działa, musisz zrównoważyć wartość nalegania na zmianę kodu w stosunku do przyszłych kosztów sprytnego kodu. Chociaż istnieją ogólne zasady dotyczące stosunku między pracami rozwojowymi a pracami konserwacyjnymi, będą się one bardzo różnić w zależności od projektu. Bądź rozsądny.
• Zastanów się, dlaczego nie jesteś w stanie przekonać kolegi z zespołu, że kod należy uprościć?
• Nie zawsze musisz robić wszystko idealnie. Oznaczałoby to recenzje kodu w nieskończonej pętli i nic się nie sprawdzało, ponieważ nic (oprócz mojego kodu, haha) nie jest idealne.
• Osobiście wolę, aby autor kodu miał ostatnie słowo. Oczywiście, jeśli ciągle wykonują bardzo słabą robotę, należy podjąć inne działanie, ale jak mówisz, ujemna wartość zmuszania programisty do zmiany kodu może być wyższa niż zysk uzyskany przez naprawienie go, jeśli jest to bardzo rzadka sytuacja .

Zdecydowanie mogę odnieść się do tego pytania. Obecnie jestem kierownikiem technicznym 2 zespołów i moim zadaniem jest zapewnienie, aby produkowany przez nas kod był jak najbardziej czytelny i możliwy do utrzymania. Jednocześnie jestem znany z tego, że produkuję jakiś „sprytny” kod i wiem, że większość moich kolegów z zespołu będzie miała trudności z jego przestrzeganiem.

Kilka uwag, które mogę zaoferować:

1. Twój zespół potrzebuje jednego tropu, który podejmie ostateczną decyzję w przypadku braku porozumienia. W ostatnim wydaniu byłem w zespole bez przywództwa i to było okropne. Wszystko stało się kłótnią, a jeśli masz niewiele osób o silnych osobowościach, żadna z nich się nie ruszy. Jeśli masz potencjalną szansę, niezależnie od tego, która decyzja zostanie wybrana, wszyscy członkowie zespołu MUSZĄ zrozumieć, że to, co mówi potencjalna szansa, idzie. Właśnie dlatego kierownictwo uczyniło go liderem.

2. Dbanie o zadowolenie ludzi jest bardzo ważne. Dlatego zamiast popychać cały zespół w stronę swojego punktu widzenia, wystarczy popchnąć go tam. Wyjaśnij zasady SOLID, wyjaśnij znaczenie małych i spójnych klas / metod / interfejsów i powtórz te rzeczy za każdym razem, gdy zobaczysz, że są naruszane (tj. Podczas przeglądu kodu). Jednocześnie nie zmuszaj ich do przepisywania wszystkich rzeczy, których nie lubisz. Na koniec dnia potrzebujesz równowagi między ekspresją osobistą a przestrzeganiem standardów grupy. Miejmy nadzieję, że będą się one zbieżne, gdy osobiste preferencje zmienią się w kierunku działania grupy w ogóle.

3. Uważam, że o wiele ważniejsze jest posiadanie czystych, łatwych do zrozumienia interfejsów klasowych, niż brak jakiegokolwiek „sprytnego” kodu. Na przykład mamy klasę, która utrzymuje listę wpisów, które są wyszukiwane na 3 różne sposoby. Obecnie po prostu używa wyszukiwania liniowego dla wszystkich odnośników, co działa na małą skalę, ale ponieważ ta klasa jest na bardzo niskim poziomie, widzę, że nie skaluje się zbyt dobrze. Mam zamiar zastąpić go inną klasą, która używa kontenerów Boost Intrusive. Każdy element będzie obsługiwał umieszczanie w każdym indeksie jednocześnie, a wszystkie wyszukiwania będą wykonywane w O (sqrt (N)). Tak, będzie to o wiele bardziej skomplikowane wewnątrz i wiele osób nie lubi wzmocnienia, ale na zewnątrz pozostaną 3 metody: dodawanie, usuwanie, pobieranie. Najważniejsze jest to, że ludzie mogą pisać dowolny kod (w granicach rozsądku),

4. Utrzymaj ideę własności kodu. Chociaż czasami jest to trudne do osiągnięcia, ponieważ różne osoby mogą potrzebować dodać / zmodyfikować jakiś kod. Kiedy kod jest zapisywany, pierwotny programista jest ostatecznym posiadaczem tego kodu. To nie znaczy, że nikt inny nie może tego dotknąć. Jeśli inni zmodyfikują swój kod, to w porządku, ale pod koniec dnia oryginalny programista sprawdza go i pozostaje odpowiedzialny za wszystko, co się tam dzieje. Niezależnie od tego, czy ten kod jest prosty czy sprytny, to jego dziecko. Jeśli / kiedy, jak przewidujesz, błędy zaczynają się gromadzić z powodu podjętych decyzji dotyczących projektowania / kodowania, zamiast po prostu naprawiać te błędy, gdy się pojawią, usiądź z tym deweloperem (kto btw powinien naprawić wszystkie te błędy) i zastanowić się nad tymi decyzjami, aby zobaczyć, w jaki sposób mogły zostać podjęte inaczej.

Spędziłem wiele lat na kierowaniu zespołami programistycznymi i zarządzaniu nimi. Z natury jestem trochę obsesyjny na punkcie kodu i bardzo czarno-biały. Nauczyłem się dzięki doświadczeniu, że wybieranie bitew jest jedną z najtrudniejszych umiejętności do nauczenia się jako lider zespołu. Tak, standardy są ważne. Tak, czytelność i łatwość konserwacji są niezwykle ważne. Tak, wszyscy powinniśmy starać się pisać jednolity, zgodny ze standardami kod. Programiści to ludzie ... nie narzędzia do generowania kodu. Mamy osobowości, opinie, nudzimy się i chcemy uczyć się nowych rzeczy.

Podczas przeglądów kodu w pracy widziałem kod i wzorce, które uważam za „sprytne”, choć niekoniecznie zwiększające ogólną jakość lub łatwość konserwacji bazy kodu.

OK ... więc nie dodają, ale czy szkodzą? Czy mówimy tylko o osobistych preferencjach dotyczących stylów kodowania, czy też pisanie kodu jest zupełnie niepotrzebne (np. Używanie drzew wyrażeń i refleksji tylko dlatego, że fajnie jest używać drzew wyrażeń i refleksji)? Jeśli to ten pierwszy, pozwól mu odejść. Radość z bycia programistą polega na kreatywnym rozwiązywaniu problemów. Być może (i większość z nas nie lubi tego przyznać) czasami czujemy się zastraszani podejściami, których nie rozumiemy i albo nie chcemy pytać, albo nie mamy dodatkowej energii, aby nauczyć się nowego podejścia.

Teraz, gdy kreatywność prowadzi do niepotrzebnego kodu i całkowicie nieuzasadnionej złożoności, to zdecydowanie bądź głośny i uzasadnij swoją opinię. Bycie graczem zespołowym jest ważne, ale także bycie odpowiedzialnym (i pociąganie innych). Przeglądy kodu dotyczą zarówno odpowiedzialności, jak zapewnienia jakości i nauki. Będziesz stawał na palcach, ale jeśli masz wrażenie, że masz mocny argument, dlaczego wysiłek (pieniądze) powinien zostać wydany na przepisanie działającego kodu ORAZ ego powinno zostać zmiażdżone w tym procesie ORAZ chcesz ryzykować osłabienie czyjegoś entuzjazmu dla ich rzemiosła , to nie powinieneś unikać umieszczania go na stole. Jeśli jesteś liderem zespołu, to twoja praca. Bądź świadomy wpływu i zrób to. Jeśli nie jesteś liderem zespołu i nie masz uprawnień, zdecyduj o tym.

Najlepszym sposobem na zaszczepienie odpowiedzialności w zespole jest zachęcenie innych do pociągnięcia do odpowiedzialności. Jeśli zachowujesz otwarty umysł i nie zamykasz ludzi, gdy sugerują ulepszenia twojego kodu, możesz zauważyć, że są bardziej otwarci na twoje sugestie.

Z własnego doświadczenia, kiedy to się dzieje, prosiłbym o zgodę na bycie ochotniczym testerem jednostki przeciwnika, aby pisać testy w celu torturowania nieznanej implementacji.

Będę bardzo się starał, aby naprawdę zrozumieć, jak działa kod, a także spróbuję go sondować na wiele różnych sposobów.

Pamiętaj, że jest to zobowiązanie czasowe. Mogą to być godziny, dziesiątki godzin, a nawet spora część tygodnia. To, czy jest to uzasadnione, zależy od tego, czy złożoność kodu jest współmierna do złożoności wymagania.

Gdybym nie zwyciężał, tj. Jeśli kod przetrwa wiele testów, przekonałbym się, że może implementacja jest naprawdę bardziej oświecona niż ja i poprę jej włączenie do głównego produktu.

W zależności od metodologii kontroli źródła, kod może wymagać tymczasowego przypisania do systemu kontroli źródła (być może w oddziale) przed rozpoczęciem tej fazy testowania.

Moja odpowiedź jest zabarwiona moim doświadczeniem w korzystaniu z OpenCV. Istnieją algorytmy, które są znacznie bardziej wyrafinowane niż jakikolwiek programista może zaimplementować samodzielnie; nawet doktoratów - może kilka najlepszych procent doktorów. Jeśli kod jest tak dobry, musisz mu zaufać, działając wbrew własnemu instynktowi i uprzedzeniom, nawet jeśli nie masz skutecznych środków na określenie tego poziomu zaufania.