Тендеры и лиды
Информация
Разработчики занимаются написанием кода и после реализации задачи привлекают других участников команды к его проверке. Это называется code review. В рамках ревью-кода ставится цель: проверить качество кода на соответствие стандартам компании. Если есть что‑то, что можно улучшить, участники делятся своими знаниями и дают рекомендации.
В процессе работы разработчикам нередко приходится переписывать код и вносить изменения, чтобы все работало без багов. Из-за доработок глаз буквально «замыливается», а анализаторы не всегда эталонно доводят стиль кода до установленных стандартов.
Отсюда необходимость свежего взгляда, способного заметить неудачно написанный метод или класс. Разработчик привлекает коллег и просить прочесть код. Стоит отметить, code review не должен превращаться в формальную процедуру — это своего рода аудит, в рамках которого ставится задача сделать код еще лучше и снизить количество ошибок на ранних этапах разработки. Это в интересах всей команды. Переработки могут дорого обходиться и замедлять сдачу проекта.
Как уже говорилось, code review является процессом обмена опытом, а не массового осуждения и критики. Соответственно, в рамках кода-ревью более опытные коллеги дают рекомендации, выявляются неочевидные ошибки, обосновывают свои решения — растет компетенция как отдельных специалистов, так и команды в целом.
На практике, мотивированные специалисты охотно включаются в code review, особенно, если они занимаются позиции уровня junior и middle.
Само-ревью: проводится, когда в проекте работает только один разработчик. Он самостоятельно повторно проверяет свой код. При само-ревью лучше следовать чек-листу, а также исключить чтение кода по диагонали. Желание сдать работу пораньше и побыстрее вполне понятно, но формальная отписка «approve» может стать причиной краха последующих работ. Стоит задача отловить баги самостоятельно, поэтому лучше чекать строки дробно: например, по 50–100 строк, делая небольшие перерывы между code review.
Ревью через техлида: код проверяет технический лидер проекта. Он проводит глубокий анализ качества, выявляет соответствие кода стандартам разработки, оценивает возможность улучшения кодовой базы и очерчивает потенциальные проблемы. Лидер направления после code review возвращает разработчику задачу: после доработок он повторно выполняет анализ. Ревью через тех-лида наиболее распространенный вид code review.
Перекрёстное ревью: иногда коды проверяют несколько разработчиков друг у друга. Это помогает держать всех участников в курсе контекста проекта и быстрее выявлять ошибки. Может проводиться как оффлайн, так и онлайн. Ошибки могут быть исправлены сразу же, таким образом, ускоряется процесс доработки.
Перед тем, как привлечь коллег или техлида, необходимо провести рефакторинг кода. Суть этой задачи: внесение мелких изменений, каждое из которых не глобально меняет код, но в совокупности улучшает структуру, архитектуру программы и читаемость кодовой системы, упрощает разработку новых функций, устраняет дубли.
Также рефакторинг способствует выявлению и устранению узких мест, что в отдаленной перспективе отражается на скорости работы программы.
До code review разработчики Kokoc.tech проверяют код через git-hooks. Он в автоматическом режиме проверяется стиль, выявляет отступы и базовые ошибки. При таком подходе техлид и команда не тратят время на очевидные недочеты, которые может разработчик скорректировать самостоятельно до code review.
Чтобы было легче погружаться в специфику задачи, наши разработчики заранее анонсируют ключевые моменты, на которые стоят обратить внимание, и расставляют приоритеты.
Ведется работа от общего к частному. То есть, сначала исправляются верхнеуровневые ошибки и недочеты, техлид или разработчики читают код, оценивают его читаемость и логику. Далее дорабатываются уже мелкие детали. Специалисты не просто указывают на ошибку — они объясняют, почему решение неверное, и предлагают альтернативы. Это превращает ревью в обучающий процесс.
В рамках code review ревьюер может проверить функциональность кода, провести тесты — полная свобода действий с учетом поставленных задач и специфики проекта!
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13258 тендеров
проведено за восемь лет работы нашего сайта.
Что важно, обеспечивается прямая и доверительная коммуникация: как ревьюер может задавать вопросы автору, так и автор может вести диалог с командой. Возможен и такой ход событий, при котором разработчик доказывает актуальность своего решения – в этом плане все действуют в интересах проекта, с пониманием воспринимая разные точки зрения. Доказать свою правоту любой ценой — это не про code review.
Простая задача может занять на ревью около 15 минут, более сложная — до часа и более. Тайминг зависит от размера файла и количества строк. Задачи, которые «по коду» кажутся короткими, в итоге требуют больше часов. К тому же стоит понимать, что в процессе code review необходимо делать паузы: проверка требует концентрации, внимания, сосредоточенности. Поэтому нет смысла проверять код более часа без перерывов. Иначе может снижаться качество анализа.
Сколько бы не занял code review, временные затраты оправданы: лучше потратить время на ревью, чем потом исправлять баги, найденные тестировщиками уже на поздних этапах разработки.
В Kokoc Tech выработаны свои алгоритмы и принципы code review:
Код-ревью — это не только контроль, но и инструмент развития специалистов и повышения качества продукта разработки.
Несмотря на временные затраты, ревью окупается за счёт меньшего количества багов и более предсказуемого процесса разработки — выигрывает и вся команда, и в итоге заказчик.
В Kokoc Tech выработаны свои алгоритмы и принципы code review:
Само-ревью: проводится, когда в проекте работает только один разработчик. Он самостоятельно повторно проверяет свой код. При само-ревью лучше следовать чек-листу, а также исключить чтение кода по диагонали. Желание сдать работу пораньше и побыстрее вполне понятно, но формальная отписка «approve» может стать причиной краха последующих работ. Стоит задача отловить баги самостоятельно, поэтому лучше чекать строки дробно: например, по 50–100 строк, делая небольшие перерывы между code review.
Также рефакторинг способствует выявлению и устранению узких мест, что в отдаленной перспективе отражается на скорости работы программы.
В рамках code review ревьюер может проверить функциональность кода, провести тесты — полная свобода действий с учетом поставленных задач и специфики проекта!
Что важно, обеспечивается прямая и доверительная коммуникация: как ревьюер может задавать вопросы автору, так и автор может вести диалог с командой. Возможен и такой ход событий, при котором разработчик доказывает актуальность своего решения – в этом плане все действуют в интересах проекта, с пониманием воспринимая разные точки зрения. Доказать свою правоту любой ценой — это не про code review.
