Действительно ли один программист должен зарегистрировать чей-либо код?

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

Но вашим старшим разработчикам все равно придется читать и проверять правильность комментариев или это пустая трата времени.

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

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

Похоже, это просто умный способ уйти от наставничества. Осталась пара проблем:

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

Наверное, не такая уж и хорошая идея. По ряду причин:

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

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

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

• Код должен быть «самодокументированным». Такие вещи, как Javadoc и т. Д., В последние годы вышли из моды, потому что они не добавляют ценности (они всегда устарели и т. Д.). Гораздо разумнее тратить время на реструктуризацию кода, чтобы его было легче понять.

• Я не верю аргументу «более продуктивный». Если у вас есть 5 пожилых людей, идущих на полной скорости, а 5 младших занимаются зачисткой позади них, у вас есть только 5 разработчиков, создающих код. Если у вас 10 разработчиков, работающих на 2/3 скорости, у вас будет большая общая емкость (~ 6 разработчиков на полной скорости).

Чтобы ответить на вопрос заголовка,

Если один программист документирует код другого

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

Мне все равно, кто это написал.

Ого !! Неужели я единственный, кто думает, что время документировать код - до того, как вы начнете стучать по клавишам?

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

Есть ли у вас процессы? SQA?

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

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

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

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

Я не достаточно умен, чтобы написать свой собственный ответ, поэтому я процитирую людей умнее меня:

Джоэл сказал:

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

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

Егге сказал :

Студент UW, с которым я только что проходил собеседование, сказал мне, что его друг проходил стажировку в Intel этим летом, и ненавидел ее настолько, что отказался от довольно выгодного предложения от них на полный рабочий день. Друг сказал, что он убежден, что один из сотрудников Intel написал сценарий для фильма "Офисное пространство". Мало того, что у людей там есть 5 или 6 боссов, которым нужно отчитываться, что достаточно плохо, у них на самом деле есть отчеты TPS, и каждый должен их делать. А когда они меняют формат титульного листа, выходит памятка, оповещающая всех.

Хотя это, наверное, один из самых сюрреалистичных стажировок, о которых я слышал, стажировка в ужасах - довольно распространенное явление. И это не так, как если бы стажер никому не рассказывал в школе. Слухи быстро распространяются. Многие компании фактически занесли себя в черный список крупных университетов. Студент из UW, который рассказал мне эту историю, говорит, что теперь никто в отделе CS не заинтересован в работе в Intel. Intel все еще набирает сотрудников, как сумасшедшие в университетском городке, но они фактически закрыли трубопровод.

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

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

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

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