Перевод статьи Дэвида Ю «These common mistakes will lead to immortal bugs. Learn how to avoid them».
«Разве мы это уже не фиксили?»
Это вопрос, который задаете вы или ваш коллега после того как менеджер продукта публикует снапшот бага.
Все это кажется каким-то дежавю. Вы пытаетесь восстановить в памяти, когда вы исправляли этот баг в коммитах. В чем же дело?
Просто вы не добрались до основной причины появления этого бага, поэтому он будет появляться снова и снова, как головы у Гидры.
Вот некоторые шаблоны, ведущие к неубиваемым багам.
Хардкодинг
Занимаясь фронтенд-разработкой, мы часто используем временные данные для быстрого построения пользовательского интерфейса. Это нормально.
Проблема в том, что эти временные данные у нас бывают во многих местах. В результате легко забыть одно-два таких значения, когда пушите свой код.
Вот несколько советов:
- Используйте простую переменную для ваших временных данных и применяйте ее в разных компонентах.
- Пишите комментарии вроде // TODO: remove later – это позволит вам быстро находить нужные места в дальнейшем.
- Не полагайтесь на неизменность бэкенд-данных.
Давайте отложим рефакторинг
По мере работы ваша кодовая база будет только расти. Ваш клиент или начальник могут и не знать об отрицательном эффекте отсутствия рефакторинга, потому что на первый взгляд все выглядит прекрасно.
Как же нам определиться, когда нужно заняться рефакторингом?
Согласно Refactor Guru, нужно следовать «Правилу Трех»:
- Когда делаете что-то первый раз, просто сделайте это.
- Когда делаете что-то похожее в следующий раз, поморщитесь от необходимости повторения, но все равно сделайте то же самое.
- Когда делаете что-то в третий раз, начинайте рефакторинг.
Размещение всего кода в одном файле
Это идет рука об руку с рефакторингом. Когда проект свежий, тяжело предугадать, насколько объемным станет его функционал.
Когда-то у меня был файл, разросшийся до тысяч строк кода. Рефакторинг такого кода это практически хирургическая операция – очень деликатная, но итог того стоит.
У большинства людей есть какие-то принципы, согласно которым они структурируют свой код. Файлы могут разделяться по страницам, фичам, по принципу разработка/продакшен, в соответствии с приватными или публичными методами, по MVC-модели и т. д.
Принцип структуры папки проекта заслуживает большого внимания и отдельной статьи.
Отсутствие спецификаций для API
– Погодите, а почему картинки больше не отображаются? – спрашивает менеджер продукта фронтенд-разработчиков.
Фронтенд-разработчики смотрят в консоли ответ сети.
– Погодите, а почему у данных больше нет picture_url? – спрашивают они.
– А, да, теперь изображения имеют три размера: large_pic_url, med_pic_url, small_pic_url, – это бэкенд-разработчик услышал обсуждение и присоединился к разговору.
Звучит знакомо?
Каждый старается делать свою работу. Но для достижения общего результата нужно коммуницировать между собой.
Вот несколько простых решений для начала:
- Прежде чем создавать API, начните с JSON-файла с данными, к которым будут иметь доступ и фронтенд-, и бэкенд-разработчики.
- Когда API завершен, генерируйте документ с помощью https://github.com/apidoc/apidoc.
- Уведомляйте коллег о существенных изменениях перед тем, как разворачивать их.
Есть и более замысловатые подходы к написанию спецификаций и обработке документации. Поделитесь в комментариях, как вы это делаете в вашей команде!
Слияние кода без чтения конфликтов
Вещи, способные что-то сломать, не вызывают больших опасений, пока вы можете откатиться к предыдущему коммиту. А вот если ваш код или код вашего товарища по команде исчезает в процессе, то это проблема.
Это часто случается, когда вы хотите «сэкономить время» и двинуться вперед.
Если у вас есть какие-то сомнения, обратитесь к разработчику, который сделал коммит, конфликтующий с вашим.
Если вы что-то испортили, применяйте git merge —abort или git-reset —hard. В случае если исправить не удается, – удалите проект и клонируйте его заново.
Подумайте дважды, прежде чем делать git push -f.
Исправление компонента, доступного к повторному использованию, без тестирования
Компоненты, которые можно использовать повторно, это туз в рукаве каждого разработчика. Например, в ситуациях, когда клиент хочет иметь одинаковый инструмент для выбора даты на разных страницах.
Вы думаете: «Я сделаю прекрасный компонент для выбора даты. Кода меньше – дела больше».
Спустя несколько месяцев клиент говорит, что хочет, чтобы на вот этой странице при выборе даты взрывался фейерверк, а на других страницах месяцы были представлены в виде разных котят. Теперь вам надо, чтобы инструмент выбора даты стал более динамичным, чем раньше.
И после внесения изменений вы обнаруживаете, что фейерверки вылетают из котят.
Если у вас большая компания, то выявлением подобных вещей может заниматься отдел QA. Но если в вашей организации такого отдела нет, вам придется самостоятельно разыскивать ваш компонент по имени, чтобы отследить, на что могут повлиять изменения.
Делайте для себя записи о файлах, в которых используете компоненты повторно. Тестируйте эти файлы визуально и функционально, в зависимости от того, что они делают.
Каждый случай, когда вы говорите «пока прокатит»
Вы знаете, что позже к этому вернетесь. Главное, не забыть.
При выборе между скоростью разработки и стабильностью программы важно соблюдать осторожность и не всегда отдавать предпочтение скорости. Это как водить машину и никогда не проверять ее техническое состояние.
Вы можете подумать о принятии какого-то соотношения скорости и качества. Например, две быстрые итерации и одна для обеспечения качества.
Заключение
- Старайтесь не хардкодить значения, если можно этого избежать. А если приходится так делать, оставляйте для себя пометки.
- Проводите рефакторинг, если делаете одно и то же в третий раз.
- Разбивайте код и почаще занимайтесь рефакторингом.
- Фронтенд- и бэкенд-инженеры должны сотрудничать, чтобы согласовывать передачу данных.
- Если не понимаете, что вызывает конфликт слияния, поговорите с человеком, написавшим коммит.
- При внесении изменений в компонент, используемый повторно, проверяйте его работу во всех местах, где он используется.
- Найдите здоровый баланс между скоростью и качеством.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]