♬ Послушай эту историю или прочти

Я был профессиональным разработчиком iOS почти 5 лет и могу честно сказать, что нашел свою страсть. Одна из моих любимых составляющих в работе разработчика программного обеспечения - это то, что нам нужно сохранять непредвзятость и постоянно учиться.

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

После учебы я переехал в Германию и начал работать на полную ставку разработчиком iOS. Здесь команда была больше, у нее были процессы, стандарты, сильное внимание уделялось созданию качественного программного обеспечения. Я нашел это увлекательным.

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

Почему я считаю, что обзоры кода - это здорово:

Вы понимаете ценность конструктивной критики

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

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

Это одно отношение, которое нужно преодолеть каждому из вас, товарищам по команде. Не принимать критику на свой счет, а как совет о том, как стать лучше и постоянно совершенствоваться.

Я долго привык к комментариям. Иногда я доходил до конца статьи, и в комментариях говорилось: «Почему вы это сделали?» "Насколько это гибко?" «Можете ли вы нарисовать схему своего решения?»

Представьте, что вам нужно начать все сначала 😫. Выбросьте дни или неделю работы.

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

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

Через некоторое время вы тоже начинаете бросать вызов себе. Но это не всегда работает ... Иногда вы устали или просто ленивы и можете решить пойти по более короткому пути ... Возможно, вы решите вообще пропустить сложную часть.

Вот почему так важно работать в команде, которая сосредоточена на извлечении максимума из всего, каждой функции, каждой строчки кода.

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

Развивайте в своей команде культуру конструктивной критики и цените ее больше всего. Это принесет наибольшую пользу

Это помогает распространять знания внутри команды

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

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

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

Вы можете оглянуться на свой код и спросить: «Какого хрена ???»

Возможно, это моя любимая часть. Когда вы открываете более старый проект, который вы написали, и не можете узнать себя. Это величайшее доказательство роста! Приятно осознавать, что вы добились такого большого прогресса, что даже не узнаете себя в том, что раньше писали.

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

Это ступенька к стандартам всей команды

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

Определить стандарты непросто. Вначале вы даже не знаете, что вам следует стандартизировать. Ревью кода может стать основой для этого, поскольку это способ сообщить различные мнения внутри команды.

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

На выходе будет единая высококачественная кодовая база

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

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

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

Вы можете учиться у товарищей по команде

Вы все в одной команде, потому что вы все классные. Что еще лучше, так это то, что вы можете дополнять друг друга.

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

Что мы отдаем?

В большинстве случаев идеального решения не существует.

Итак, чем нам нужно пожертвовать ради всех этих преимуществ?

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

Вы видите преимущества?

Если все это сбалансировано и сделано правильно, эта практика действительно поможет вам сэкономить время и деньги на ошибках и техническом долге.

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

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

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

Спасибо, что нашли время прочитать это. Надеюсь, вам понравилось это так же, как мне нравится ревью кода :). Сообщите мне, что вы думаете об этом, и не стесняйтесь обращаться к нам

Если вы хотите получить персональный коучинг для улучшения ваших навыков разработки под iOS и получить от меня информацию по вашим наиболее насущным вопросам, связанным с iOS, в настоящее время я открыт для обучения других разработчиков. Если вам интересно, просто свяжитесь с нами. Подробнее здесь: https://mobiledev.consulting/1x1-expert-coaching/

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