Школа
Веб-разработка

Принцип «не протыкал — не сделал»

25 июля 2019
👁 9026   🗩4
Веб-разработка

Принцип «не протыкал — не сделал»

25 июля 2019
👁 9026   🗩4
Василий Половнёв
Технический директор бюро
Полезно
 24
24
Непонятно
  
Войдите в Бюросферу, чтобы голосовать

Бесит, когда говорят, что исправили баг или выкатили фичу, а на деле ничего не работает:

Разработчик утверждает, что поправил последние замечания по демоглаве и присылает на неё ссылку. Замечания не исправлены, из разворота по‑прежнему торчит часть текста: CI‑сервис, доставляющий код на стейджинг, упал и не выкатил последние изменения.

Девопс утверждает, что настроил особенную аутентификацию для журналистов и передаёт логины и пароли арт‑директору. Ни один из них не работает: девопс добавил логины и пароли в конфигурацию веб‑сервера, но забыл включить их использование.

Бэкендер утверждает, что выкатил новый АПИ для добавления комментариев в продакшен. При переключении фронтенда на новый АПИ выясняется, что он не работает: в продакшене не хватает ключа для проверки комментариев на спам.

Кажется, что причины здесь разные, а винить стоит CI, Гитхаб или сисадминов. Но фундаментально причина одна: не проверил свою работу, не протыкал то, что получилось.

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

Чтобы не забывать протыкивать свою работу, нужно подкреплять свои слова доказательствами. Поправил вёрстку — открой ту версию, о которой отчитался, проверь, дай ссылку и приложи скриншот; настроил особенную аутентификацию — запиши видео, как логинишься; выкатил АПИ в продакшен — дай скриншот с примером запроса и ответа сервера в продакшене, а не локально.

Отсюда принцип:

Не протыкал — не сделал

P. S. Это был совет о веб‑разработке. Хотите знать всё о коде, тестах, фронтенд‑разработке, цеэсэсе, яваскрипте, рельсах и джейде? Присылайте вопросы.

Веб‑разработка
Полезно
 24
24
Непонятно
  
Войдите в Бюросферу, чтобы голосовать
Отправить
Поделиться
Поделиться
Запинить
Твитнуть

Комментарии

Несколько раз попадал впросак, «протыкав» исправления из собственной сессии в ЦМС. Думал, что всё проверил, а у клиента без прав администратора кнопки не работают :‑(

Поэтому слежу, чтобы в скриншот с исправлениями попадала шапка браузера. Тогда и заказчику, и мне самому понятно, в режиме «инкогнито» я работу проверял или нет. Особенно помогает, когда нагрузка большая и внимание начинает проседать.

Андрей Никифоров

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

Ручное протыкивание — это медленно, это человеческий фактор, это не масштабируется. Добавили новый визард — N страниц × N вариантов, — сколько нужно веток проверить? И, наконец, какого рожна разработчик должен тратить время на то, что может сделать машина?

Интеграционные/поведенческие тесты, стейджинг, обязательный CI, мониторинг сервисов. Вот это — подход.

Упал CI? Это ред алерт девопсам и большой красный баннер разработчику: «Выкатываться нельзя, тесты не отработали». Если это селф‑хостед CI, то у хорошего девопса лежит запасной контейнер, который автоматически поднимется, если упадёт основной.

Девопс недонастроил сервер? Есть тесты и на это. Например, nginx‑route‑testing или самописные скрипты, сличающие конфиг с эталоном. А если конфиг сделан модульно, то инклюды можно переносить с сервера на сервер, не мешая основному конфигу.

Про бекендера вообще молчу: тесты на АПИ и CI мгновенно выявят проблему. Swagger умеет автоматом писать тесты, основываясь на определении АПИ. То есть, тут вообще минимум усилий.

Андрей, я не призываю заменять автоматические тесты, тестировщиков, стейджинги, CI и мониторинг ручным тестированием. Это было бы безумием: тратить время людей на то, что могут и должны делать роботы.

Речь о том, что нужен sanity check в боевой версии, потому что автоматические тесты, деплой, CI и тестировщики не гарантируют, что код, работающий на стейджинге или компьютере разработчика, успешно доедет и заработает в продакшене.

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

Цель рубрики — обсуждение вопросов дизайна, веб-разработки, переговоров, редактуры и управления.
Комментарии модерируются. Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры.

Рекомендуем другие советы