Что сделать со звездообразными разработчиками, которые не документируют их работу? [закрытый]

В то время как отдельный успех может быть важным и полезным в некоторых случаях, это - работа в команде и хорошее сотрудничество среди всех игроков и заинтересованных сторон, что в конечном счете сделает большинство проектов успешным.

Документация является частью процесса сотрудничества. Если Ваш "звездообразный разработчик" не помещает свой вес на эту тему, затем сообщают ему и помещают его в его обзор.

Документируют проблемы, которые Ваш "звездообразный разработчик" вызвал из-за его отсутствия документации. Изложите доводы этой проблемы к верхнему управлению с примерами этих проблем и удостоверьтесь, что он понимает последствия. Если он продолжает перестать работать в этом аспекте, затем рассматривают его как любой другой отказ... завершение, являющееся последним курсом.

, Прежде всего, делают его знающий о проблеме и дают ему шанс улучшиться. , если Вы не видите улучшения за согласованный промежуток времени, затем он не готов улучшить himeself и команду. Вы знаете то, что должно быть сделано!

Удачи! Andres

Не будет? При попытке всего остального могло бы быть пора напомнить ему, кто подписывает его paycheque.

Серьезно!

звездообразный разработчик А бесполезен Вам 5 лет в будущем после того, как он был поражен шиной, и кто-то еще должен работать над его кодом.

не использует CVS? В компании я работал в, мы сделали штрафы для того, чтобы не зарегистрироваться, три штрафа, и Вы были уволены. Ваш исходный код является Вашим бизнесом, Вы теряете свой исходный код, Вы теряете бизнес. Снова, я напомнил бы этому парню, что его paycheque зависит от следующих стандартов компании.

Вы не можете уничтожить людей для того, чтобы не сделать то, что Вы предложили там. Он просто отличается.

if(developer.IsHuman())
{
    developer.IsUnique = true;
}

я работаю с людьми, которые пишут мусор (и называют его кодом). Я делаю это также. Иногда. Но, поскольку Вы уже чувствуете, его раздражение для не изменения дурных привычек, когда Вы знаете, что Ваша работа влияет на других. Попытайтесь убедить его больше.

И, я не думаю, что можно сделать много в этой ситуации, если Вы не" менеджер ".

часто сверхусложняет вещи, например, использует три сценария оболочки, которые называют друг друга, чтобы сделать работу, которую мог сделать один простой сценарий оболочки.

Это не кажется, что он точно пишет грамотный сам документирующий код мне, скорее противоположное. Кажется, что его выбор чрезмерно сложных решений создает необычно большой потребность для документации и также создания отсутствия документации намного более серьезная проблема.

Я думаю, что члены команды должны понять обязанности друг друга, т.е. это - обязанность DBA работать с DB, Вы не просите, чтобы QA применил патч DB. И DBA не может отказаться делать это, потому что это - его ответственность. Всем должно быть ясно, что одна из обязанностей члена команды является написанием кода, которое может быть понятно другим членам команды. И я думаю с той точки зрения, она должна быть разрешена от человека, которому он сообщает.

, Если Ваш DBA не работает с DB и вместо этого делает что-то еще, как создание UI, он не делает своего задания. То же с Вашим коллегой - если он производит код, который не может быть понят под другими членами команды - он не делает своего задания.

Написание кода, которое не может быть понято под его коллегами, нельзя рассмотреть как выполнение задачи. Написание кода, который не находится в CVS так, не может быть рассмотрено другими членами команды, пока не слишком поздно - также не должен быть рассмотрен как выполнение задачи. Запись 3 сценариев вместо 1 нужно считать пустой тратой времени.

, Если управление не может понять, что и все еще рассматривают его, программист рок-звезды - рассматривает изменение управления.

я также подчеркнул бы, что цель не пишет, комментирует себя. Это должен быть понятный код, легкий поддержать. Я лично полагаю, что комментарии как последнее средство делают мой код понятным - я предпочитаю чистый дизайн и именование сначала.

Отдайте его код ему и скажите ему фиксировать его, или он уволен.

Обзор кода сбоя.

Вот другой такт, который Вы могли попробовать, в дополнение ко многим из других предложений:

кажется, что Вы предрасположены, чтобы думать, что поведение и методы Вашего разработчика плохи по любой причине. Принятие Вас обсудило их с ним, и он не предоставил выравнивание Вашей удовлетворенности (или готовность измениться), я сказал бы, что у Вас есть два очевидного выбора: избавьтесь от него, или живой с ним. Я предположил бы, что в этом случае Вы очень искренны со своими требованиями того, как он пишет свой код и позволил ему выбрать к как хотите.

Как пример, у меня был предыдущий работодатель, который (после встряски управления) решил, что разработчикам больше не разрешали использовать, 'утверждают' в коде, потому что они считали это ненужной помехой и не согласовывающиеся с существующим стилем теперь "ответственного" группа (кто написал очень прямой низкоуровневый C код стиля без утверждений или методов безопасного программирования). У управления и меня было прямое обсуждение, они сказали мне, что я должен был адаптироваться к их стилю или отпуску, и я решил уехать. В целом, я думаю, что это удалось лучше всего для обеих сторон.

Не все собираются иметь те же мнения о кодировании, инструкциях по коду или процессах разработки, и в конце дня, человек, платящий деньги, делает правила (сбалансированными относительно потребности на самом деле произвести вещи). Чем более искренны Вы о том, чего Вы требуете, тем менее обиженные разработчики будут.

Может быть причина, по которой он «знает свое дело», в том, что это именно то - «его материал». Лучший код - это код, который другие программисты могут с уверенностью понять и изменить.

Впечатляющие программисты, которые не наставляют других и пишут код, который понимают только они, являются ИМХО обузой - особенно после того, как они ответили на достаточно вопросов, чтобы вы знали, как переписать их код, и могли отправить их, чтобы помочь кому-то другому.