[Перевод] 10 частых ошибок начинающих веб-разработчиков
Перед современным веб-разработчиком стоит широчайший выбор платформ для хостинга и хранения данных, инструментов для работы с HTML, CSS и JavaScript, способов фактической реализации дизайна, а также всевозможных библиотек и фреймворков. В помощь тем, кто хочет найти свой путь в этом обилии вариантов, сеть услужливо предоставляет массу статей, обсуждений на форумах и примеров «наилучших» решений. Но вне зависимости от того, как и с помощью чего начинающие разработчики создают сайты, многие совершают одни и те же ошибки. Давайте рассмотрим некоторые из них, чтобы в будущем не наступать на эти популярные грабли.
Использование старого HTML
Ошибка: На заре интернета было куда меньше возможностей по оформлению страниц, чем сегодня. Но старые привычки трудно изжить, и многие разработчики всё ещё пишут на HTML так, словно они застряли в 1990-х. Например, используют <table> для создания макета страницы; применяют <span> или <div> в случаях, когда более уместны иные, более подходящие к содержимому тэги; используют тэги, не поддерживаемые текущим стандартом HTML (например, <center> или <font>); или применяют для разделения элементов большое количество .
Последствия: Использование HTML десятилетней «свежести» может привести к излишнему усложнению разметки страницы и, как следствие, к непредсказуемости её отображения в разных браузерах. И далеко не только в Internet Explorer.
Как избежать: Для начала перестаньте использовать <table> для создания структуры страницы и применяете его только для вывода табличных данных. Ознакомьтесь с более современными инструментами. Используйте HTML для описания самого контента, а не способов его отображения. А для корректного отображения применяйте CSS.
«У меня в браузере всё работает»
Ошибка: Вероятно, вы горячий поклонник какого-то браузера и предпочитаете тестировать в нём все свои работы. Возможно, что вы также используете найденные в сети куски кода, которые писались без учёта совместимости с разными браузерами. Кроме того, в разных браузерах для стилей приняты разные значения по умолчанию.
Последствия: Будьте готовы к тому, что сайт, «заточенный» под один браузер, в других будет выглядеть просто ужасно.
Как избежать: Конечно, тестировать свой сайт во всех существующих браузерах и их версиях было бы пыткой. Но нужно хотя бы периодически проверять, как ваш сайт выглядит в некоторых наиболее популярных браузерах. Сегодня для этого есть бесплатные инструменты: виртуальные машины, сканеры сайтов. Например, с помощью http://browsershots.org/ или https://www.browserstack.com/ можно сделать снэпшоты того, как будет рендериться конкретная страница на всевозможных платформах. Работая с CSS, убедитесь, что «сбросили» все значения по умолчанию.
Кстати, если вы используете какие-то специфические CSS-решения, заточенные под конкретные браузеры, то обратите внимание на характерные для разных вендоров префиксы вроде -webkit-, -moz- или -ms-. Чтобы быть в курсе текущих тенденций, можете изучить эти ссылки:
A break from the past, part 2: Saying goodbye to ActiveX, VBScript, attachEvent
CSS vendor prefixes considered harmful
On Internet Explorer supporting -webkit- vendor prefixes
Там описывается, почему стоит отойти от использования подобных префиксов. Практические рекомендации, как работать без префиксов, можно найти здесь: http://davidwalsh.name/goodbye-vendor-prefixes.
Плохие формы ввода
Ошибка: Предложить пользователям ввести какие-то данные (особенно в текстовые поля) и ожидать, что они введут их именно в том виде, в каком нужно.
Последствия: Если вы возлагаете на пользователей ответственность за корректность вводимых данных и правильность формата, то это приведёт к непредсказуемым последствиям. Могут возникать сбои или ошибки несовместимости, вас даже могут попытаться взломать.
Как избежать: Во-первых, удостоверьтесь, что вы безошибочно донесли до пользователей, какая именно информация вам от них нужна. Если вы просите ввести «адрес», то уточните, какой: рабочий, домашний, электронный? Чтобы дополнительно подстраховаться, используйте проверку корректности вводимых данных. Неважно, как это будет сделано на стороне браузера, главное, чтобы на сервере были уже проверенные данные. Никогда не используйте сцепленные T-SQL выражения для работы с полученными от пользователей данными без подтверждения корректности по каждому полю ввода.
Слишком большие ответы на сетевые запросы
Ошибка: Страница, заполненная многочисленными изображениями в высоком разрешении, уменьшенными с помощь атрибутов высота и ширины тэга <img>. Слишком большие CSS- и JS-файлы, залинкованные со страницы. Излишне сложный и громоздкий исходный HTML-код.
Последствия: Если ваша страница слишком долго грузится/отображается, то это может заставить многих пользователей не дождаться завершения и закрыть вкладку или нетерпеливо обновлять страницу. Иногда излишне долгое ожидание загрузки может привести к возникновению ошибок.
Как избежать: Не думайте, что раз интернет из года в год становится быстрее, то это оправдывает раздувание размеров страниц. Вместо этого оптимизируйте свои проекты ради ускорения обмена сетевыми пакетами. Основная причина, по которой страницы становятся «тяжёлыми», — изображения. Чтобы минимизировать их влияние:
- Спросите себя, действительно ли необходима вся используемая вами графика? Откажитесь от ненужных графических украшательств. Можно воспользоваться сетевыми инструментами, чтобы определить, какие изображения нуждаются в дополнительном сжатии.
- Уменьшите размер изображений. Например, с помощью Shrink O’Matic или RIOT.
- Используйте предзагрузку. Это не ускорит первичную загрузку, но зато даст преимущество при просмотре других страниц сайта. Подробности можно почерпнуть из статьи: https://perishablepress.com/3-ways-preload-images-css-javascript-ajax/
Миницифируйте залинкованные CSS- и JS-файлы. Для этого есть множество инструментов, например, Minify CSS и Minify JS.
И наконец, старайтесь использовать наиболее современную версию HTML и внимательно используйте тэги <style> и <script>.
Создание кода, который должен работать
Ошибка: Тестирование проекта на сервере и развёртывание без последующей проверки, работает ли он после этого. Хотя сайт работал без ошибок, потому что его тестировал сам разработчик.
Последствия: Без нормального тестирования развёрнутых сайтов может случиться так, что пользователи столкнутся с весьма неприятными ошибками. Мало того, что сайт может работать совершенно некорректно, так ещё могут появиться лазейки для хакеров.
Как избежать: Необходимо принять как данность, что людям свойственно ошибаться. В том числе и вам. Если вы пишете на JavaScript, то применяйте грамотные методики для предотвращения и поиска ошибок. Можно воспользоваться большинством советов из этой статьи: http://www.palermo4.com/post/JavaScript-for-Windows-Store-Apps-Error-Handling.aspx, несмотря на то, что она предназначена для JS-разработчиков Windows-приложений. Также хорошим подспорьем в создании качественного кода будет модульное тестирование.
Все ошибки на бэкенде нужно обрабатывать так, чтобы пользователи не становились свидетелями подробностей. Выводите только то, что необходимо, и создайте правильную страницу 404.
Написание ветвящегося кода
Ошибка: Ради великой цели обеспечить поддержку всех браузеров и их версий, многие разработчики создают код, обрабатывающий все возможные сценарии. В результате он превращается в хаотичную кучу операторов if.
Последствия: С выходом новых версий браузера вам будет всё труднее поддерживать проект, он будет всё более громоздким.
Как избежать: Внедрите в код обнаружение по характерным признакам, а не проверку браузера/версии. Это позволит очень сильно уменьшить объём кода, сделает его более читабельным. Например, можно воспользоваться библиотекой Modernizr, которая поможет автоматически поддерживать старые браузеры, не знакомые с HTML 5 или CSS 3.
Неадаптивный дизайн
Ошибка: При создании сайта разработчики и дизайнеры используют мониторы одного размера/разрешения.
Последствия: Вряд ли нужно кому-то объяснять, что на экране ноутбука и смартфона сайты выглядят очень по-разному. И решения, подходящие для больших экранов, совершенно не годятся для мобильных устройств. Бывает и так, что на маленьких экранах сайтом невозможно пользоваться, поскольку ряд важных элементов становится недоступным.
Как избежать: Адаптивный дизайн — наше всё. В сети есть много публикаций на эту тему, включая работу с адаптивными изображениями. Одной из наиболее популярных библиотек для адаптивного дизайна является Bootstrap.
Создание «бесполезных» страниц
Ошибка: Страницы, наполненные полезным контентом, но совершенное недружественные к поисковикам. Не внедрены специальные возможности для слабовидящих пользователей.
Последствия: Страницы, по которым не могут путешествовать поисковые боты, будут иметь очень низкую посещаемость, если она вообще будет. Содержимое страницы может быть практически не читаемо для пользователей со слабым зрением.
Как избежать: Используйте SEO и поддержку специальных возможностей в HTML. Добавляйте в тэги ключевые слова и описания. В частности, об этом хорошо написано на About Tech. Чтобы помочь пользователям, которые не могут похвастаться орлиным зрением, добавляйте ко всем изображениям описание с помощью атрибута alt; есть ещё немало советов на эту тему. Можете также протестировать свои страницы с помощью Cynthia Says на предмет соответствия Section 508.
Слишком много обновлений страницы
Ошибка: Создание сайтов, которые для каждого действия требуют полностью обновить страницу.
Последствия: Аналогично тому, что бывает в случае со слишком большими ответами на сетевые запросы — страдает производительность, увеличивается время загрузки. Пользователи будут недовольны, потому что из-за каждого «чиха» им придётся ждать очередной загрузки.
Как избежать: Определите, действительно ли нужно каждый раз обращаться к серверу? Иногда скрипты на клиентской части можно использовать для немедленного предоставления данных пользователю. Также очень популярна технология AJAX. Можно пойти ещё дальше и применить методику SPA. С внедрением этих подходов вам помогут различные библиотеки, например, JQuery, KnockoutJS, AngularJS.
Работа с рассвета до заката
Ошибка: Вы тратите очень много времени на создание веб-контента, на повторяющиеся задачи, или просто на набор текста и кода.
Последствия: На запуск и дальнейшие обновления сайта уходит слишком много времени. И если другие разработчики за тот же промежуток времени делают гораздо больше, то ваша ценность как специалиста снижается. Чем больше ручного труда, тем выше вероятность ошибок, которые тоже потребуют времени на устранение.
Как избежать: Изучите доступные возможности. Выберите новые инструменты или методики для каждого этапа разработки. Может быть, ваш редактор кода далеко не идеален и есть куда более удобные приложения, позволяющие экономить время? Насколько хорошо вы знаете и используете возможности своего редактора? Возможно, стоит немного покопаться в документации, чтобы открыть для себя новые возможности и в дальнейшем экономить ценные минуты, а то и часы на выполнении каких-то задач?
Также обратите внимание на разнообразные веб-инструменты. Скажем, средства для упрощения процесса тестирования на разных платформах и устройствах. Экономить время можно и с помощью автоматизации процессов: например, Grunt может автоматизировать минификацию файлов, а Bower облегчает управление библиотеками и фреймворками.
* * *
Бывает, что даже достаточно опытные веб-разработчики допускают какие-то из вышеописанных ошибок. И важно не только знать, чего нужно избегать, но и понимать возможные последствия тех или иных неверных решений. Это позволит упростить и облегчить процесс разработки, создавая действительно качественные и приятные в использовании сайты.
