Что делать, если в твоем тексте или коде нашли ошибку?

Ситуация глазами разработчика

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

Здесь мы не рассматриваем ошибки в бизнес-логике написанного кода — только ошибки на уровне интерпретатора/компилятора, из-за которых приложение «падает».

Чего НЕ нужно делать

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

А еще не нужно оправдываться. Оправдание есть у каждого (открою секрет: ревьюеру не интересно, почему ты допустил ошибку. В первую очередь это должно быть интересно тебе лично — сделай правильные выводы, чтобы такая ошибка не повторялась).

Что нужно сделать

Не нужно исправлять ошибку сразу. Проверь работоспособность всего кода. Повторю — ПРОВЕРЬ РАБОТОСПОСОБНОСТЬ. И исправь ВСЕ выловленные ошибки.

• Пройдись по коду всеми возможными линтерами и анализаторами (линтер - это как автоматическая проверка орфографии в MS Word, только для кода). 

• Запусти код еще раз у себя (локально, на тестовом стенде, еще как-нибудь). 

• «Погоняй» код на различных данных. Пообщайся с постановщиком или тестировщиком, чтобы получить приближенные к реальности входные данные для тестирования. 

• Поправь найденные ошибки.

• Повтори все вышенаписанное еще раз.

Почему? 

Наличие ошибки — это повод задуматься о том, что код плохо протестирован самим разработчиком. А ведь прямая обязанность разработчика — это в первую очередь предоставление РАБОТОСПОСОБНОГО кода.

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

Повторяю — нужно исправлять не ошибку, а проверить работоспособность своего кода. Каждой его строчки. И убедиться, что твой код не повлиял на другой функционал.

Запомни: твой коллега-ревьюер — не линтер. В его обязанности не входит построчная проверка кода на синтаксические ошибки.

И тестировщик не линтер. 

Цель ревью — взглянуть на твое решение «свежим» взглядом или с позиции опыта и указать на моменты реализации, которые ты не учел. Но никак не поиск ошибок на уровне кода.

А задача тестировщика — проверить код на соответствие бизнес-требованиям, а также убедиться, что новый функционал не повредил стабильные узлы.

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

Вывод

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

Ревьюерам не хочется постоянно быть нянькой — им хочется выполнять СВОИ задачи, а вместо этого они отвлекаются на поиск ошибок в ТВОЕМ коде.

И это повод:

1. Обновить свой инструментарий: обвесить свою IDE (или редактор кода) линтерами и анализаторами или настроить скрипт, который при изменениях прогонял бы код проекта через них.

2. Подумать над средой для тестирования задач. Чтобы можно было собрать проект и «погонять» его при разных условиях. Не так глубоко, как это делают тестировщики. Но основные кейсы нужно обязательно протестировать самостоятельно. Лайфхак: спроси у коллег, как они тестируют свой код перед отправкой в ревью.

3. При постановке задачи сформировать (с постановщиком, тестировщиком или самостоятельно) тест-кейсы. 

4. Ревьюер скажет тебе спасибо, если ты коротко опишешь список изменений, которые ты внес в код. А также укажешь, как именно тестировал и проверял свой код.

5. Подумать о внедрении подходов и инструментов тестирования (Unit-тесты, TDD, например, если их нет) лично для себя или на уровень всего отдела.

Ситуация глазами редактора

Ты написал текст, отправил на проверку и получил фидбэк о пропущенной запятой или орфографической ошибке. 

Нет. 

Исправить ошибку и снова отправить на проверку. 

Да. 

Внимательно — весьма внимательно — пройтись по всему тексту и перепроверить все запятые и буквы. 

Почему? 

1 

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

2

Страдает твоя личная репутация. Неимоверно бесит два или три раза подряд отправлять текст на правку элементарных вещей. ​​

3

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

Как быть? 

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

Хитрость

Если ситуация такова, что надо срочно отправить текст, который дописываешь с гудящим от напряжения мозгом, пиши коммент: «Отправляю текст. В нем могут быть опечатки, потому что делали срочно. В течение часа я внимательно проверю еще раз». 

Вывод

Пропущенная запятая — не ошибка, а сигнал о повторной тщательной проверке. 

P.S. 

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