x
 
Василий
25 июля 2019
Советы почтой каждую неделю
Пожалуйста, получите наше письмо, чтобы подтвердить свой адрес:
Вы подписаны на «Советы за неделю»:

Василий, расскажите о принципе «не протыкал — не сделал».


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

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

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

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

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

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

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

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

Не про­ты­кал — не сде­лал
P. S. Это был совет о веб‑разработке. Хотите знать всё о коде, тестах, фронтенд‑разработке, цеэсэсе, яваскрипте, рельсах и джейде? Присылайте вопросы.
Вёрстка и прототипирование — дисциплина Школы дизайнеров. Набор закрыт. Оставьте почту, и мы напишем вам, когда откроется следующий набор.
 

Поделиться
Отправить

Комментарии

Глеб Кемарский
25 июля 2019

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

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

Андрей Никифоров
28 июля 2019

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

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

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

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

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

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


29 июля 2019

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

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

Владимир Тицкий
30 июля 2019

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


Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры. Мы ожидаем, что такие комментарии составят около 20% от общего числа.

Решение о публикации принимается один раз; мы не имеем возможности комментировать или пересматривать свое решение, хотя оно может быть ошибочно. Уже опубликованные комментарии могут быть удалены через некоторое время, если без них обсуждение не становится менее ценным или интересным.

Вот такой веб 2.0.

Вы используете Зеплин? 1 Несколько месяцев назад меня повысили из обычного разработчика до «тимлида» 1 Как правильно, эффективно и уважительно ставить KPI? Как готовить макеты для технологов? 6




Недавно всплыло

2 4 2 Как совместить информационный стиль и текст для поисковиков? 7