От автора: итак, какие важные функции несет в себе front end разработка? Начнем с того, чего не будет в этом посте: это не список языков. Это не список библиотек. Это не список жалоб, здесь не будет кода. В сети полно важных постов на эту тему.
Каждая новая функция на Degreed претерпевает строгий процесс проверки и приоритизации. Мы работаем быстро и каждый месяц выкатываем много крутых функций. Поэтому мы должны точно знать, что то, над чем мы работаем, ценится. Мы должны четко знать, что хорошо выполняем свою работу и не упускаем детали, которые сделают эти функции успешными.
Как front end разработчик, я мысленно проверяю несколько концепций, когда наша команда находится на этапах планирования и выполнения. Это важнейшие привычки для успеха. Чем раньше вы задумаетесь об этих концепциях в процессе, тем более гладко все пройдет. Degreed посвящен изучению и обмену изученным, поэтому я решил перенести мысли на бумагу. Надеюсь, информация будет вам полезна, и вы поделитесь своими идеями в комментариях.
Доступность
Адаптивный дизайн
Производительность
Однообразие
Кроссбраузерная совместимость
Безопасность
Локализация
Юзабилити/UX
Разберем подробно каждую концепцию.
Доступность
С вашим продуктом будут работать самые разные пользователю. Нельзя смотреть за кроссбраузерной совместимостью и забывать про доступность. По данным WebAIM примерно одна пятая населения имеет различные ограничения в возможностях. WebAim утверждает:
«Не у всех людей недуги связаны с тем, что затрудняет доступ к сети Интернет, но это все еще значительная часть населения. Для бизнеса недальновидно отсеивать 20, 10 или даже 5 процентов потенциальных покупателей через сайты. Школы, университеты и государственные учреждения поступят не просто глупо, но во многих случаях это будет считаться нарушением закона.»
Как разрабатываемая вами функция будет работать для людей, которые не могут использовать мышь? Существуют какие-либо альтернативные действия, которые можно подключить, чтобы пользователи с клавиатурой могли выполнять те же задачи? Как пользователи с нарушениями зрения «увидят» ваш контент? Какой базовый тип у создаваемого вами компонента, как вы его опишите для скрин ридеров? Как увеличение стандартного размера шрифта в браузере повлияет на общий дизайн?
Адаптивный дизайн
Пользователи мобильных устройств уже давно обогнали пользователей десктопа. Чем раньше вы начнете думать о том, как функция ведет себя на разных размерах экрана, тем успешнее она будет, и тем меньше будет компромиссов.
Что будет с вашей функцией, если просматривать ее на маленьком экране? Что будет на большом проекторе в конференц-зале? Что если ваши пользователи переворачивают свои устройства с горизонтального в вертикальное положение? Если пользователь любит функцию на ноутбуке, будет ли он ее также любить на телефоне?
Производительность
На этапах планирования не всегда обязательно проводить оптимизацию производительности. Хорошо, если вы не забываете про нее, но не проводите оптимизацию раньше времени. На ранних этапах зачастую важнее думать о воспринимаемой скорости, так как на восприятие скорости могут оказывать сильное влияние дизайн и поток.
Как разработать функцию таким образом, чтобы не замедлить пользователя при выполнении поставленной им задачи? Как сказать пользователям, что им не придется долго ждать? Как замаскировать ожидание, чтобы улучшить восприятие скорости? Знаете ли вы все лучшие практики, проблемы с фреймворком, библиотекой или методологией, которую вы используете для латания дыр оптимизации?
Однообразие
Однообразие всегда легче поддерживать в начале проекта, чем во время его эксплуатации или при добавлении новых функций. Наличие четкого руководства по стилю и четкого набора правил программирования неоценимо. Временами может казаться, что эти правила сковывают вас, однако они помогают. Особенно по мере роста команды и прихода/ухода людей в компании.
Эта новая функция выглядит и ощущается как все остальное (т.е. соблюдает правила стиля)? Есть предложения, из-за которых нужно править или дополнять руководство по стилю? Будут ли удобны и понятны твои шаблоны программирования следующему разработчику, который увидит твой код?
Кроссбраузерная совместимость
Скорее всего, мне не нужно вам рассказывать, почему поддержка разных браузеров – это хорошая идея. Это одна из главных задач front end разработчика. Я скажу следующее: чем дольше вы занимаетесь кроссбраузерностью, тем раньше вы сможете найти узкие места. Чтобы получить конструктивный диалог о поведении дизайна и о том, что нужно изменить под требования, необходимо иметь четкий набор поддерживаемых браузеров, с которым согласна вся команда.
Как вы примените технику «изящной деградации» к этой функции в браузерах, в которых с ней возникают проблемы? Использует ли функция нативные компоненты браузера, которые могут оказать влияние на весь дизайн (не все радио кнопки выглядят одинаково, скроллбары в браузерах на Windows могут изменять общую ширину и т.д.)?
Безопасность
Необходимо помнить о том, что большинство форм защиты на стороне клиента следует рассматривать как сдерживающее средство, а не фактическую безопасность. Все еще очень много эксплойтов, о которых нужно знать и думать, когда переходишь на этап программирования новой функции. Мы несем ответственность за работу с back end разработчиками, чтобы быть в синхронизациями с системой сдержек и противовесов.
Как сильно эта новая функция полагается на вводимые данные? Как с помощью этой функции использовать другие? Предполагаете ли вы какое-то количество и тип получаемых данных от пользователя или сервера? Будете ли вы использовать чужой код, и понимаете ли вы, как он работает?
Локализация
На мысли о возможной локализации влияет ваша аудитория, бюджет и стратегия (i18n). Если вам определенно нужно поддерживать несколько языков (на момент написания статьи на Degreed поддерживается более 25 языков), важно помнить о том, как изменится макет при изменении длинны текста.
Учитывает ли дизайн разное количество текста? Используете ли вы идиомы, слоганы или сленговые выражения, которые теряют смысл при буквальном переводе?
Обратите внимание: если вы не поддерживаете i18n, то эти вопросы применимы и к доступности!
Юзабилити/UX
Несмотря на то, что все вышеперечисленные пункты относятся к общему пользовательскому опыту, в UX намного больше факторов. Каждая команда подходит к владению UX по-разному, но нет сомнений в том, что пользовательский опыт относится к работе front end разработчика, независимо от того, кто им «владеет».
Есть ли в дизайне места, которые могут запутать? Смогут ли ваши бабушка и дедушка использовать эту функцию? Можно ли подумать о более стандартном подходе или шаблоне, который уж известен пользователям?
Заключение
Фреймворки приходят и уходят, доступные инструменты продолжают приходить и уходить, облегчая нашу работу, а языки продолжают развиваться. Я хотел поделиться с вами списком, который вы и так знаете, но который останется полезным, если в индустрии что-то изменится.
Автор: Jason Gill
Источник: //dev.degreed.com/
Редакция: Команда webformyself.
