Web Developer Checklist

http://webdevchecklist.com/

Что нужно знать перед тем, как сделать сайт доступным для широкой публики?

О каких вещах полезно знать, прежде чем выкладывать сайт на всеобщее обозрение? Подробности по ссылке.

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

Интерфейс и User Experience

• Держитесь в курсе того, как непоследовательно браузеры реализуют стандарты и удостоверьтесь, что сайт работает разумно на всех основных браузерах. Как минимум, протестируйте на последнем браузере на движке  Gecko (Например, на Firefox), на движке WebKit (Например, на Safari или мобильных браузерах), Chrome, и что сайт нормально отображается на IE (воспользуйтесь Application Compatibility VPC Images), а также на Opera. Также посмотрите на то, как браузеры отображают ваш сайт на разных операционных системах.
• Проверьте, как люди будут использовать ваш сайт в других браузерах: на телефонах, ридерах. — Некоторая информация о доступности здесь: WAI и Section508, мобильная разработка: MobiForge.
• Подготовка: как развернуть обновления без воздействия на ваших пользователей. Имейте одну или несколько проверок или подготовительных сред, доступных для реализации изменений архитектуры, кода или меняющегося содержания и удостоверьтесь, что они могут быть развернуты контролируемым образом без поломок чего-либо. Имейте автоматизированный способ развертывания сделанных изменений для живого сайтаэ. Самый эффективный способ — использовать систему контроля версий (CVS, Subversion и т.д.) и автоматизированный механизм сборки (Ant, NAnt, и т.д.).
• Не отображайте недружелюбные ошибки прямо пользователю.
• Не отображайте прямым текстом пользовательские адреса электронные почты, потому что их заспамят.
• Добавьте атрибут rel="nofollow" к сгенерированным пользователями ссылкам, чтобы избежать спама.
• Придумайте хорошо продуманные пределы в вашем сайте — это также относится и к разделу безопасности
• Изучите как делать постепенные улучшения.
• Перенаправляйте запрос после POST-запроса, если тот POST-запрос был успешен, чтобы предотвратить обновление от передачи на усмотрение формы еще раз.
• Не забывайте брать в счет доступность для всех (в том числе и для людей с ограниченными возможностями). Это всегда хорошая задумка и в некоторых обстоятельствах юридическое требование. WAI-ARIA и WCAG 2 — хорошие ресурсы на эту тему.
• Не делайте непонятный для пользователя интерфейс

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

• Полно дайджестов на эту тему, но Гайд по разработке OWASP полностью раскрывает тему безопасности сайта.
• Изучите внедрения, особенно внедрения SQL-кода и то, как это предовратить.
• Никогда не доверяйте пользовательскому вводу, ни тем более всему том, что указано в запросе (которое может включать куки и спрятанные от поля значения!).
• Используйте пароли, используя соль и другие различные соли для ваших строчек в базе данных для предотвращения «радужных атак». Используйте медленный алгоритм хеширования, такой как bcrypt (проверенный временем) или scrypt (даже сильнее, но новее) (1, 2) для хранения паролей. (Посмотрите статью «Как безопасно хранить пароли»). организация NIST также одобряет использования PBKDF2 вместо хешированных паролей, и организация FIPS одобрила такой способ в .NET (больше информации на эту тему здесь). Избегайте испрользования алгоритма MD5 или семейства алгоритмов SHA напрямую.
• Не пробуйте создавать свои собственные необычные системы аутентификации. Очень легко ошибиться в хитроумных и непроверенных способах и вы даже не узнаете об этом до того, как вас взломают.
• Узнайте о правилах для обработки информации с кредитных карт. (Посмотрите также этот вопрос.)
• Используйте SSL/HTTPS для входа и для других страниц, где вводится важная информация (например, информация о кредитной карте).
• Предотвращайте TCP hijacking.
• Отстерегайтесь межсайтового скриптинга (XSS).
• Отстерегайтесь межсайтовую подделку запроса (CSRF).
• Отстерегайтесь кликджекинга.
• Держитесь в курсе последних патчей для вашей системы.
• Удостоверьтесь, что информация о подключении к базе данных в безопасности.
• Будьте в курсе самых последних техник атак и уязвимостей, воздействующих на вашу платформу.
• Почитайте The Google Browser Security Handbook.
• Почитайте The Web Application Hacker's Handbook.
• Рассмотрите принцип минимальных привилегий. Попробуйте запустить сервер вашего приложения не как суперпользователь. (пример tomcat)

Производительность

• Реализуйте кеширование в случае необходимости, поймите и используйте HTTP кеширование должным образом, как и манифест HTML5.
• Оптимизируйте картинки: не используйте изображение размером 20 KB для повторяющегося фона.
• Изучите как сжимать содержимое с помощью gzip/deflate (deflate лучше).
• Комбинируйте/соединяйте несколько CSS-файлов или несколько скриптов в один, чтобы уменьшеить количество соединений с браузером и улучшить способность gzip сжимать дупликаты среди файлов.
• Посмотрите на подборку материалов от Yahoo по производительности, включающую хорошие требования и производительность фронт-енда и их инструмент YSlow (для использования нужны Firefox, Safari, Chrome или Opera). Также Google page speed (используйте дополенение к браузеру) — другой инструмент для проверки производительности и он оптимизирует изображения тоже.
• Используйте CSS Image Sprites для маленьких изображений как тулбары (обратите внимание на пункт "минимизация HTTP запросов")
• Для разработки деловых веб-сайтов рассмотрите разделение компонент среди доменов.
• Статический контент (такие как картинки, CSS, JavaScript и общее содержание, не нуждающееся в куки) должно идти на отдельный домен, который не нуждается в куки, потому что все куки для домена и его поддоменов посылаются с каждым запросом к домену и поддомену. Одна хорошая опция здесь — это использовать Content Delivery Network (CDN), но рассмотрим случай, где CDN может упасть вместе со всеми альтернативыми CDN или локальные копии, которые могут быть доставлены вместо этого.
• Минимизируйте общее число HTTP-запросов, которые нужны браузеру для показа вашей страницы.
• Используйте компилятор Closure от Google для JavaScript'a и другие инструменты минификации.
• Удостоверьтесь, что у вас есть файл favicon.ico в корневой папке вашего сайта, т.е. /favicon.ico. Браузеры будут автоматически запрашивать его, даже если иконка не указана в HTML совсем. Если у вас нет /favicon.ico, то в результате будет много вызвано страниц 404, что повлияет на пропускную способность вашего сервера.

SEO (Поисковая оптимизация)

• Используйте "дружелюбные для поисковика" URL'ы, например, example.com/pages/45-article-titleвместо example.com/index.php?page=45
• Когда используется # для динамического контента, измените # на # !, и тогда на сервере $_REQUEST["_экранированный_фрагмент_"] — это то, что гуглбот использует вместо # !. Другими словами ./# !page=1 становится ./?_экранированные_фрагменты_=page=1. Также для пользователей, использующих FF.b4 или Chromium, history.pushState({"foo":"bar"}, "About", "./?page=1"); — хорошая команда. Таким образом, даже если адресная строка изменилась, страница не обновляется заново. Это позволяет использовать  ? вместо # !, чтобы оставить в покое меняющееся содержание.
• Не используйте ссылки, которые пишут что-то вроде "нажмите здесь". Вы тратите впустую возможность поискового продвижения и такие ссылки усложняют жизнь людям со screen reader'ами.
• Сделайте карту сайта на XML, желательно в корневой папке /sitemap.xml.
• Используйте <link rel="canonical" ... />, когда у вас есть несколько ссылок, указывающих на один и тот же контент, эта проблема также рассмотрена здесь Google Webmaster Tools.
• Используйте Google Webmaster Tools и Bing Webmaster Tools.
• Установите Google Analytics прямо в начале (или какой-нибудь опенсорсный инструмент вроде Piwik).
• Почитайте про то, как robots.txt и поисковые пауки работают.
• Перенаправляйте запросы (используя код 301 Moved Permanently), спрашивующие www.example.com к example.com (или каким-нибудь еще способом) для предотвращения раздробления ранжирования гугла между двумя сайтами.
• Держите в голове, что существуют поисковые пауки, которые плохо себя ведут.
• Если у вас есть нетекстовый контент, загляните в дополнение Google для построения карты сайта для видеоконтента и т.д. Также немного хорошей информации можно найти в одном из ответов на сайте.

Технология

• Поймите HTTP-протокол и такие вещи, GET, POST, сессии, куки и что означает протокол «stateless».
• Напишите ваш XHTML/HTML и CSS согласно спецификациям W3C и удостоверьтесь, что они валидны. Цель здесь — избежать причуды брузера и в качестве бонуса сайт будет легче заставить работать на скрин ридерах и мобильных устройствах.
• Понимайте как Javascript-код обрабатывается в браузере.
• Понимайте как JavaScript, стили и другие ресурсы используются для того, чтобы страница загрузилась и рассмотрите их влияние на полученную производительность. Широко распространена практика перемещать подключенные скрипты вниз ваших страниц за исключением приложений для аналитики и библиотек для поддержки совместимости HTML5 во всех браузерах.
• Понимайте как работает JavaScript-песочница, особенно, если вы намеренны использовать iframe'ы.
• Будьте готовы к тому, что JavaScript может быть и будет отключен и что AJAX поэтому будет дополнением, а не основанием. Даже если обычные пользователи разрешат выполнение JS, помните, что расширение NoScript становится все более популярным, мобильные устройства могут не работать, как ожидалось и Google не запустит большинство ваших скриптов во время индексации сайта.
• Изучите разницу между перенаправленями 301 и 302 (это также и к вопросу о поисковой оптимизации).
• Изучите как можно больше о вашей платформе для развертки.
• Рассмотрите использование Reset Style Sheet или normalize.css.
• Рассмотрите Javascript фреймворки (такие как jQuery, MooTools, Prototype, Dojo или YUI 3), которые спрячут многие специфические для браузеров особенности использования Javascript для манипуляции DOM.
• Осозновая проблему производительности и использование JS фреймворков, рассмотрите использование таких сервисов как Google Libraries API, чтобы загружать фреймворки, таким образом браузер может использовать копию фреймворка, которые он уже кешировал вместо того, чтобы загружать копию с вашего сайта.
• Не изобретайте велосипед. Прежде чем что-то делать, поищите компоненту или пример того, как это делать. 99% вероятность того, что кто-то делал это до вас и выпустил готовую работающую версию кода.
• С другой стороны, не начинайте с подключения 20 библиотек, прежде чем вы не определитесь со своими нуждами. Особенно на клиентской стороне очень важно делать вещи легкими, быстрыми и гибкими.

Исправление ошибок

• Поймите, что вы потратите 20% своего времени на кодинг и 80% на поддержку кода, поэтому пишите код соответствующе.
• Установите хорошую систему для уведомлении об ошибках.
• Поставьте систему, где люди смогут с вами связаться с предложениями и критикой.
• Документируйте то, как работает приложение для будущей команды поддержки и людей, осуществляющих будущую поддержку проекта.
• Делайте частые бекапы! (и удостоверьтесь, что эти бекапы смогут функционировать) Имейте стратегию восстановления, а не только стратегию бекапа.
• Пользуйтесь системой контроля версий, такой как Subversion, Mercurial или Git.
• Не забывайте тестировать. Фреймворки как Selenium могут помочь. Особенно если вы полностью автоматизируете тестирование, возможно с использованием инструмента непрерывной интеграции, таким как Jenkins.
• Удостоверьтесь, что у вас происходит подробное логгирование с использованием таких фреймворков, как log4j, log4net или log4r. Если что-то идет не так с вашим живым сайтом, вам легко будет узнать что именно.
• В процессе логгирования удостоверьтеся, что идет запись как предусмотренных исключений, так и непредусмотренных. Записывайте и анализируйте вывода логгирования, и это покажет вам, какие ключевые проблемы есть на вашем сайте.

Другое

• Реализуйте как серверную, так и клиентскую часть мониторинга и аналитики (они должен быть скорее активные, чем реактивные).
• Используйте сервисы как UserVoice и Intercom (или любые другие похожие инструменты) для того, чтобы быть в контакте с вашими пользователями.
• Почитайте книгу «Модель ветвления Git», написанную Vincent Driessen