Привет! Я - Роман Батин, ведущий фронтенд разработчик. Уже несколько лет занимаюсь управлением командами разработки интерфейсов и обучением стажеров. За время своей работы я заметил, что у большинства начинающих (да и не только) программистов, встречаются одни и те же ошибки. Корни же этих ошибок лежат даже не столько в незнании языка или технологий, сколько в отсутствии определенных навыков разработки в целом. В этой статье я сформулировал два, на мой взгляд, важных навыка, которые каждый программист должен развивать в себе, не только в области фронтенда. Начинающие разработчики часто упускают из виду, что интерфейсы, которые они создают, будут использоваться людьми без технического опыта и знаний. Современные популярные сервисы формируют определенные паттерны поведения пользователя. Например, человек, увидев иконку с корзиной, ожидает, что клик по этой иконке переведет в корзину заказов, кнопки будут визуально реагировать на клик, а долгая загрузка контента будет сопровождаться соответствующей индикацией. Многое из этого продумывается еще на стадии разработки макетов интерфейсов UX/UI дизайнерами. Однако не все детали учитываются в макетах. Например, дизайнер разрабатывает карточку, клик по которой ведет на другую страницу приложения. Очевидно, что данный элемент подразумевает интерактивность. И эту интерактивность нужно передать, а самый простой способ это сделать - навесить css свойство cursor: pointer.  Многие начинающие программисты забывают о таких важных деталях. Сюда же накладывается и вторая проблема. Разработчик, привыкнув к поведению приложения, перестает замечать различные мелочи. В очередной раз прокликав тот или иной кейс, можно упустить из виду, что отступы одних блоков отличаются от других, карточка как-то странно дергается при наведении, цвета кнопок подтверждения и отмены перепутаны. Пользователь же видит все эти странности, поскольку они для него в новинку. Он может просто не понять, какую функцию выполняет данный элемент интерфейса, если не обеспечена ясность и удобство его использования. Прокачивайте насмотренность Начать можно с простого: в очередной раз, когда вы будете пользоваться своим любимым сервисом, начните обращать внимание на его техническое устройство, а также какой опыт он вам дает как пользователю. Не забывайте использовать инструменты разработчика (DevTools), чтобы лишний раз посмотреть реализацию различных элементов управления. Постарайтесь определить, что именно в поведении интерфейса вам нравится, а что - нет. Такая рефлексия не будет занимать у вас много времени, но позволит увидеть хорошие и полезные практики и впоследствии их применить. Будьте пользователем для своего интерфейса После завершения работы над проектом или задачей сделайте небольшой перерыв: прочитайте полезную статью или разомнитесь. Это поможет вам изменить контекст вашего мышления. После этого свежим взглядом посмотрите на результат своей работы. Попробуйте пройтись по интерфейсу так, как это бы сделал пользователь, не знающий его реализацию. Это поможет вам обнаружить недоработки, которые можно исправить перед отправкой кода на проверку. Процессы разработки, выстроенные в большинстве IT компаний, направлены на минимизацию ошибок, которые попадают в конечный продукт. Unit и End-2-End тестирование, Code Review, QA позволяют выявлять баги на различных этапах. Но можно ли, написав код, пойти пить чай и переложить ответственность проверки конечного результата только на других? На мой взгляд, определенно нет. Каждый разработчик должен брать ответственность за тот код, который он пишет. Конечно, для начинающих разработчиков уровень этой ответственности значительно ниже, чем, например, для senior. Однако, важным скиллом для собственной прокачки будет развитие самоконтроля. На практике очень часто можно встретить такую ситуацию: начинающий программист, как ему кажется, выполнил задачу. Отправив коммит, он радостно отчитывается о том, что все было сделано. При проверке оказывается, что код просто-напросто не работает. Не выполняются необходимые функции. Верстка же - хорошо, если компонент будет хотя бы отдаленно напоминать макеты. Последнее можно встретить даже у более опытных разработчиков. Проблемы с pixel perfect версткой возникают зачастую даже не из-за сложности ее реализации, а в силу отсутствия проверки результатов с макетом. Перечитывайте описание задачи Периодически перечитывайте описание задачи, над которой вы работаете. Это поможет убедиться, что вы ничего не упустили. Если кажется, что задача описана недостаточно четко, не стесняйтесь обратиться за уточнениями или дополнительной информацией. Больше внимания на проверку Не бойтесь потратить время на то, чтобы после выполнения задачи пройтись по той части интерфейса (желательно, и не только), которую вы разработали. Попробуйте воспроизвести пользовательские кейсы, создать различные условия для работы интерфейса. Приведу далеко не полный список действий, которые вы можете совершить для проверки корректности своей работы. Используйте навигацию по приложению. Многие проблемы могут дать о себе знать при переключении экранов, особенно если вы используете один из SPA фреймворков. Запустите приложение в другом браузере, чтобы убедиться, что оно работает на всех популярных платформах, особенно, если оно рассчитано на широкую аудиторию. Проверьте адаптивность, используя DevTools. Не всегда она требуется (для мобильных устройств и планшетов), но даже для десктопа необходимо, чтобы контент отображался без ошибок. Проверьте вашу верстку на корректность работы при различных данных. Например, лишние скроллы могут появляться при большом количестве блоков или при длинной строке необработанной строке, которая не вмещается в контейнер. Используйте замедление сети из вкладки Network в DevTools, чтобы отследить поведение приложения при низкой скорости интернета. Не забывайте смотреть логи, чтобы не пропускать ошибки и вовремя их исправлять. И уж точно не забудьте запустить тесты и линты, если они у вас настроены (а если нет - то стоит задуматься, почему). Экспериментируйте! Написание тестов Тесты - один из важных подходов проверки работоспособности приложения. Да, тестами, unit или end-2-end, не всегда возможно полностью покрыть все кейсы, особенно если мы говорим про разработку интерфейсов. Не во всех командах вообще сформирована культура их написания. Однако, тесты несут более важную функцию, чем формальная проверка работоспособности. Продумывание тест-кейсов и их реализация позволяют лишний раз со стороны взглянуть на проделанную работу и убедиться, что вы ничего не упустили. Улучшение навыков разработки - это не только отличное знание языка программирования. Формирование рефлексивного подхода и взгляда на сам процесс создания приложения позволит вам в конечном итоге быть намного эффективнее в своей работе и делать сервисы и системы, которые не будут ломаться при малейшем чихе. Если ужать все вышеизложенное: Внимательно и вдумчиво относитесь к выполнению задачи, не спешите ее завершить - потратьте время на самопроверку. Изучите интерфейс с точки зрения обычного пользователя. Зачастую будет полезно просто рандомно покликать по экрану, может всплыть много чего интересного.  Проверьте работоспособность приложения в различных условиях: запустите в разных браузерах, измените размер окна браузера, изучите внимательно DevTools. И не бойтесь тратить время на самостоятельную проверку - это важнейшая часть всей вашей работы. Надеюсь, что мои мысли, изложенные в этой статье, могут быть вам полезны! Teamlead, Angular lead developer