Jak powiedzieć komuś, że pisze zły kod? [Zamknięte]

Dla zabawy pracuję z małą grupą ludzi nad projektem kodowania. Jest to zorganizowana i dość spójna grupa. Ludzie, z którymi pracuję, mają różne zestawy umiejętności związanych z programowaniem, ale niektórzy z nich używają starszych lub zupełnie niewłaściwych metod, takich jak nadmierne zmienne globalne, złe konwencje nazewnictwa i inne rzeczy. Podczas gdy rzeczy działają, implementacja jest słaba. Jaki jest dobry sposób grzecznego poproszenia lub wprowadzenia ich w celu zastosowania lepszej metodologii, bez zakwestionowania (lub znieważenia) ich doświadczenia i / lub edukacji?

Przedstaw pytania, aby uświadomić im, że to, co robią, jest złe. Na przykład zadaj tego rodzaju pytania:

Dlaczego zdecydowałeś się uczynić tę zmienną globalną?

Dlaczego nazwałeś to tak?

To interesujące. Zazwyczaj robię to w ten sposób, ponieważ [Wpisz powód, dla którego jesteś lepszy]

Czy to działa? Zwykle [wstaw, jak byś wyglądał głupio]

Myślę, że idealnym sposobem na to jest subtelne pytanie, dlaczego kodują w określony sposób. Może się okazać, że uważają, że istnieją inne korzyści. O ile nie wiedziałem, że powodem ich stylu kodowania były dezinformacje, nigdy nie uznałbym swojej drogi za lepszą bez uzasadnionego powodu. Najlepszym sposobem na to jest po prostu zapytać ich, dlaczego wybrali tę drogę; upewnij się, że jesteś zainteresowany ich rozumowaniem, ponieważ to właśnie musisz zaatakować, a nie ich zdolność.

Standard kodowania na pewno pomoże, ale gdyby to była odpowiedź na każdy projekt oprogramowania, wszyscy popijalibyśmy koktajle na naszych prywatnych wyspach w raju. W rzeczywistości wszyscy jesteśmy podatni na problemy, a projekty oprogramowania wciąż mają niski wskaźnik powodzenia. Myślę, że problem wynikałby głównie z indywidualnych zdolności, a nie z konwencji, dlatego sugeruję, aby przepracować problemy jako grupę, gdy problem pojawia się w jego brzydkiej głowie.

Co najważniejsze, NIE od razu zakładaj, że twoja droga jest lepsza . W rzeczywistości prawdopodobnie tak jest, ale mamy do czynienia z opinią innej osoby i dla niej jest tylko jedno rozwiązanie. Nigdy nie mów, że twoja droga jest lepszym sposobem na zrobienie tego, chyba że chcesz, aby postrzegali cię jako zadowolonego z siebie przegranego.

Zacznij przeglądać kod lub programować w parach.

Jeśli zespół nie wybierze się na nie, wypróbuj cotygodniowe recenzje projektów. Co tydzień spotykaj się przez godzinę i rozmawiaj o kawałku kodu. Jeśli ludzie wydają się defensywni, wybierz stary kod, z którym nikt nie jest już związany emocjonalnie, przynajmniej na początku.

Jak powiedział @JesperE: skup się na kodzie, a nie na kodzie.

Kiedy widzisz coś, co Twoim zdaniem powinno być inne, ale inni nie widzą tego w ten sam sposób, zacznij od zadawania pytań, które prowadzą do braków, zamiast ich wskazywania. Na przykład:

Globals : Czy uważasz, że kiedykolwiek będziemy chcieli mieć więcej niż jeden z nich? Czy uważasz, że będziemy chcieli kontrolować dostęp do tego?

Zmienny stan : Czy uważasz, że będziemy chcieli manipulować tym z innego wątku?

Uważam też, że pomocne jest skupienie się na moich ograniczeniach, które mogą pomóc ludziom się zrelaksować. Na przykład:

długie funkcje : Mój mózg nie jest wystarczająco duży, aby pomieścić to wszystko na raz. Jak możemy zrobić mniejsze elementy, z którymi mogę sobie poradzić?

złe nazwy : łatwo się mylę, czytając czysty kod; kiedy imiona wprowadzają w błąd, nie mam dla mnie nadziei.

Ostatecznie celem nie jest nauczenie zespołu lepszego kodowania. Ma to na celu stworzenie kultury uczenia się w zespole. Gdzie każda osoba zwraca się do innych o pomoc w zostaniu lepszym programistą.

Przedstaw ideę standardu kodu. Najważniejszą rzeczą w standardzie kodu jest to, że proponuje on ideę spójności w bazie kodu ( najlepiej cały kod powinien wyglądać tak, jakby został napisany przez jedną osobę na jednym posiedzeniu), co doprowadzi do bardziej zrozumiałego i łatwego do utrzymania kodu.

Musisz wyjaśnić, dlaczego twoja droga jest lepsza .

Wyjaśnij, dlaczego funkcja jest lepsza niż wycinanie i wklejanie.

Wyjaśnij, dlaczego tablica jest lepsza niż $ foo1, $ foo2, $ foo3.

Wyjaśnij, dlaczego zmienne globalne są niebezpieczne i że zmienne lokalne ułatwią życie.

Po prostu wymyślenie standardu kodowania i powiedzenie „zrób to” jest bezwartościowe, ponieważ nie wyjaśnia programistom, dlaczego jest to dobra rzecz.

Po pierwsze, uważam, aby nie oceniać zbyt szybko. Łatwo jest odrzucić jakiś kod jako zły, gdy mogą istnieć dobre powody, dla których tak jest (np. Praca ze starszym kodem z dziwnymi konwencjami). Ale załóżmy na chwilę, że są naprawdę źli.

Możesz zasugerować ustanowienie standardu kodowania w oparciu o wkład zespołu. Ale naprawdę musisz wziąć pod uwagę ich opinie, a nie tylko narzucić swoją wizję dobrego kodu.

Inną opcją jest przyniesienie do biura książek technicznych (Code Complete, Effective C ++, Pragmatic Programmer ...) i zaoferowanie pożyczenia go innym („Hej, skończyłem z tym, czy ktoś chciałby go pożyczyć?” )

Jeśli to możliwe, upewnij się, że rozumieją, że krytykujesz ich kod , a nie oni osobiście.

Zaproponuj lepszą alternatywę w sposób niekonfrontacyjny.

„Hej, myślę, że ten sposób też zadziała. Co wy myślicie?” [Gest, aby oczywiście poprawić kod na ekranie]

Mają opinie kod i zacząć od przeglądu SWÓJ kod.

Ułatwi to ludziom cały proces przeglądu kodu, ponieważ zaczynasz proces od przeglądu własnego kodu zamiast własnego. Rozpoczęcie od kodu da im również dobre przykłady tego, jak to zrobić.

Mogą myśleć, że twój styl też śmierdzi. Zbierz zespół, aby omówić spójny zestaw wytycznych dotyczących stylu kodowania. Zgadzam się na coś. To, czy pasuje to do Twojego stylu, nie jest problemem, liczy się każdy styl, o ile jest on spójny.

Przez przykład. Pokaż im właściwą drogę.

Zrób to powoli. Nie wyrzucaj ich za każdy mały błąd od samego początku, po prostu zacznij od rzeczy, które naprawdę mają znaczenie.

Pomysł standardowego kodu jest dobry.

Ale nie mów nic, zwłaszcza, że ​​jest to dla zabawy, prawdopodobnie z osobami, z którymi się przyjaźnisz. To tylko kod ...

Jest kilka naprawdę dobrych rad w książce Gerry'ego Weinberga „Psychologia programowania komputerowego” - całe jego pojęcie „programowania bez ego” dotyczy tego, jak pomóc ludziom zaakceptować krytykę ich kodu w odróżnieniu od krytyki własnej.

Złe praktyki nazewnictwa: zawsze niewybaczalne.

I tak, nie zawsze zakładaj, że twoja droga jest lepsza ... Może to być trudne, ale należy zachować obiektywizm.

Mam doświadczenie z koderem, który miał tak okropne nazewnictwo funkcji, że kod był gorszy niż nieczytelny. Funkcje kłamały na temat tego, co zrobili, kod był bezsensowny. I byli ochronni / odporni na to, że ktoś inny zmieni ich kod. kiedy skonfrontowali się bardzo uprzejmie, przyznali, że jest źle nazwany, ale chcieli zachować własność kodu i wrócić i naprawić go „w późniejszym terminie”. To już przeszłość, ale jak radzisz sobie z sytuacją, w której błąd jest POTWIERDZONY, ale następnie chroniony? Trwało to przez długi czas i nie miałem pojęcia, jak przebić się przez tę barierę.

Zmienne globalne: Sam nie przepadam za zmiennymi globalnymi, ale znam kilku doskonałych programistów, którzy bardzo je lubią. Do tego stopnia, że ​​uwierzyłem, że w wielu sytuacjach nie są wcale takie złe, ponieważ pozwalają na przejrzystość, łatwość debugowania. (proszę, nie płać mi / nie oceniaj mnie :)) Sprowadza się to do tego, że widziałem wiele bardzo dobrego, skutecznego, wolnego od błędów kodu, który wykorzystywał zmienne globalne (nie wprowadzane przeze mnie!) i dużo błędów niemożliwy do odczytania / utrzymania / naprawy kod, który skrupulatnie używał właściwych wzorców. Może tam JEST miejsce (choć być może kurczy) dla zmiennych globalnych? Zastanawiam się nad przemyśleniem mojej pozycji na podstawie dowodów.

Uruchom wiki w swojej sieci za pomocą oprogramowania wiki.

Zacznij kategorię w swojej witrynie o nazwie „najlepsze praktyki” lub „standardy kodowania” lub coś w tym rodzaju.

Wskaż wszystkim to. Pozwól na opinie.

Kiedy robisz wersje oprogramowania, poproś osobę, której zadaniem jest wstawienie kodu do kompilacji, wypchnij programistów, kierując ich na strony Wiki.

Zrobiłem to w mojej organizacji i zajęło to kilka miesięcy, aby ludzie naprawdę zaczęli korzystać z Wiki, ale teraz jest to niezbędny zasób.

Jeśli masz nawet luźny standard kodowania, możesz wskazać na to lub wskazać, że nie możesz postępować zgodnie z kodem, ponieważ nie jest to prawidłowy format, być może warto.

Jeśli nie masz formatu kodowania, teraz byłby dobry moment, aby go wprowadzić. Pomocne mogą być odpowiedzi na to pytanie: /programming/4121/team-coding-styles

Zawsze wybieram zdanie „To właśnie bym zrobił”. Nie próbuję ich pouczać i mówić im, że ich kod to śmiecie, ale daję alternatywny punkt widzenia, który, mam nadzieję, pokaże im coś, co jest oczywiście trochę starsze.

Poproś osobę (osoby) o przygotowanie prezentacji dla reszty grupy na temat kodu dla napisanego przez nich reprezentatywnego modułu, i pozwól, aby zadali to pytania (uwierz mi, zrobi to, a jeśli jest to dobra grupa, nie powinno nawet stać się brzydkie).

Uwielbiam kodować i nigdy nie miałem w życiu żadnego kursu dotyczącego czegokolwiek związanego z informatyką. Zacząłem bardzo źle i zacząłem uczyć się na przykładach, ale to, co zawsze pamiętam i pamiętałem, odkąd przeczytałem książkę „Gang czterech” :

„Każdy może pisać kod zrozumiały dla maszyny, ale nie wszyscy mogą pisać kod zrozumiały dla człowieka”

Mając to na uwadze, w kodzie jest wiele do zrobienia;)

Nie mogę wystarczająco podkreślić cierpliwości. Widziałem tego rodzaju rzeczy całkowicie odwrotne, głównie dlatego, że ktoś chciał, żeby zmiany miały miejsce TERAZ. Sporo środowisk potrzebuje korzyści ewolucji, a nie rewolucji. Wymuszając dziś zmiany, może stworzyć bardzo nieszczęśliwe środowisko dla wszystkich.

Wpis jest kluczem. Twoje podejście musi uwzględniać środowisko, w którym się znajdujesz.

Wygląda na to, że jesteś w środowisku, które ma w sobie wiele „indywidualności”. Więc ... nie sugerowałbym zestawu standardów kodowania. Przekonasz się, że chcesz wziąć ten „zabawny” projekt i przekształcić go w wysoce ustrukturyzowany projekt roboczy (och, świetnie, co dalej… dokumenty funkcjonalne?). Zamiast tego, jak powiedział ktoś inny, będziesz musiał sobie z tym poradzić do pewnego stopnia.

Bądź cierpliwy i staraj się edukować innych w twoim kierunku. Zacznij od krawędzi (punktów, w których Twój kod wchodzi w interakcję z innymi), a podczas interakcji z ich kodem spróbuj wykorzystać to jako okazję do przedyskutowania interfejsu, który stworzyli i zapytaj ich, czy byłby z nimi w porządku, gdyby został zmieniony (przez ty lub oni). I w pełni wyjaśnij, dlaczego chcesz zmiany („pomoże to lepiej radzić sobie ze zmianą atrybutów podsystemu” lub cokolwiek). Nie podrywaj i próbuj zmieniać wszystko, co uważasz za błędne. Kiedy już wchodzisz w interakcję z innymi na krawędzi, powinni zacząć widzieć, w jaki sposób przyniesie im to korzyści w rdzeniu ich kodu (a jeśli uzyskasz wystarczającą dynamikę, wejdź głębiej i naprawdę zacznij omawiać nowoczesne techniki i zalety kodowania standardów). Jeśli nadal tego nie widzą ... może ty?

Cierpliwość. Ewolucja, nie rewolucja.

Powodzenia.

Zakładam togę i otwieram puszkę metody sokratejskiej.

Metoda Sokratesa nazwany klasycznego greckiego filozofa Sokratesa, jest formą myśli filozoficznej, w którym pytający bada konsekwencje pozycjach innych, aby stymulować racjonalnego myślenia i oświetlania pomysły. Ta metoda dialektyczna często wymaga opozycyjnej dyskusji, w której obrona jednego punktu widzenia jest skierowana przeciwko drugiemu; jeden uczestnik może doprowadzić innego do sprzeczności, wzmacniając w ten sposób własny punkt dociekania.

Wiele odpowiedzi tutaj dotyczy formatowania kodu, które obecnie nie są szczególnie istotne, ponieważ większość IDE przeformatuje kod w wybranym przez ciebie stylu. To, co naprawdę ma znaczenie, to jak działa kod, a plakat ma prawo patrzeć na zmienne globalne, kopiować i wklejać kod, i mój wkurzony, konwencje nazewnictwa. Istnieje coś takiego jak zły kod i ma on niewiele wspólnego z formatem.

Zaletą jest to, że większość z nich jest zła z bardzo dobrego powodu, a przyczyny te są ogólnie policzalne i możliwe do wyjaśnienia. Zatem w sposób niekonfrontacyjny wyjaśnij przyczyny. W wielu przypadkach można nawet podać scenariusze pisarza, w których problemy stają się oczywiste.

Nie jestem głównym programistą w moim projekcie i dlatego nie mogę narzucać standardów kodowania, ale odkryłem, że zły kod zwykle powoduje problem raczej wcześniej niż później, a kiedy to robi, mam czystszy pomysł lub rozwiązanie.

Nie wtrącając się wtedy w interakcje i przyjmując bardziej naturalne podejście, zyskałem większe zaufanie do lidera i często zwraca się do mnie z pomysłami i włącza mnie w projekt architektoniczny i strategię wdrażania zastosowaną w projekcie.

Ludzie piszący zły kod to tylko przejaw ignorancji (która różni się od głupoty). Oto kilka wskazówek dotyczących postępowania z tymi ludźmi.

• Własne doświadczenia ludzi pozostawiają silniejsze wrażenie niż coś, co powiesz.
• Niektórzy ludzie nie pasjonują się tworzonym przez siebie kodem i nie słuchają niczego, co mówisz
• Programowanie sparowane może pomóc dzielić się pomysłami, ale zmieniać, kto jedzie, albo będą tylko sprawdzać pocztę e-mail na swoim telefonie
• Nie topi ich zbyt wiele, zauważyłem, że nawet Continuous Integration trzeba było wyjaśnić kilka starszych deweloperów
• Podnieś ich ponownie, a będą chcieli się uczyć. Może to być coś tak prostego, jak programowanie robotów na jeden dzień
• ZAUFAJ SWOJEMU ZESPOŁOWI, standardy kodowania i narzędzia sprawdzające je podczas kompilacji często nigdy nie są czytane ani denerwujące.
• Usuń własność kodu, w niektórych projektach zobaczysz silosy kodu lub wzgórza mrówek, gdzie ludzie mówią, że to mój kod i nie możesz go zmienić, jest to bardzo złe i możesz go usunąć za pomocą sparowanego programowania.

Zamiast zmuszać ich do pisania kodu, poproś go o zachowanie kodu.

Dopóki nie będą musieli utrzymywać parującego stosu spaghetti, nigdy nie zrozumieją, jak źle radzą sobie z kodowaniem.

Nikt nie lubi słuchać, jak ktoś mówi, że ich praca jest do bani, ale każda rozsądna osoba chętnie skorzysta z mentoringu i sposobów unikania niepotrzebnej pracy.

Jedna ze szkół naucza nawet, że nie powinieneś wskazywać błędów, ale skupiać się na tym, co zrobiono dobrze. Na przykład zamiast wskazywać na niezrozumiały kod jako zły, należy wskazać, gdzie jego kod jest szczególnie łatwy do odczytania. W pierwszym przypadku pobudzasz innych do myślenia i działania jak gówniani programiści. W późniejszym przypadku przygotowujesz się do myślenia jak wykwalifikowany profesjonalista.

Mam podobny senario z facetami, z którymi pracuję. Nie mają tak dużego doświadczenia w kodowaniu, jak ja, ale nadal są przydatni w kodowaniu.

Zamiast mnie pozwalać robić to, co chcą, wracać i edytować całość. Zwykle po prostu je siedzę i pokazuję dwa sposoby robienia rzeczy. Ich droga i moja droga, od tego omawiamy zalety i wady każdej metody, a zatem dochodzimy do lepszego zrozumienia i lepszego wniosku, w jaki sposób powinniśmy kontynuować programowanie.

Oto naprawdę niesamowita część. Czasami pojawiają się pytania, na które nawet nie mam odpowiedzi, a po badaniach wszyscy uzyskujemy lepszą koncepcję metodologii i struktury.

1. Omawiać.
2. Pokaż im, dlaczego
3. Nawet nie myśl, że zawsze masz rację. Czasami nawet oni nauczą cię czegoś nowego.

To właśnie zrobiłbym, gdybym był tobą: D

Prawdopodobnie nieco później po efekcie, ale tam dobrze jest uzgodniony standard kodowania.

Szczerze wierzę, że czyjś kod jest lepszy, gdy łatwiej jest go zmieniać, debugować, nawigować, rozumieć, konfigurować, testować i publikować (whew).

To powiedziawszy, myślę, że nie można powiedzieć komuś, że jego kod jest zły bez uprzedniego wyjaśnienia, co robi lub jak ktoś powinien go później ulepszyć (np. Stworzyć nową funkcjonalność lub debugować).

Tylko wtedy ich umysł pęka i każdy będzie mógł zobaczyć, że:

• Zmiany wartości zmiennych globalnych są prawie zawsze niemożliwe do prześledzenia
• Ogromne funkcje są trudne do odczytania i zrozumienia
• Wzory ułatwiają ulepszanie kodu (o ile przestrzegasz ich reguł)
• (itp ...)

Być może sesja programowania par powinna załatwić sprawę. Jeśli chodzi o egzekwowanie standardów kodowania - to pomaga, ale są one zbyt dalekie od zdefiniowania, co jest dobrym kodem.

Prawdopodobnie chcesz skupić się na wpływie złego kodu, a nie na tym, co można odrzucić jako subiektywną opinię na temat tego, czy jest to dobry, czy zły styl.

Prywatnie pytaj o niektóre „złe” segmenty kodu, mając na uwadze możliwość, że jest to rzeczywiście uzasadnione kod (bez względu na to, jak bardzo jesteś predysponowany), lub że mogą wystąpić okoliczności łagodzące. Jeśli nadal jesteś przekonany, że kod jest po prostu zły - i że źródłem jest właśnie ta osoba - po prostu odejdź. Może się zdarzyć jedna z kilku rzeczy: 1) osoba zauważy i podejmie jakieś działania naprawcze, 2) osoba nic nie robi (jest nieświadoma lub nie dba tak bardzo jak ty).

Jeśli zdarzy się # 2 lub # 1 nie zapewni wystarczającej poprawy z twojego punktu widzenia, I szkodzi to projektowi i / lub wywiera na ciebie wystarczający wpływ, może być czas na rozpoczęcie kampanii w celu ustanowienia / egzekwowania standardów w ramach drużyna. Wymaga to wpisowego w zarządzanie, ale jest najbardziej skuteczne, gdy jest inicjowane od podstaw.

Powodzenia z tym. Czuję twojego bólu brata.