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

Начнем с моего последнего столкновения с этой проблемой.

Небольшое приложение, которым просто пользуются администраторы

В одном из моих недавних проектов я работал фронтенд-разработчиком в команде, состоящей из семи человек. Это был мой первый проект фронтенд-разработки, и вначале мой опыт работы с Angular был очень ограниченным. Тем не менее, я все еще был тем, кто в основном разрабатывал библиотеку, которая используется другими командами, и несколько небольших веб-приложений. Моими товарищами по команде были инженеры по бэкенду и DevOps.

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

В конце недели он создал пулреквест, и, разумеется, я обязан его просмотреть. Скажем честно, от него пахло хорошей порцией кода. Некоторый код был скопирован и включал имена классов CSS, которые были совершенно неуместны в этом приложении. Тесты вообще не писались и в целом качество кода было далеко не идеальным. Я рассказал ему о проблемах, и он до некоторой степени их уменьшил. Как бы то ни было, впереди еще долгий путь (примерно один-два рабочих дня).

Знаменитые слова против качества кода

Он согласился со мной по большинству вопросов, но по некоторым (например, по классам CSS) он просто сказал, что пока не хочет их исправлять. Команда UX никогда не обращала внимания на этот материал, и они, очевидно, полностью его изменили. Затем эта информация повлияла на весь процесс обзора. Во время звонка он даже сказал мне эти (не-) известные слова:

Мы сделаем это как следует позже.

По ходу обсуждения я также однажды услышал:

Я потратил целую неделю на эту задачу и на менеджера проекта, и я просто хочу закончить ее сейчас!

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

То, что я сделал, было непрофессионально

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

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

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

Это была моя вина и только я. Я знал технологию и недостатки его решения. Я все еще нажимаю кнопку подтверждения. Как разработчик программного обеспечения, вы обязаны создавать высококачественный код. Как рецензент запросов на вытягивание, вы обязаны давать отзывы, которые улучшают код и являются залогом качества. Я не был. И, прочитав «Чистый кодер» дяди Боба, я знаю, что тоже был непрофессиональным. Опять же, это был я. Я был непрофессионален.

Как избежать этого сценария

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

Трассирующие пули и производственный код против прототипов

Одна вещь, которая мне очень помогла, - это начать думать о коде, который я просматриваю, как о функции трассировки / производства, а не как о прототипе. Я использую эти два термина, как Дэвид Томас и Эндрю Хант в «Программисте-прагматике». И трассирующие маркеры, и прототипы - это способы узнать, возможно ли что-то технически, путем проверки с помощью кода. Однако есть большая разница в подходе, который вы используете для их создания.

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

С другой стороны, трассирующие пули создаются с той же точностью, что и при обычной разработке функций. Код протестирован (возможно, вы даже занимаетесь разработкой через тестирование). Применяется чистый код. Вы гордитесь тем, что сделали.

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

Не делайте качество кода зависимым от внешних факторов.

Многие попадают в ловушку мысли, что условия изменятся. Не заставляйте качество вашего кода зависеть от других. Команда UX рассмотрит и изменит его позже. Действительно? Они? Вы не знаете, поэтому придерживайтесь своих стандартов, даже если что-то изменится позже. Скорее всего, вам будет гораздо лучше адаптировать приложение к новым требованиям, если у вас с самого начала будет чистый код.

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

Объясни свои рассуждения

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

Сохраняйте свою позицию

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

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

Предложите свою помощь по открытым вопросам

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

Создайте дополнительную задачу

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

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

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

Заключение

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

Будьте профессионалом.