Jak „zneutralizować” tych, którzy piszą zły kod w zespole?

Zawsze podobał mi się ten artykuł na temat JoelOnSoftware zatytułowany „Pierwsze rzeczy zrobione, gdy jesteś tylko chrypką”. Mógłbym szczególnie relacjonować, kiedy byłem nowicjuszem (i nadal czuję, że ZAWSZE będę jednym).

Około 4, neutralizowanie bozo. Jakie masz porady dotyczące faktycznego wdrożenia tego w rzeczywistych sytuacjach w pracy? Nie wydaje się to tak łatwe (przynajmniej w naszym zespole), jak po prostu zarejestrowanie błędu w czyimś złym kodzie. Co działa dla reszty z was?

team bug

— C Johnson
źródło

Pistolety Wiele z nich.

— CodesInChaos

Odpowiedzi:

Stała ocena.

Pod koniec każdego dnia poświęć 30 minut na sprawdzenie, co napisali. Jeśli zrobili coś złego, spraw, aby przepisali.

Jeśli tego nie zrobisz, pewnego dnia zdasz sobie sprawę, że część twojego wniosku, choć wydaje się być w stanie wykonać tę pracę, jest całkowicie niemożliwa do utrzymania, niewłaściwie zaprojektowana i spowoduje wiele problemów w przyszłości - a nawet jutro.

Nawet jeśli sprawi to, że będą mniej produktywne, nadal będzie znacznie lepiej, jeśli stworzą dobry kod przeciwko dwa razy większemu rozmiarowi, ale niemożliwym do utrzymania nadęciu błędów.

— P Shved
źródło

Świetna odpowiedź. Jeśli mogę po prostu do tego dołączyć, jeśli ta osoba jest rówieśnikiem, najlepiej zrobić to lider zespołu. W ten sposób odpowiedź „nie-dobra-zrób-to-ponownie” byłaby znacznie bardziej skuteczna, gdyby nakazała jej hierarchia sklepu.

@ Surfer, jest dokładnie odwrotnie. Stajesz się liderem zespołu, robiąc takie rzeczy, proponując lepsze rozwiązania, dbając o to, co robi zespół. Nie odwrotnie. (Ale oczywiście pomaga w uzyskaniu pomocy z wyższych poziomów hierarchii).

— P Shved

Powstaje więc pytanie, kto ma uprawnienia, aby je przepisać? Wydaje mi się, że odpowiedzią jest autorytet moralny całego zespołu, jeśli problemy zostaną przekazane całemu zespołowi.

— C Johnson,

W przypadku braku solidnego mechanizmu przeglądu kodu dla każdego członka zespołu jest to właściwe. Należy również upewnić się, że bozo nie wykopie naprawdę głębokiej dziury (nawet nie jest to warte kosztu naprawy), zanim zostanie poproszony o jej przerobienie.

— mattnz

Jeśli dana osoba po prostu nie wie nic więcej, ale chce się uczyć, zapewnij mentoring i przejrzyj kod. Upewnij się, że są narażone na dobry kod.

Naprawdę słabymi programistami są ci, którzy są źle nastawieni i walczą o naukę czegoś nowego. Waszą jedyną nadzieją jest pozwolić im cierpieć poprzez utrzymanie własnego bałaganu lub niektórych prostszych rzeczy. Idealnie byłoby, gdyby ktoś z autorytetu wstał i powiedział, że się zgadza lub odchodzi.

— JeffO
źródło

Postawa naprawdę się liczy. Zazwyczaj uważam, że nowicjusz jest bardziej skromny i otwarty na recenzje kodu i krytykę. Z tymi ludźmi łatwo się rozmawia. I możesz łatwo z nimi porozmawiać o ich słabościach. To aroganccy weterani, którzy rozbiją się jak milion kawałków szkła, kiedy zostaną skrytykowani za swoją pracę.

— C Johnson,