Должен ли один программист документировать код другого?

Question

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

Их аргументы:

1. У вас будет два программиста, знакомых со всем.
2. Это парное программирование, вроде.
3. Это более рентабельно = они сделают больше.
4. Это демонстрирует, что их код читабелен и доступен для обслуживания.
5. Они будут рады ответить на любые вопросы; так что это форма наставничества.

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

Это хорошая идея?

---

Вау! Это так не наш опыт!

Вот некоторые пояснения, которые оказываются важными.

1. Старшие разработчики - рефлексивные самодокументирующие. Это основной вопрос найма. Иногда им нужно сказать «оставь это младшему парню».

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

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

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

5. Разве ваши старшие люди не хотят объяснить их код?

6. Мы твердо привержены принципу Agile «каждый владеет кодом». Мы думаем, что это ускоряет процесс.

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

Может быть, мы отфильтруем несколько младших кандидатов, потому что проясним, что именно так мы и работаем. Но это не проблема оборота. (Но прошло всего 3 месяца.)

Answer 1

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

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