Я задаю этот вопрос программистам C ++, потому что: a) только программист C ++ может судить о технических достоинствах примеров; б) Только программист может почувствовать темперамент другого программиста, который пишет такой код.
HR и директора знают, что есть проблема просто потому, что они видят доказательства в этой области. Это мой вызов, дадим ли мы данному программисту больше времени. Многие из ошибок находятся на очень базовом уровне - мой вопрос (к программистам) заключается в том, следует ли кому-то, кто заявляет, что он является старшим разработчиком C ++, дать преимущество в виде сомнения на основе примеров их текущего кода. Непрограммисты - даже люди вне программирования на C ++ - не могут судить об этом.
Для справки, мне была поручена задача управления разработчиками в хорошо известной компании. У них есть один разработчик, который специализируется на всем своем кодировании на C ++ (с тех пор навсегда), но качество работы ужасно. Обзоры кода и тестирование выявили много проблем, одна из худших - утечки памяти. Разработчик никогда не проверял свой код на наличие утечек, и я обнаружил, что приложения могут пропускать много МБ всего за минуту использования. Пользователи сообщали об огромных замедлениях, и его мнение было таково: «Это не имеет никакого отношения ко мне - если они выходят и перезапускаются, все снова хорошо».
Я дал ему инструменты для обнаружения и отслеживания утечек и провел с ним много часов, чтобы продемонстрировать, как используются эти инструменты, где возникают проблемы и что нужно делать для их устранения. Мы на 6 месяцев вниз, и я поручил ему написать новый модуль. Я рассмотрел его до того, как он был интегрирован в нашу большую кодовую базу, и с ужасом обнаружил то же самое плохое кодирование, что и раньше. Часть, которую я нахожу непостижимой, состоит в том, что некоторые кодировки хуже, чем любительские. Например, он хотел класс (Foo), который мог бы заполнить объект другого класса (Bar). Он решил, что Фу будет содержать ссылку на Бар, например:
class Foo {
public:
Foo(Bar& bar) : m_bar(bar) {}
private:
Bar& m_bar;
};
Но (по другим причинам) он также нуждался в конструкторе по умолчанию для Foo и вместо того, чтобы ставить под сомнение его первоначальный дизайн, он написал этот гем:
Foo::Foo() : m_bar(*(new Bar)) {}
Таким образом, каждый раз, когда вызывается конструктор по умолчанию, Bar пропускается. Что еще хуже, Foo выделяет память из кучи для 2 других объектов, но он не написал деструктор или конструктор копирования. Таким образом, каждое выделение Foo на самом деле пропускает 3 разных объекта, и вы можете представить, что произошло, когда Foo был скопирован. И - это только поправляется - он повторил ту же самую модель в трех других классах, так что это не одноразовый промах. Вся концепция неверна на многих уровнях.
Я бы почувствовал больше понимания, если бы это было от новичка. Но этот парень занимается этим уже много лет, и за последние несколько месяцев он уделял много внимания обучению и советам. Я понимаю, что большую часть времени он работал без наставничества или экспертных оценок, но начинаю чувствовать, что он не может измениться. Итак, мой вопрос: вы бы не отказались от того, кто пишет такой явно плохой код?