Самые большие ошибки в веб-разработке — опыт экспертов

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

Часто это случается из-за отсутствия в команде единых стандартов при работе над развитием системы. А ещё чаще — из-за недостаточного внимания к UX на старте. Такие фейлы бывали и у нас, поэтому сейчас мы ориентируемся на ожидания пользователей уже на этапе прототипирования. Это удлиняет проект, но так мы исключаем риски, что функциональный заказчик откажется работать в системе, например потому что «интерфейс какой-то не такой».

Сейчас стандартная схема работы нашей команды включает 5 обязательных шагов:

1. Начинаем с пользовательского интерфейса без дизайна (только функциональные элементы).
2. Добавляем оформление — цвета-шрифты.
3. Делаем интерфейс живым.
4. На живом прототипе проверяем, удобен ли он и нравится ли пользователю.
5. Если всё хорошо — отдаём в реализацию, если надо что-то поменять — возвращаемся к прототипу.

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

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

Как пользователь. У программистов часто бывают мощные компьютеры, а у пользователей — не всегда. Поэтому систему важно тестировать с максимальным приближением к привычкам и возможностям пользователей, чтобы потом не удивляться почему на вашем классном 4K дисплее всё отлично, а пользователи рапортуют о проблемах. Да, бывало и у нас такое. Теперь стараемся придерживаться правила «быть как пользователь» — то есть тестировать систему в том окружении, которое определили, как целевое. Это касается разрешений и размеров дисплеев, версий браузеров и операционных систем, объёмов памяти и производительности процессора. При реализации разработчик должен постоянно проверять результат: заходить на сайты через привычные для пользователей браузеры на виртуальных машинах с аналогичными для пользовательских планшетов и компьютеров характеристиками и отдельно проверять работу на мобильных устройствах с тач-интерфейсами.

Моя самая большая ошибка в веб-разработке — удалил 6 сайтов нажатием одной кнопки.

Тогда я только начинал свой путь в веб-разработке и работал специалистом технической поддержки. К нам обратился клиент, у которого была рядовая проблема на сайте. Потратив пару часов, я сделал патч и хотел установить на клиента, но у него была мудреная cPanel, в которой очень неудобный менеджер файлов.

Чтобы упростить себе жизнь, я решил через cPanel сгенерировать FTP-доступ к серверу, чтобы удобней было заливать патч и править файлы. К моему сожалению, FTP-доступ создался криво, не работал и, более того, создал несколько странных папок на уровне директории /home, в которой лежали сайты клиента. Будучи ответственным специалистом, я не хотел оставлять за собой мусор и решил удалить эти папки. После заветной фразы «Вы точно хотите это удалить?» и подтверждения сайт вдруг перестал быть доступным. Через несколько секунд к своему ужасу я обнаружил, что файлы всех сайтов один за другим начинают удаляться и эту операцию нельзя отменить…

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

Вывод: с тех пор я невзлюбил cPanel, сфокусировался на прокачке навыков работы с терминалом и агитирую за true-доступы типа SSH/SFTP.

P. S. До сих пор так и не знаю, почему запустилось удаление всех папок сайтов, хотя казалось, что кликнул на другую папку. ?

Самая большая ошибка в жизни и в работе — это боязнь ошибиться. Приведу пример. Я работал в стартапе на позиции junior-разработчика. У меня тогда было мало опыта, и я боялся лишний раз задать вопрос коллегам, сделать что-то лишнее, предложить свои идеи, потому что мне казалось, что я могу выдать в себе непрофессионала. Вскоре в компании появился новый разработчик, который вёл себя кардинально по-другому — он постоянно задавал вопросы, генерировал новые фичи, его критиковали, но он никогда не останавливался. Через полгода я с ужасом осознал, что его повысили до middle, а меня нет. Поэтому не бойтесь делать то, что никогда не делали. Рискуйте. Боясь сделать неверный шаг, разработчики топчутся на месте, а значит не развиваются. Обновляйте стек, не откладывайте рефакторинг, внедрение технологий на потом. Ошибки дают ценные знания, которые невозможно нигде приобрести. Не зря говорят: «На ошибках учатся».

Расскажу, наверно, не самую серьёзную ошибку, а ту, которую запомнил на всю жизнь. Многие из вас слышали шутку: «Люди делятся на два типа: на тех, кто не делает бэкапы, и тех, кто уже делает».

К рядам тех, кто «уже делает», я присоединился в те давние времена, когда мой колоссальный опыт работы составлял целых 3 или 4 месяца.

Попался мне срочный и сложный для меня проект — интерактивная карта коттеджных участков. Уже не помню многих деталей кроме того, что там была какая-то вакханалия из Canvas, Area Map и прочего. И нужно было, чтобы это работало в IE7. К слову, сложность вылезла и с IE8: пришлось с помощью meta принудительно переключать его в режим IE7, потому что была проблема с opacity. Столько лет прошло, а я это помню, вспоминаю и плачу. С учётом моего опыта работы, это был, я вам прямо скажу, весьма и весьма занимательный экспириенс.

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

Я прихожу утром на работу — компьютер выключен, хм… Включаю и… ничего не грузится. Шок, паника, отчаянье, седые волосы. Вы не подумайте, даже тогда я знал, что такое Git. Но я не делал коммитов, пока не завершу задачу, даже если она крупная. Это сейчас при любом раскладе после логически завешенного куска кода — коммиться и заливай, пусть даже во временную ветку! Но это сейчас.

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

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

В общем, делайте бэкапы. Комитьтесь почаще. А если не любите, когда в дереве много коммитов, делайте просто после завершения каждой задачи squash.

Самая большая ошибка в разработке, с которой мы столкнулись не один раз, — это работа без продуктологов и проверки гипотез.

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

У нас не хватало ресурсов для проверки «а стоит ли делать эту фичу?» и вообще отсутствовала культура проведения экспериментов и опросов. Как следствие, некоторые крупные задачи делались совершенно интуитивно. Например, мы были очень воодушевлены идеей одной совместной интеграцией с партнером, рассчитывали на хорошие показатели. Мы потратили 3 месяца разработки, 2 разработчика практически всё время уделяли работе над этой интеграцией, но она не сработала. Интерес нашей аудитории оказался низким и интеграция не окупила разработку.

Ещё аналогичный пример: мы очень хотели попасть в маркетплейс одной из популярных и крупных CSM на рынке. Задача осложнялась тем, что для этого они требовали выполнить множество технически сложных условий, чтобы соответствовать их стандартам. Разработка плагина для этой CMS c переменным успехом продолжалась около 2 лет. Бесконечные ревью со стороны менеджеров маркетплейса, отправка на доработки, смена руководства и т. д. Несложно догадаться, что нас ждало разочарование. Мы не проверили качество аудитории, которая пользовалась этой CMS, она оказалась не такой платежеспособной, как мы рассчитывали.

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

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