От джуна до сеньора

Тезисы

■ В ходе код-ревью не обороняйтесь и не нападайте, это не битва.

■ Уделите время код-ревью.

■ Абстрагируйтесь от кода и стиля, сосредоточившись на логике написанного.

■ Воспринимайте рекомендации как добрый совет, не ищите в них упрека.

Задание

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

История из жизни

Как-то раз я проводил код-ревью начинающего разработчика и делал это по большей части автоматически – комментировал, писал, почему так не стоит делать и как сделать лучше; словом, это было самое обычное ревью, по крайней мере для меня. Через некоторое время мне передали, что разработчик, чей код я проверял, работает через силу, подавлен, сомневается даже в простых решениях, которые пишет. Я решил поговорить с ним, узнать, что случилось, нет ли каких-то личных причин, которые он хотел бы обсудить. Выяснилось, что мое код-ревью было обычным только для меня, а разработчик воспринял его как отповедь, как прямую критику в свой адрес. Я извинился и попытался объяснить, что ничего из того, что я говорил, не может и не должно восприниматься как упрек или сомнения в его профессионализме: это всего лишь комментарии, которые должны подготовить код к тому, чтобы он стал частью проекта. Мы хорошо поговорили в тот день и достаточно долго поддерживали дружеские отношения, иногда вспоминая эту историю.

Методологии разработки

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

Когда-то разработка программного обеспечения была узкоспециализированной необходимостью. Научной, математической, интеллектуальной. Развиваясь, разработка стала требовать большего, чем просто умение создавать программы и вычислять результаты. Итеративность процесса разработки, необходимость предсказуемости результата, формирование четкой структуры и фаз разработки требовали создания чего-то нового. Алгоритма по созданию программного обеспечения. Методологии.

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

Насколько методология разработки, предпочитаемая в компании, повлияет на вас как на разработчика? Это зависит от вас.

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