Что делать, если в твоем тексте или коде нашли ошибку?
Ситуация глазами разработчика
Ты написал код, отправил его на ревью. Во время ревью тебе указали на ошибку в коде и вернули задачу на доработку.
Здесь мы не рассматриваем ошибки в бизнес-логике написанного кода — только ошибки на уровне интерпретатора/компилятора, из-за которых приложение «падает».
Чего НЕ нужно делать
Не нужно послушно исправлять указанную ошибку и отправлять задачу на повторное ревью. После чего ждать дальнейшей участи и надеяться на то, что ревьюер ничего больше не найдет и пропустит код дальше.
А еще не нужно оправдываться. Оправдание есть у каждого (открою секрет: ревьюеру не интересно, почему ты допустил ошибку. В первую очередь это должно быть интересно тебе лично — сделай правильные выводы, чтобы такая ошибка не повторялась).
Что нужно сделать
Не нужно исправлять ошибку сразу. Проверь работоспособность всего кода. Повторю — ПРОВЕРЬ РАБОТОСПОСОБНОСТЬ. И исправь ВСЕ выловленные ошибки.
Пройдись по коду всеми возможными линтерами и анализаторами (линтер — это как автоматическая проверка орфографии в MS Word, только для кода).
Запусти код еще раз у себя (локально, на тестовом стенде, еще как-нибудь).
«Погоняй» код на различных данных. Пообщайся с постановщиком или тестировщиком, чтобы получить приближенные к реальности входные данные для тестирования.
Поправь найденные ошибки.
Повтори все вышенаписанное еще раз.
Почему?
Наличие ошибки — это повод задуматься о том, что код плохо протестирован самим разработчиком. А ведь прямая обязанность разработчика — это в первую очередь предоставление РАБОТОСПОСОБНОГО кода.
Тестировщики проверяют корректность бизнес-логики, граничные и нестандартные значения. Но только при условии, что код работает и способен запуститься на тестировочном стенде.
Повторяю — нужно исправлять не ошибку, а проверить работоспособность своего кода. Каждой его строчки. И убедиться, что твой код не повлиял на другой функционал.
Запомни: твой коллега-ревьюер — не линтер. В его обязанности не входит построчная проверка кода на синтаксические ошибки.
И тестировщик не линтер.
Цель ревью — взглянуть на твое решение «свежим» взглядом или с позиции опыта и указать на моменты реализации, которые ты не учел. Но никак не поиск ошибок на уровне кода.
А задача тестировщика — проверить код на соответствие бизнес-требованиям, а также убедиться, что новый функционал не повредил стабильные узлы.
Конечно, есть компании, где ревьюеры пробегутся по всему коду и подробно укажут на все найденные ими ошибки. Но такое бывает редко. И такие ревьюеры — тема для отдельного поста.
Вывод
Ситуации, когда от разработчика выходит неработоспособный код, конечно же бывают. Никто не отменял запары, форс-мажоры, усталость и невнимательность. Но если такие ситуации повторяются регулярно, то это существенный удар по твоей репутации как разработчика.
Ревьюерам не хочется постоянно быть нянькой — им хочется выполнять СВОИ задачи, а вместо этого они отвлекаются на поиск ошибок в ТВОЕМ коде.
И это повод:
Обновить свой инструментарий: обвесить свою IDE (или редактор кода) линтерами и анализаторами или настроить скрипт, который при изменениях прогонял бы код проекта через них.
Подумать над средой для тестирования задач. Чтобы можно было собрать проект и «погонять» его при разных условиях. Не так глубоко, как это делают тестировщики. Но основные кейсы нужно обязательно протестировать самостоятельно. Лайфхак: спроси у коллег, как они тестируют свой код перед отправкой в ревью.
При постановке задачи сформировать (с постановщиком, тестировщиком или самостоятельно) тест-кейсы.
Ревьюер скажет тебе спасибо, если ты коротко опишешь список изменений, которые ты внес в код. А также укажешь, как именно тестировал и проверял свой код.
Подумать о внедрении подходов и инструментов тестирования (Unit-тесты, TDD, например, если их нет) лично для себя или на уровень всего отдела.
Ситуация глазами редактора
Ты написал текст, отправил на проверку и получил фидбэк о пропущенной запятой или орфографической ошибке.
Нет.
Исправить ошибку и снова отправить на проверку.
Да.
Внимательно — весьма внимательно — пройтись по всему тексту и перепроверить все запятые и буквы.
Почему?
1
Время принимающего текст (например, старшего редактора) для бизнеса стоит дороже. Он может либо править твои ошибки, либо делать более сложную задачу.
2
Страдает твоя личная репутация. Неимоверно бесит два или три раза подряд отправлять текст на правку элементарных вещей.
3
Возможно, в тексте есть и другие — более серьезные ошибки. Если ты дописываешь текст в сильной запаре и с вытекающими под вечер глазами, остановись. Проветрись и проверь еще раз. Может, где-то дублирование смыслов. Может, неверная ссылка. В общем, проверь.
Как быть?
Не страшно пропустить запятую. Важно отношение. Не надо писать, что было мало времени на вычитку. Или что голова распухла от задач. Надо принять замечание и все внимательно проверить.
Хитрость
Если ситуация такова, что надо срочно отправить текст, который дописываешь с гудящим от напряжения мозгом, пиши коммент: «Отправляю текст. В нем могут быть опечатки, потому что делали срочно. В течение часа я внимательно проверю еще раз».
Вывод
Пропущенная запятая — не ошибка, а сигнал о повторной тщательной проверке.
P.S.
То же относится, когда на ошибку указали в комментариях в соцсетях. Поблагодарить за внимательность, исправить ошибку и пойти внимательно читать весь текст. Весь. Текст. Целиком.
