Отдел новостей 27 июля 2015, 14:29

Что нужно знать для разработки приложения в 2015 году

Последний год я работал над созданием с нуля моего первого серьёзного веб-приложения. Мне пришлось многому учиться, особенно, когда дело касалось безопастности и взаимодействия с пользователем. Будет кстати упомянуть, что последний раз когда я делал что-то сколь-либо внушительное, на дворе был ещё 2005 год, так что, в своё оправдание могу сказать, что мне нужно было очень многое наверстать, пишет автор блога venanti.us.

В любом случае, когда есть много мелких (но важных!) деталей немудрено что-нибудь забыть — особенно, когда вы только начинаете работу. Список ниже не претендует на какую-либо полноту, и, если вы опытный разработчик, я не сомневаюсь, что ничего из этого вас не удивит, но я надеюсь, что это будет неплохим подспорьем для новичков.

Фото: Johan Larsson via Flickr.

Веб

Безопасность

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

Идентификация пользователей. Для хранения паролей прежде всего «посолите» и захешируйте их, используя широко известную библиотеку для шифрования. А лучше, если есть возможность, предоставьте это ВКонтакте, Facebook, GitHub или чему-либо ещё и просто пользуйтесь OAuth.

Шифрование. Несмотря на все заморочки с сертификатами, никто ещё не придумал ничего лучше, чем SSL. Используйте его. Не забывайте про HSTS.

Данные для доступа к системе. Никогда не оставляйте в системе контроля версий важные данные сервера, вроде ключей API и паролей от баз данных (например, жёстко вшивая их в код).

Анимация

Во имя всего святого, не пытайтесь сделать всё ваше приложение анимированным. Бо́льшая часть CSS анимаций задействует перерисовку всего макета; лучше ограничьте себя настолько, насколько возможно, в использовании transform и opacity.

Избегайте ленивых вычислений параметра transition, если вы используете его, то используйте отдельные атрибуты (например, "transition: opacity 250ms ease-in" вместо "transition: all 250ms ease-in").

Взаимодействие с пользователем (UX)

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

Перенаправления при авторизации. Если пользователь пробует зайти на страницу, для просмотра которой он должен быть авторизован, должно быть перенаправление на страницу, где он сможет ввести логин и пароль. После этого он, однако, должен быть перенаправлен на первоначальную страницу (разумеется, если у него теперь достаточно доступа для её просмотра). Если пользователь вводит неправильный пароль, должно появляться визуальное напоминание, что он может его переназначить или восстановить.

E-mail

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

Мобильная разработка

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

Последующие пункты предполагают, что вы выбрали мобильные устройства как одну из платформ для своего приложения. В своём проекте я использовал Grunt, так что в статью включены несколько специфичных для него плагинов, которые я использовал, но, скорее всего, что-то похожее есть и для других JavaScript билдеров.

Архитектура

Одностраничные приложения. Сегодня бал правят именно одностраничные приложения (single-page applications — SPA). Ключевое преимущество SPA — это меньший объём подгрузки. Вы догружаете ресурсы по мере необходимости, и вам не нужно каждый раз загружать одно и то же, снова и снова. Если вы только начинаете делать веб-приложение — оно определённо должно быть одностраничным.

Пользовательский интерфейс

Разрешения. В процессе разработки MVP (Model-View-Presenter), вам, конечно, не нужно проверять, работает ли ваш UI на любом возможном мобильном устройстве, — но вы должны убедиться, что он работает на основных разрешениях телефонов и планшетов. Беспокоиться о каждом отдельном устройстве стоит, только когда вы опеределите свою нишу на рынке.

Оптимизация трафика

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

JS & CSS — соединить и минимизировать. Вы должны объединять ваши СSS и JS файлы в два единственных больших файла (один для JS, один для CSS) и возможно сильно уменьшить их. Crunt-contrib-concat, Grunt-contib-cssmin и Grun-contrib-uglify вам в этом помогут.

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

Второй касается библиотек, которые использует ваше приложение. Использование CDN может очень значительно снизить количество загрузок, просто кешируя их. Например, так как многие сайты используют Angular.js, запросы к коду его ядра будут перенаправляться в кеш, и пользователь будет использовать уже имеющуюся версию, вместо повторной загрузки из сети.

Уменьшаем объём CSS. Большинство начинающих разработчиков будут, вероятно, использовать какие-либо UI фреймворки (такие как Bootstrap, Foundation и т.д.). Эти фреймворки достаточно объёмные, а поскольку уменьшенные версии их css обычно доступны в CDN, маловероятно, что вам действительно нужны все включённые стили.Поэтому неплохо использовать, например, uncss (обычно в паре с processhtml) для удаления стилей, которые вы, в конечном счёте, не используете. Важно упомянуть, что uncss не может цеплять динамические стили (которые появляются только в результате, скажем, JavaScript событий), поэтому вам нужно будет тщательно проверить в браузере, не отсекла ли эта утилита чего лишнего.

CSS — помещайте ключевые вещи в head. Стили, которые должны быть отображены ещё до того, как приложение закончит загрзуку, должны быть размещены в head; менее важные должны быть подгружены позже.

Уменьшаем объём JS. Поскольку переменные в JavaScript коде не должны иметь понятные человеку названия, как только он отправлен в продакшн, это может быть отличной идеей переименовать все эти user.email в u.e для того, чтоб уменьшить размер файлов. К счастью, для этого есть специальный инструмент — уже упомянутый выше uglify, который обфуцирует код, сильно уменьшая его размер.

Формы

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

В заключение

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