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

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

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

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

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

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

А хороший класс должен показать свою цель через его методы и свойства.

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

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

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

1. Заставляют его использовать автоматизированные инструменты проверки выполнения. (См. мой ответ в" , Как задать вопросы obsructionist? ")

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Он уехал приблизительно 2 1/2 года назад, и это все еще преследует нас, когда мы находим часть его старого кода, и в его защите это - то, как магазин разработки здесь был выполнен тогда, за прошлые 3 года я был на крестовом походе для изменения того менталитета.

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

1. Запись изящный, удобный в сопровождении, гибкий, читаемый код
2. Работа с остальной частью команды: с помощью управления исходным кодом, личного примера, и т.д.
3. Документирование, что каждый метод, класс, объект, и т.д. делает
4. Исследующие новые и лучшие способы сделать вещи для себя и Вашу команду

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

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

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

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

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

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

Это - то, если можно убедить его к регистрации во-первых! (Который ВАЖЕН, imo)

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

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

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

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

Отказ зарегистрировать является (очень плохим) способом гарантировать обеспеченность работой.

можно сделать несколько вещей противостоять этому:

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

Это походит на жесткую ситуацию.

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

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

Говорите с ним?

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

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

Редактирование:

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

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

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

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

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

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

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

• не комментирует его код, например, 3,500 SLOC C без комментариев и никаких пустых строк для клевания вещей

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

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

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

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

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

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

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

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

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

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

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

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

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

Думают об этом действительно трудно.

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

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

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

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

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

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

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

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

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

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

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

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

Никакое управление не уволит хорошего программиста только для найма плохого.

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

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

Команда может быть успешной с ним? Раз так продвиньте проблему и откажитесь принимать любой код, что isn’t, правильно зарегистрированные или doesn’t, соответствуют другим стандартам. Надо надеяться, это поймет через, но это могло бы просто сделать его сердитым и заставить его выходить. Если команды can’t успешны с ним затем you’re не повезло, пока Вы не можете обучить замену до его уровня квалификации, который не может стоить времени и усилия.

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

Редактирование Поднимают его в его оценке. Документация / комментирующий код может быть дана ему для его "областей улучшения".

:-)