Пока объясняешь своё решение
Вопрос начинающего разработчика может заставить наставника проверить привычный приём. Сам пользуешься им давно, а объяснить, почему он подходит именно к этому коду, оказывается трудно. Тогда становится видно, где можешь обосновать свой выбор, а где пока опираешься на привычку.
Например, совет вынести часть кода в отдельную функцию хочется объяснить просто: «Так понятнее». Но автор кода и сейчас хорошо в нём ориентируется. Чтобы объяснение ему помогло, придётся уточнить, что изменится: у части кода появится имя, исчезнет повторение или будут разделены действия, которые меняются независимо. Каждое из этих соображений нужно проверить на коде, который перед нами.
Допустим, функция выводит список статей блога. Внутри неё ещё и формируется подпись даты. Если вынести эту часть в formatDate, в основном коде станет видно, где берётся готовая подпись. Подробности форматирования можно будет прочитать отдельно. Изменение помогло, если по основному коду теперь легче проследить, как собирается список.
Но одного нового имени недостаточно. Если мы назвали функцию prepare и для понимания следующей строки всё равно приходится открывать её тело, чтение могло стать только неудобнее. У ученика есть основание спросить, что мы улучшили. И наставнику придётся ответить точнее, чем «функция стала короче».
Иногда убедительного объяснения пока нет. Мы привыкли делать именно так, когда-то увидели похожий приём и с тех пор повторяем. Это ещё не означает, что решение плохое. Но теперь понятно, в чём стоит разобраться самому: при каких условиях этот приём помогает, а когда добавляет лишний переход между частями кода.
В докладе «Искусство обучать» я говорил о пользе наставничества для самих наставников. В HTML Academy с учениками работают практикующие разработчики. Объясняя решения, они заодно приводят в порядок собственные знания. Меня здесь интересует момент, когда знакомая вещь перестаёт быть само собой разумеющейся.
Разбор двух вариантов кода даёт больше, чем правило «длинные функции нужно разбивать». По одному правилу всё равно придётся угадывать, какая функция уже длинная. Сравнивая варианты, мы смотрим, что было трудно понять и удалось ли это исправить. Ученик может рассуждать вместе с нами, а в следующей задаче проверить похожий выбор сам.
От наставника требуется готовность задержаться на вопросе. Ответ «так принято» позволяет продолжить проверку задания, но ничего не объясняет. Иногда приходится открыть документацию или собрать другой пример. Можно признать, что сейчас не получается ответить точно, и вернуться после проверки. По-моему, это полезнее, чем уверенно повторять объяснение, в котором сам начал сомневаться.
Я не жду, что каждый разговор с новичком принесёт опытному разработчику открытие. Часть вопросов знакомая, часть времени уйдёт на повторение, и помощь уже оправдывает эту работу. Но иногда вопрос, на который собирался ответить за минуту, обнаруживает вещь, которую давно пора было разобрать. Тогда к следующей встрече готовится и наставник.