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

https://stackoverflow.com/questions/532338

collaboration

22-08-2019
|

Вопрос

Есть коллега, который серьезно знает свое дело, он один из самых умных, с кем я когда-либо работал, но он:

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

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

Есть предложения, что делать?

Кстати, руководство знает о ситуации и пытается ее изменить.

Решение

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

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

Другие советы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

не документирует свой код

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

«Привет, звездный разработчик!

просто небольшое неофициальное предупреждение, чтобы сообщить вам, что со следующей недели мы будем требовать документацию кода и полезные комментарии в коде — это будет политика компании, и исключений не будет».

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

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

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

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

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

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

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

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

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

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

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

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

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

Редактировать Упомяните это в его оценке.Код документации/комментирования может быть предоставлен ему для его «Областей улучшения».

:-)

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

Это если вы вообще сможете убедить его зарегистрироваться!(что ВАЖНО, имхо)

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

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

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

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

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

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

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

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

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

Хороший класс должен раскрывать свое предназначение через методы и свойства.

Документирование модели вне приложения также проще для понимания.

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

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

Заставьте его использовать автоматизированные инструменты проверки исполнения.(Смотрите мой ответ в разделе «Как задавать вопросы обструкционисту?")
Если он слишком усложняет и не использует SCC, он нет отличный разработчик — эти вещи являются важной частью разработки программного обеспечения.
В очень маловероятном случае, если он обладает незаменимыми талантами в таких областях, как алгоритмы, поручите ему работу в этой области, например, определение алгоритмов, и попросите настоящего программиста заняться кодированием.
Используйте код статического анализа, чтобы понять и очистить его код.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow