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?