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

Ответ 1

По-моему, кто-то, кто делает такие глупые вещи, как вы описали выше, не может быть звездным разработчиком! Мне кажется, что он намеренно делает вещи более сложными, как они есть, так что никто, кроме него, не может поддерживать код. Это делает его более важным, чем он есть на самом деле! Говорить с ним. Он должен изменить это! Если он этого не сделает, замените его настоящим звездным разработчиком!

Я обещаю, что даже через полгода он не будет знать, как работает его собственный код! Огоньте его, и вы можете сэкономить много времени и денег.

Ответ 2

Часть CVS проста - "случайный" сбой жесткого диска научит его урок на всю жизнь (убедитесь, что у вас есть резервная копия, поэтому вы фактически не потеряете код)

Ответ 3

Это звучит как сложная ситуация.

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

Ответ 4

Невозможность документа - это (очень плохой) способ обеспечения безопасности работы.

Вы можете сделать несколько действий, чтобы встретить это:

• добавьте документацию в качестве требования к обзору личной эффективности.
• не принимают программное обеспечение, которое не документировано.
• поговорите с разработчиком и узнайте, почему он не документирует.
• Купите классный инструмент для документации.

Ответ 5

Воспроизведите эскиз bad cop/good cop, который вы видели из фильмов. Пусть менеджмент будет плохим полицейским, и вы будете хорошим полицейским. Позвольте руководству запросить документацию с избыточным количеством убийств и мгновенные резервные копии ZIP его работы. Но вы предлагаете ему умеренную документацию (например, с помощью doxygen) и обычные проверки контроля над версиями...

Ответ 6

Поговорите с ним?

Если он действительно "звездный разработчик", он примет к сведению то, что вы говорите.

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

Edit:

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

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

Ответ 7

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

Ответ 8

Вы можете сосредоточиться на неправильном месте здесь, вам предоставляется возможность увидеть некоторые недостатки в вашем процессе.

• работает в своей небольшой области своего домашнего каталога, а не в общем репозитории CVS.

Простой чат, вероятно, будет достаточно здесь, преимущества управления версиями говорят сами за себя, и любой "яркий" человек, скорее всего, будет в восторге от этих преимуществ. Однако это также может быть хорошим шансом взглянуть на альтернативные системы контроля версий, которые обеспечивают большую простоту использования и гибкость (посмотрите на bzr и git). Еще лучше, вовлечь его в процесс отбора, если он действительно "звезда", он, вероятно, будет иметь хороший вклад и больше надеяться на его использование.

• не документирует его код

Не похоже, что документация является частью вашего процесса. Люди будут сопротивляться выполнению дополнительной работы, и если нет определенного процесса, тогда вы говорите о большой дополнительной работе. Необходима ли документация? Если да, существует ли процесс для его создания? если у вас есть кто-то целиком посвященный этому? Если у вас есть хотя бы инструмент для его облегчения (возможно, что-то простое, как mediawiki)?

• не комментирует свой код, например. 3500 SLOC of C без комментариев и без пустых строк, чтобы окутать вещи.

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

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

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

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

Ответ 9

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

Ответ 10

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

Ответ 11

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

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

Документация - это широкий и сложный вопрос. Я стараюсь следовать за СУХОЙ (не повторяю) максиму. Документация, которая отделена от кода, может означать повторение себя, поэтому она может устареть, если вы не замедляете ее, чтобы поддерживать ее в актуальном состоянии. Мой обычный подход - коснуться его потом.

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

В любом случае, я думаю, что это отличный вопрос, и ответ совсем не прост.

Ответ 12

Действительно ли парень рок-звезда? Шутки в сторону? Подумайте об этом на секунду. Является ли он умным, но не делает ничего, или он умный и способный сделать что-то?

Подумайте об этом очень сложно.

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

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

Ответ 13

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

Ответ 14

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

Я боюсь, что вы потеряете хорошего разработчика.

Ответ 15

"Приветственный разработчик,

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

С этого момента вы просто справляетесь с этой неудачей так же, как и с тем, что не успеваете вовремя, не можете прекратить работу во время работы и т.д. Итог: если босс говорит документ, вы документируете или вы не выполняете свою работу должным образом.

Ответ 16

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

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

Ответ 17

Очень маловероятно, что руководство избавится от него, если он действительно яркий.

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

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

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

Что он хочет изменить? Он может сказать руководству: "Хорошо, люди, все так же, как вы меня спрашивали: зарегистрировались, задокументированы и под вашим контролем. Я покончил с собой, я упаковываю и ухожу".

Ответ 18

Документация по коду устарела. Обучение CVS очень просто.

Хороший класс должен раскрывать свою цель с помощью своих методов и свойств.

Документирование модели за пределами приложения также легче протекать и понимать.

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

Изменить: Oops - используется CSV вместо CVS, для многих импорта, и я использую svn heh.

Ответ 19

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

Ответ 20

+1 к ocdecio - если он звездный разработчик, то его код должен основываться на таком высококачественном дизайне, который сам документирует.

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

Наличие доступного "гуру" может быть абсолютной спасательной способностью - или, по крайней мере, это было раньше, или StackOverflow сделал эту роль избыточной?

Ответ 21

Не позволяйте выпуску кода до тех пор, пока он не пройдет проверку кода и не разрешит его пропускать, если есть достаточно комментариев и/или документации для кода, который он написал для текущей функции/проекта.

Изменить Подведите итог в своей оценке. Код документации/комментариев может быть предоставлен ему за его "Области совершенствования".

: -)

Ответ 22

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

То есть, если вы можете убедить его зарегистрироваться в первую очередь! (Что является ОСНОВНЫМ, imo)

Ответ 23

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

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

• Является ли его код понятным, несмотря на отсутствие комментариев?
• Использует ли ваша команда какое-либо отслеживание проблем (например, FogBugz, Bugzilla и т.д.), в котором он участвует?
• Проверяется ли его код?
• Есть ли кто-нибудь еще в команде, который на самом деле хотя бы немного знаком с тем, как работает его код?
• Готовы ли он хотя бы признать, что он может внести некоторые изменения в то, как он работает с остальной командой?

Если ответ на все эти вопросы "нет", у вас есть большая проблема. Просто умение не обязательно делает кого-то активом. У вас есть гарантия, что он не покинет вашу компанию завтра или попадет в автобус? Как бы вы были, если бы это случилось? Стоит ли рисковать?

Ответ 24

Я думаю, что это довольно типично в любой среде. Как вы заставляете кого-то делать то, что хотите? Это именно то, что "Как завоевать друзей и влиять на людей". Дейл Карнеги не был о манипуляции, а управлял людьми.

Мне кажется, что он просто неопытен и нуждается в каком-то опыте и руководстве.

Как вы думаете, вы можете сесть и поговорить с ним об этих проблемах? Говорить кому-то, что они делают что-то неправильно, часто кажется неправильным (особенно в современном западном обществе, где мы не хотим причинять вред чужим чувствам), но я думаю, что вы можете очень далеко, спокойно и честно объясняя проблемы и разговаривая с ними. Это помогает, если человек уважает вас и ваше мнение, что является совершенно другой проблемой, о чем говорится в упомянутой выше книге. Удостоверьтесь, что он понимает, что это серьезные проблемы. Кроме того, что в любых будущих заданиях на развитие он должен будет делать это тоже, поэтому неплохо практиковать их сейчас.

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

Ответ 25

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

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

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

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

Ответ 26

• Попросите его использовать автоматические инструменты проверки выполнения. (См. Мой ответ на Как задать вопросы обструкционисту?")

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

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

  /li >

• Используйте код статического анализа, чтобы понять и очистить его код.

Ответ 27

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

Ответ 28

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

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

Если бы у вас были регулярные обзоры кода с этим парнем, я думаю, вы увидите, что он не такой звездный разработчик, как вы думаете.

Ответ 29

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

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

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

Ответ 30

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

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

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

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