Я задаю этот вопрос программистам 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 был скопирован. И - это только поправляется - он повторил ту же самую модель в трех других классах, так что это не одноразовый промах. Вся концепция неверна на многих уровнях.
Я бы почувствовал больше понимания, если бы это было от новичка. Но этот парень занимается этим уже много лет, и за последние несколько месяцев он уделял много внимания обучению и советам. Я понимаю, что большую часть времени он работал без наставничества или экспертных оценок, но начинаю чувствовать, что он не может измениться. Итак, мой вопрос: вы бы не отказались от того, кто пишет такой явно плохой код?
источник
Ответы:
Я бы посоветовал ему рассказать об этом конкретном примере и посмотреть, что он говорит. Если он отрицает, что с кодом что-то плохое, то, боюсь, мало что можно сделать. Если он признает, что совершил ошибку (даже если он защищает ее), то, по крайней мере, есть место для улучшения. Если вы потратите время и силы на его совершенствование, то вам или старшему программисту нужно будет усадить его и написать код, пока все эти тенденции не сгладятся (будьте готовы посвятить этого человека хотя бы на 1 месяц).
Плохой программист, с которым я обычно работаю, но программист, который не может улучшить, я не могу.
источник
Нет. Я бы уволил любого профессионального разработчика C ++, у которого не было базового понимания управления памятью.
Если это кто-то из Java или C # или что-то еще, я бы дал им немного широты, но это чистая некомпетентность.
источник
Мы не можем ответить на более широкую часть вашего вопроса. А именно, вы должны оставить или уволить этого сотрудника. Уволить сотрудника сложно, но это решение не входит в компетенцию такого сообщества.
Вы обновили свой вопрос, чтобы ограничить ответы программистов на C ++. Для моего фона / квалификации: я порезал зубы на C, и я могу писать на C ++, C # и Java. И мне нравится гоняться за условиями гонки между нитями, потому что я думаю, что это весело. Да, я "получаю" немного вертеться.
Ваш ответ и решение обернуто вокруг этого: кто - то изменения , могут ли зависит от индивидуального и если они хотят перемены.
Но давайте начнем с некоторых ваших вопросов:
Вы должны убедиться, что можете ответить «да» на все эти вопросы. Если нет, то с вашей стороны все еще есть бремя доказательств общения с ним.
Его ответ на ваш недавний обзор будет самым интересным.
Если он пытался и показывает некоторые признаки прогресса, то, возможно, вам нужно пересмотреть процесс наставничества. Во всяком случае, может быть, вам стоит подумать о том, чтобы связать его с более опытным программистом, чтобы он мог получить немедленную обратную связь, пока он принимает дизайнерские решения. Я не фанат парного программирования, но в таком случае это может быть очень полезно. Постоянно отсылать его, чтобы он все больше и больше пересматривал старый код, не всегда является практическим путем для изучения.
Если он не пытался, тогда вам нужно лучше понять его мотивацию. Разве он не понимает, что ему нужно стараться изо всех сил? Ему просто все равно? Есть ли в команде другие области, где его навыки лучше подходят, и он больше интересуется этим? Если он не хотел пытаться, тогда вы должны понять, почему.
Оттуда, вы будете знать , хочет ли он изменить и действительно ли он может измениться. Отсутствие желания изменить эквивалентно неспособности измениться. Если есть желание и степень прогресса, тогда решительно подумайте над тем, чтобы изменить способ его реабилитации.
источник
Боюсь, что его плохой код - не единственная проблема в вашей команде.
Вы говорите, что он был в компании в течение длительного периода времени. Увольнение такого человека редко является хорошей идеей (если только он не сотрудник типа Уолли). Их знание потребностей клиентов, продуктов, которыми вы владеете, и т. Д. Часто гораздо ценнее, чем код, который они пишут.
Решения:
источник
Принятие решения уволить кого-либо является трудным решением для любого. Ваша ситуация, однако, усугубляется несколькими факторами:
Тем не менее, вы потратили последние 6 месяцев на то, чтобы показать разработчику ошибку, которую он сделал, а его новый код еще не улучшился.
На этом этапе вам действительно нужно начать активное управление, чтобы в течение 3 месяцев
или
Чтобы сделать это, хотя вам нужно сесть с разработчиком, объяснить, что не так в написании / электронной почте, объяснить, как разработчик может улучшить, и очень ясно заявить, что если ожидаемое улучшение не материализуется, то он будет прекращен в 3 месяцы.
Вам также необходимо четко понимать, что с этого момента ожидается улучшение в оставшейся части его работы в компании, а не только в течение трех месяцев!
Вам также следует сообщить об этом своему менеджеру и отделу кадров (если есть).
Во время этого процесса вам нужно будет активно управлять разработчиком и проверять задачи / код каждые 1-2 дня, а также проверять, что они в порядке, подробно описывать те, которые отсутствуют, и объяснять, что можно сделать для их улучшения.
источник
Либо у вас не было ясности относительно того, насколько серьезно вы относитесь к его плохому мастерству (то есть, возможно, он видит, какое время вы провели с ним, как вариант, если он хочет улучшить, а не абсолютную необходимость), или у него невероятно плохой отношение это неустойчивое. Если для этого разработчика еще не ясно, что вы рассматриваете его позицию по этому вопросу, то это должно быть прописано (при условии, что ваше руководство в порядке с вашим правом прекратить работу). Надеюсь, шок приведет к переменам.
Решение о трудоустройстве имеет гораздо более широкие последствия, чем просто этот парень, тем не менее, вы должны учитывать влияние на команду. Если его отношение позволено процветать, оно может вызвать либо негодование других, либо заставить других чувствовать, что подобные вещи тоже хороши. Однако с точки зрения команды должно быть абсолютно ясно, что если он все-таки уйдет, это будет по правильным причинам, и у него будет достаточно возможностей для улучшения.
Одна жемчужина, которую я приобрел на курсе много лет назад, - это тот факт, что люди с техническими знаниями, которых нет у других, могут привести руководство к ослаблению. Это плохо для команды. Вы можете бояться потерять единственного разработчика C ++, но их можно заменить. Очевидно, существуют риски, связанные с тем, что он хорошо знает выпущенные продукты, но часто я видел людей, у которых, казалось бы, незаменимые знания о продукте / технических знаниях заменялись легче, чем предполагалось. Команды и организации часто могут заполнить пробелы, которые изначально кажутся трудными для заполнения. Конечно, если он не обладает навыками C ++ или специфическими знаниями организации, которые, по вашему мнению, будет трудно заменить, проблем гораздо меньше!
источник
Конечно, вы не должны. Помните, это не благотворительность, вы обмениваете деньги на работу. Если он не поддержит свою сторону сделки, то, как любая сделка, я перестану платить.
источник
Если вы хотите дать ему шанс, разработайте стандартизированный тест, который собирает показатели утечки памяти. Следите за его прогрессом еженедельно, настаивая на том, чтобы увидеть код, который он изменил, и ищите улучшения. Если он не может справиться в этот момент, снимите с толку бесполезных оскорблений.
источник