От джуна до сеньора: Как стать востребованным разработчиком - Владимир Швец
Шрифт:
Интервал:
Закладка:
История из жизни
Ощущение, будто я и правда могу создать что-то идеальное, никуда полностью не уходит, но мои ожидания становятся реалистичнее. Само словосочетание «идеальный код» теряет свою магическую недостижимость и означает вполне конкретные критерии, которыми я буду доволен, когда достигну их выполнения. Ощущаю ли я, начиная новый проект, что хочу создать идеальный продукт? Разумеется, да. Просто теперь «идеальный» для меня звучит как «надежный», «удобный для пользователей», «расширяемый» и «продуманный». На такие идеальные качества я вполне могу ориентироваться без того, чтобы усложнять бесконечным перфекционизмом и без того сложную работу.
Код-ревью
Качественный способ улучшить код, найти ошибки на ранней стадии, ознакомить членов команды с компонентами системы, с которыми они раньше не работали, – прекрасно. Возможность разобрать по косточкам код коллеги, которого вы недолюбливаете, чтобы найти ошибку, – бесценно. Шучу. Не обижайте коллег, вам с ними делать релизы.
Код-ревью – это прекрасная практика, которая помогает держать код проекта в чистоте и порядке, придерживаться изначально задуманной архитектуры, находить ошибки, давать подсказки новым разработчикам и т. д. Описывать прелести код-ревью можно долго, а еще проще найти об этом сотню статей.
В этой теме я не буду подчеркивать достоинства ревью кода. Просмотр кода полезен, и если в вашей компании его практикуют – прекрасно.
Код-ревью вовлекает разработчиков в диалог, в ходе которого один из них должен занимать оборонительную позицию. Может быть, и существуют идеальные команды, где каждый разработчик уважает своих коллег и то, как они пишут код, но давайте будем реалистами.
Формальные правила код-ревью предполагают, что написанный для проверки код должен соответствовать правилам проекта, которые нельзя проверить автоматизированно. Иными словами, код-ревью подразумевает проверку логики работы написанного кода, целесообразность использования механизмов, алгоритмов и компонентов.
Код-ревью поможет понять, соответствует ли код архитектуре и смыслу проекта, не используются ли средства, которые не принято использовать на проекте, и многое-многое другое. Отчасти с такой проверкой могут справиться тесты, но чаще всего тесты пишутся тем же разработчиком, что и код, попавший на ревью, а следовательно, они неспособны выявить все потенциальные проблемы.
Код-ревью требует времени. Нередко это раздражает, потому что не во всякой компании на ревью выделяется отдельное время и часто код-ревью требуется совмещать с работой над задачами. Просмотр кода не просто предполагает беглое ознакомление с написанным, но требует понимания поставленных задач и логики работы кода. В случае если мы говорим о ревью добавленной кнопки с одним действием, все кажется не таким сложным. Но если вы смотрите на код нового компонента аудита действия пользователей системы – да поможет вам Вселенная.
Код-ревью требует опыта и отстраненности. Умение донести свою позицию, не перегибая палку и не пытаясь переделать чужой код в свой, требует большого опыта. С годами у разработчиков вырабатывается свой стиль, свое видение кода. Да, мы используем один и тот же язык с одинаковыми правилами синтаксиса и выполнения, и тем не менее у каждого разработчика есть личный подход. Это может быть свой метод именования переменных, своя логика при работе с массивами, свой способ контролировать ошибки и исключения – все что угодно.
А теперь сосредоточьтесь. Не позволяйте своим привычкам проникать в код-ревью. Вы НЕ делаете код лучше, когда просите другого разработчика переименовать переменную. Вы НЕ делаете код лучше, когда просите заменить for на while просто потому, что привыкли обходить циклы так. Более того, даже если ваш подход обеспечивает мизерную оптимизацию на конкретной версии вашего компилятора, придержите эту ценную информацию при себе.
Ревью кода – это не схватка идеальных машин, это способ держать проект в балансе между разными людьми, у каждого из которых есть на него уникальный взгляд.
Код-ревью потребует от вас крепких нервов. Да, возможно, вы ветеран многих холиваров и закалены в интернет-дуэлях. Но скорее всего (особенно если вы начинающий), вы нервничаете каждый раз, когда ваш код отправляется на ревью старшим разработчикам. Это нормально. Хорошо сомневаться в своем коде, отлично, если вы хотите, чтобы он был лучше.
Проходя код-ревью, постарайтесь забыть, что этот код ваш, и объективно воспринять комментарии, которые вам напишут. Представьте, что сами присутствуете на этом код-ревью, а код принадлежит другому человеку. Хорошим советам и замечаниям стоит только радоваться: код станет только лучше.
Относитесь к код-ревью как к полезному инструменту, как к плагину для вашей среды разработки. Смогли бы вы прожить без него? Да. Но если что-то может сделать ваш вклад в проект более качественным, почему бы не воспользоваться такой возможностью?
Тезисы
■ В ходе код-ревью не обороняйтесь и не нападайте, это не битва.
■ Уделите время код-ревью.
■ Абстрагируйтесь от кода и стиля, сосредоточившись на логике написанного.
■ Воспринимайте рекомендации как добрый совет, не ищите в них упрека.
Задание
Попробуйте найти в системе контроля версий вашего проекта задачу, которую вы делали какое-то время назад и уже успели забыть. Возьмите ее на ревью. Оцените свежим взглядом собственные решения, выбор механизмов и подходов. Проверьте, соответствует ли ваш код архитектуре проекта. Достаточно ли много общего он имеет с похожими компонентами в системе? Какие рекомендации по его улучшению вы бы дали, руководствуясь своими знаниями на сегодняшний день?
История из жизни
Как-то раз я проводил код-ревью начинающего разработчика и делал это по большей части автоматически – комментировал, писал, почему так не стоит делать и как сделать лучше; словом, это было самое обычное ревью, по крайней мере для меня. Через некоторое время мне передали, что разработчик, чей код я проверял, работает через силу, подавлен, сомневается даже в простых решениях, которые пишет. Я решил поговорить с ним, узнать, что случилось, нет ли каких-то личных причин, которые он хотел бы обсудить. Выяснилось, что мое код-ревью было обычным только для меня, а разработчик воспринял его как отповедь, как прямую критику в свой адрес. Я извинился и попытался объяснить, что ничего из того, что я говорил, не может и не должно восприниматься как упрек или сомнения в его профессионализме: это всего лишь комментарии, которые должны подготовить код к тому, чтобы он стал частью проекта. Мы хорошо поговорили в тот день и достаточно долго поддерживали дружеские отношения, иногда вспоминая эту историю.
Методологии разработки
Тема, занимающая умы тысяч продакт-менеджеров. Тема, заставляющая директоров компаний потирать руки в ожидании невероятной продуктивности сотрудников. Тема, обязывающая разработчиков готовить доклады о том, как прошла их рабочая неделя.
Когда-то разработка программного обеспечения была узкоспециализированной необходимостью. Научной, математической, интеллектуальной. Развиваясь, разработка стала требовать большего, чем просто умение создавать программы и вычислять результаты. Итеративность процесса разработки, необходимость предсказуемости результата, формирование четкой структуры и фаз разработки требовали создания чего-то нового. Алгоритма по созданию программного обеспечения. Методологии.
Мы не будем погружаться в пересказ всех доступных (и уже покойных) методологий разработки. Если вам действительно этого захочется, можете найти их самостоятельно. Методологии позволяют структурировать процесс разработки программного обеспечения, составлять формальные правила по оценке задач, регламентировать обсуждения и планирование, оценивать эффективность людей и команд внутри компании.
Насколько методология разработки, предпочитаемая в компании, повлияет на вас как на разработчика? Это зависит от вас.
Для кого-то сам набор правил и регламентов позволяет чувствовать себя безопаснее и предсказуемее (многие разработчики любят структурированность не только в своем коде, но и в жизни).
Кому-то выбранная методология разработки будет отравлять жизнь необходимостью совершения рутинных действий, присутствия на пустых и обременительных обсуждениях и т. д.
На ком-то наличие методологии не скажется никак. Совсем.
Говоря о методологиях разработки, с большой долей уверенности можно
