Zadaję to pytanie programistom C ++, ponieważ: a) Tylko programista C ++ może ocenić zalety techniczne przykładów; b) Tylko programista wyczuje temperament innego programisty, który pisze taki kod.
HR i dyrektorzy są świadomi, że istnieje problem, ponieważ widzą dowody w terenie. To moje wezwanie, czy dajemy programiście więcej czasu. Wiele błędów jest na bardzo podstawowym poziomie - moje pytanie (do programistów) brzmi: czy ktoś, kto twierdzi, że jest starszym programistą C ++, powinien mieć wątpliwości co do próbki obecnego kodu. Osoby niebędące programistami - nawet osoby spoza programowania w C ++ - nie mogą na ten temat oceniać.
W tle powierzono mi zadanie zarządzania programistami w ugruntowanej firmie. Mają jednego programistę, który specjalizuje się we wszystkich kodowaniach C ++ (od zawsze), ale jakość pracy jest fatalna. Przeglądy i testy kodu ujawniły wiele problemów, z których jednym z najgorszych są wycieki pamięci. Deweloper nigdy nie testował swojego kodu pod kątem wycieków, a ja odkryłem, że aplikacje mogą przeciekać wiele MB przy zaledwie minucie użytkowania. Użytkownik zgłaszał ogromne spowolnienia, a jego zdanie brzmiało: „to nie ma ze mną nic wspólnego - jeśli odejdą i zrestartują się, wszystko znowu będzie dobrze”.
Dałem mu narzędzia do wykrywania i śledzenia wycieków, i usiadłem z nim przez wiele godzin, aby zademonstrować, w jaki sposób używane są narzędzia, gdzie występują problemy i co zrobić, aby je naprawić. Minęło 6 miesięcy, a ja wyznaczyłem go do napisania nowego modułu. Przejrzałem go, zanim został zintegrowany z naszą większą bazą kodu i z przerażeniem odkryłem to samo złe kodowanie, co poprzednio. Niezrozumiałe jest to, że niektóre kodowanie jest gorsze niż amatorskie. Na przykład chciał klasy (Foo), która mogłaby wypełnić obiekt innej klasy (Bar). Zdecydował, że Foo będzie zawierać odniesienie do Baru, np .:
class Foo {
public:
Foo(Bar& bar) : m_bar(bar) {}
private:
Bar& m_bar;
};
Ale (z innych powodów) potrzebował też domyślnego konstruktora dla Foo i zamiast kwestionować swój początkowy projekt, napisał ten klejnot:
Foo::Foo() : m_bar(*(new Bar)) {}Tak więc za każdym razem, gdy wywoływany jest domyślny konstruktor, wycieknie pasek. Co gorsza, Foo przydziela pamięć ze sterty na 2 inne obiekty, ale nie napisał niszczyciela ani konstruktora kopii. Tak więc każda alokacja Foo przecieka 3 różne obiekty i możesz sobie wyobrazić, co się stało, gdy Foo zostało skopiowane. I - robi się coraz lepiej - powtórzył ten sam wzór w trzech innych klasach, więc nie jest to jednorazowy poślizg. Cała koncepcja jest błędna na tak wielu poziomach.
Czułbym więcej zrozumienia, gdyby pochodziło to od nowicjusza. Ale ten facet robi to od wielu lat i przez ostatnie kilka miesięcy bardzo skoncentrował się na szkoleniach i poradach. Zdaję sobie sprawę, że przez większość czasu pracował bez mentoringu i recenzji, ale zaczynam czuć, że nie może się zmienić. Moje pytanie brzmi: czy uparłbyś się przy kimś, kto pisze tak ewidentnie zły kod?
źródło
Odpowiedzi:
Radzę skonfrontować go z tym konkretnym przykładem i zobaczyć, co mówi. Jeśli zaprzecza, że jest coś złego w kodzie, obawiam się, że niewiele możesz zrobić. Jeśli zaakceptuje, że popełnił błąd (nawet jeśli jest w tym defensywie), to przynajmniej jest miejsce na poprawę. Jeśli poświęcisz czas i wysiłek na ulepszenie go, wtedy ty lub starszy programista będziecie musieli go usiąść i wspólnie kodować, aż wszystkie te tendencje zostaną spłaszczone (bądź przygotowany na poświęcenie tej osoby przez co najmniej 1 miesiąc).
Zły programista, z którym zwykle mogę pracować, ale programista, który nie może się poprawić, nie mogę.
źródło
Nie. Zwolniłbym każdego profesjonalnego programistę C ++, który nie posiadał podstawowej wiedzy na temat zarządzania pamięcią.
Jeśli jest to ktoś pochodzący z Javy, C # lub czegoś innego, dałbym im trochę swobody, ale to czysta niekompetencja.
źródło
Nie możemy odpowiedzieć na szerszą część twojego pytania. Mianowicie, powinieneś zatrzymać lub zwolnić tego pracownika. Zwolnienie pracownika jest trudne, ale jest to decyzja niezależna od społeczności takiej jak ta.
Zaktualizowałeś swoje pytanie, aby ograniczyć odpowiedzi do programistów C ++. Dla mojego tła / kwalifikacji: Obcinam zęby w C i mogę pisać w C ++, C # i Javie. I lubię ścigać się w wyścigach między wątkami, ponieważ uważam, że to dobra zabawa. Tak, trochę mnie kręci.
Twoja odpowiedź i decyzja dotyczy tego: to, czy ktoś może się zmienić, zależy od osoby i tego, czy chce się zmienić.
Ale zacznijmy od kilku pytań:
Musisz upewnić się, że możesz odpowiedzieć „tak” na wszystkie te pytania. Jeśli nie, nadal spoczywa na tobie ciężar dowodu na komunikację z nim.
Jego odpowiedź na twoją ostatnią recenzję będzie najbardziej wymowna.
Jeśli próbował i wykazuje pewne oznaki postępu, być może musisz przejrzeć proces mentoringu. Jeśli już, może powinieneś rozważyć powiązanie go z bardziej doświadczonym programistą, aby mógł uzyskać natychmiastowe informacje zwrotne podczas podejmowania decyzji projektowych. Nie jestem fanem programowania par, ale w takim przypadku może być to bardzo przydatne. Ciągłe wysyłanie go, by wprowadzał coraz więcej poprawek do starego kodu, nie zawsze jest praktyczną drogą do nauki.
Jeśli nie próbował, musisz lepiej zrozumieć jego motywację. Czy nie zrozumiał, że musi bardziej się postarać? Czy to go nie obchodzi? Czy są jeszcze inne obszary w zespole, w których jego umiejętności byłyby lepiej dopasowane i jest tym bardziej zainteresowany? Jeśli nie chciał spróbować, musisz zrozumieć, dlaczego.
Stamtąd będziesz wiedział, czy chce się zmienić i czy może się zmienić. Brak chęci zmiany jest równoznaczny z niemożnością zmiany. Jeśli jest chęć i stopień postępu, zastanów się nad zmianą sposobu, w jaki próbujesz go zrehabilitować.
źródło
Obawiam się, że jego zły kod nie jest jedynym problemem w twoim zespole.
Mówisz, że był w firmie przez dłuższy czas. Zwolnienie takiej osoby rzadko jest dobrym pomysłem (chyba że jest to pracownik typu Wally). Ich wiedza o potrzebach klientów, posiadanych produktach itp. Jest często o wiele cenniejsza niż kod, który piszą.
Rozwiązania:
źródło
Podjęcie decyzji o zwolnieniu każdego jest trudną decyzją dla każdego. Na twoją sytuację składa się kilka czynników:
To powiedziawszy, że spędziłeś ostatnie 6 miesięcy, pokazując programistom błąd jego sposobów, a jego nowy kod jeszcze się nie poprawił.
Na tym etapie naprawdę musisz zacząć proaktywne zarządzanie, abyś mógł to zrobić w ciągu 3 miesięcy
lub
Aby to zrobić, musisz jednak usiąść z programistą, wyjaśnić, co jest nie tak w piśmie / e-mailu, wyjaśnić, w jaki sposób programista może poprawić i bardzo bardzo wyraźnie stwierdzić, że jeśli oczekiwana poprawa nie nastąpi, zostanie rozwiązany w 3 miesięcy.
Musisz również jasno powiedzieć, że od tego momentu oczekuje się poprawy w pozostałej części jego pracy w firmie, a nie tylko na 3 miesiące!
Powinieneś także poinformować o tym swojego kierownika i dział HR (jeśli istnieje).
Podczas tego procesu będziesz musiał aktywnie zarządzać programistą i przeglądać zadania / kod co 1-2 dni i upewniać się, że wszystko jest w porządku, szczegółowo opisując te, które nie są, i wyjaśnić, co można zrobić, aby je ulepszyć.
źródło
Albo nie masz jasności co do tego, jak poważnie traktujesz jego słabe wykonanie (tzn. Możliwe, że widzi, ile czasu spędziłeś z nim jako opcję, jeśli chce poprawić, a nie absolutną konieczność), albo ma niewiarygodnie złe podejście, które jest niezrównoważone. Jeśli nie jest jeszcze jasne dla tego programisty, że rozważasz jego pozycję w tej sprawie, musisz to wyjaśnić (zakładając, że twoje przywództwo jest w porządku z twoim upoważnieniem do rozwiązania). Szok przyniesie nadzieję na zmianę.
Jednak decyzja o zatrudnieniu ma znacznie szersze implikacje niż tylko ten facet, musisz wziąć pod uwagę wpływ na zespół. Jeśli pozwoli mu się rozwinąć jego postawa, może to oburzyć innych lub sprawić, że inni też poczują, że tego rodzaju rzeczy są w porządku. Jednak z punktu widzenia zespołu musi być absolutnie jasne, że jeśli odszedł, to z właściwych powodów i miał wiele okazji do poprawy.
Jednym z klejnotów, który podniosłem na kursie wiele lat temu, jest fakt, że ludzie z wiedzą techniczną, której inni nie mają, mogą poprowadzić kierownictwo, aby dać im luz. To źle dla zespołu. Możesz bać się utraty jedynego programisty c ++, ale można je zastąpić. Oczywiście istnieje nieodłączne ryzyko, jeśli dobrze zna wypuszczone produkty, ale często widziałem osoby z pozornie niezastąpioną wiedzą na temat produktu / wiedzy technicznej wymieniane łatwiej niż się spodziewano. Zespoły i organizacje często mogą wypełnić luki, które początkowo wydają się trudne do wypełnienia. Oczywiście, jeśli nie ma on umiejętności w języku C ++ lub wiedzy specyficznej dla organizacji, którą trudno będzie zastąpić, problem jest znacznie mniejszy!
źródło
Oczywiście, że nie powinieneś. Pamiętaj, że to nie jest organizacja charytatywna, wymieniasz pieniądze na pracę. Jeśli nie trzyma swojej strony umowy, to jak każda transakcja, którą przestałbym płacić.
źródło
Jeśli chcesz dać mu szansę, opracuj ustandaryzowany test, który zbiera dane dotyczące wycieku pamięci. Monitoruj swoje postępy co tydzień, nalegając na zobaczenie kodu , który zmienił, i szukaj ulepszeń. Jeśli nie da sobie rady w tym momencie, zwolnij bezużytecznego inwentarza.
źródło