Я был поражен ответом на мою недавнюю статью « 10 распространенных ошибок новичков» . Я ожидал сердитую толпу, собирающуюся за пределами штаб-квартиры SitePoint с вилами и пылающими факелами. Ну, я ожидал, по крайней мере, несколько зажигательных комментариев.
Пришло время восстановить баланс и дать веб-разработчикам немного шумихи. Будут ли они такими же открытыми? Готовы ли они принять небольшую критику? Очевидно, что эта статья не нацелена на вас … вы читатель SitePoint, который уже использует передовые методы. Он содержит список типичных ошибок, допущенных новыми веб-разработчиками, но мы все были новичками одновременно. Некоторые моменты могут также относиться к тому антагонистическому со-разработчику, который отказывается принять любое мнение, что их код не совершенен …
1. Игнорирование веб-стандартов
Веб-стандарты были придуманы не просто так: они помогают создавать независимые от устройств веб-сайты и приложения. Мало кто хочет их изучать, не всем они нравятся, и большинство разработчиков не согласятся с некоторыми аспектами — но игнорируйте их на свой страх и риск!
Начинающий разработчик сделает типичные ошибки, такие как:
- забыть или использовать неподходящие DOCTYPE. Я до сих пор не понимаю, почему так много разработчиков используют переходный DOCTYPE — действительно ли они хотят добавить теги
font - с использованием старой школы HTML, такой как макеты таблиц и
center - не ценить тонкости встроенных или блочных элементов, например, помещая заголовки
h2span - не проверяя их код. Или еще хуже, используя валидатор, игнорируя результаты и утверждая, что валидаторы изначально несовершенны.
2. Визуализация визуальных элементов
Вы полагаетесь на программное обеспечение WYSIWYG? Вы избежали изучения HTML? Извините — вы не веб-разработчик.
Программное обеспечение WYSIWYG заставляет вас думать визуально — вы будете сосредоточены на том, как выглядит страница, а не на структуре контента. Используйте текстовый редактор и рассмотрите уровень представления на более позднем этапе.
3. Семантика, семантика
Вот как новичок веб-разработчик будет кодировать основной заголовок страницы:
<h1>Main Heading</h1>
К сожалению, многие разработчики тогда сходят с ума со своими недавно открытыми возможностями HTML и в конечном итоге сталкиваются с таким чудовищем:
<div class="mainheading" style="color:black;"><strong>Main Heading</strong></div>
Они были в самом начале. HTML предоставляет большинство тегов содержимого, которые вам требуются (особенно если вы перешли на HTML5). Используйте их соответствующим образом.
Вам также следует остерегаться дивитита и классицизма: решение для начинающих разработчиков проблем с браузером. Пришло время остановиться и переосмыслить ваш код, когда ваш HTML начинает выглядеть следующим образом …
<div id="content">
<div id="main-content" class="main">
<div class="first-item">
<div class="para1">
<p id="top-para" class="para">Hello World!</p>
</div>
</div>
</div>
</div>
4. Практика имен презентационных классов
Имена презентационных классов — еще один кардинальный грех, например
<div id="blue-left-column-96px">...</div>
Это изначально кажется логичным — это самодокументируемый код. Это замечательно, пока ваш дизайн не изменится, и блок не станет красным столбцом с выравниванием вправо на 150 пикселей.
5. Ленивое тестирование браузера
Я открою тебе маленький секрет. Вы знаете, как разработчики жалуются на IE6? Ну, любой веб-сайт или приложение можно заставить работать в древнем браузере Microsoft. Конечно, это занимает дополнительное время, и в браузере есть ошибки, но все они хорошо документированы. Часто проще исправить сайт для IE6, чем для IE7.
Однако, оставив тестирование IE6 до конца проекта, это не принесет конца печали. Исправлять проблемы с браузером — это не весело, и это то, на что действительно жалуется ваш разработчик.
Конечно, это не только IE6 — во всех браузерах есть ошибки, причуды и проблемы. Если вы тестируете раньше и тестируете часто, большинство проблем можно устранить на этапе разработки. К сожалению, ленивый начинающий разработчик будет:
- тестирование в одном браузере на протяжении всего процесса разработки
- тратить больше времени на то, чтобы убедить людей в том, что другие браузеры — мусор, а не исправление их приложения
- и, если у них нет другого выбора, они будут внедрять ужасные быстрые исправления, используя сниффинг в браузере и хаки.
6. Не обращая внимания на портативность
Начинающий разработчик будет использовать фиксированные пути к файлам, жестко запрограммированные строки подключения к базе данных и делать предположения об окружающей среде. Их приложение завершится сбоем, если оно не будет помещено в папку с именем «MyApplication1» в корне веб-сервера IIS, на котором работает PHP с включенным register_globals. О да, и он подключается к базе данных Access, работающей на их ПК.
Идеальное веб-приложение должно быть необслуживаемым:
- он должен работать везде, где находятся файлы
- параметры конфигурации должны содержаться в одном легко редактируемом файле
- при необходимости он должен работать на разных комбинациях ОС и веб-сервера.
Как примечание, будьте осторожны с сессиями. Они могут поймать вас, когда ваше популярное приложение перейдет на платформу хостинга на нескольких серверах.
7. Чистка полосы пропускания
Проблема с тестированием на локальном ПК-сервере заключается в том, что проблемы с пропускной способностью обычно не заметны, и ваше фоновое изображение размером 4 МБ появится в одно мгновение. Включение 27 различных библиотек JavaScript — на случай, если они могут вам понадобиться — тоже не вызовет никаких задержек.
Начинающему разработчику наплевать на пропускную способность. На самом деле, я немного обеспокоен тем, что наш недавний опрос SitePoint показал, что 23% разработчиков не заботятся о пропускной способности. Я уверен, что они, должно быть, были разработчиками интранета …
8. Ужасная доступность
Для начинающего разработчика доступность == атрибуты изображения alt. Это все равно что предполагать, что вы можете управлять автомобилем, потому что вы успешно настроили автомобильную стереосистему.
Доступность подразумевает поддержку нескольких устройств с различными техническими возможностями, например мобильных телефонов, программ чтения с экрана, браузеров без JavaScript, отсутствующих Flash-плагинов или систем без мыши. Это не всегда высокий приоритет — никто не будет использовать онлайн-редактор видео в программе чтения с экрана — но есть несколько оправданий для контент-сайтов. Например, если виджеты, формы или ссылки на вашей странице основаны на JavaScript, вы просто блокируете процент своей аудитории.
9. Ускорение SEO
Я частично обвиняю это в индустрии поисковой оптимизации. SEO представлен как смесь психоанализа, технической сложности и таинственных черных искусств. Компании платят вымогательские суммы за колдовство SEO — они не имеют ни малейшего представления, за что они заплатили, что было сделано или имеют какие-либо гарантии успеха.
Поэтому начинающие разработчики полагают, что SEO — это слабое умение, которое лучше всего оставить отделу маркетинга после запуска сайта. Это слишком поздно — SEO следует планировать с самого начала, как и любой другой аспект проекта.
Теперь я собираюсь раскрыть еще один секрет индустрии: большинство техник SEO очевидны . (Это был звук тысячи консультантов по продажам SEO, опрокидывающихся?)
Если вы продаете Green Dooberries, обязательно упомяните об этом, особенно в заголовках и URL. Придерживайтесь стандартов, проведите небольшое исследование ключевых слов, создайте достойный контент, добавьте карту сайта, отправьте сайт в поисковые системы, и все готово на 90%. Забудьте о ключевых словах и других хитростях: они не будут работать.
10. Бесполезная модернизация
Почему веб-сайты и сервисы исчезают на несколько часов из-за «необходимого обслуживания» ? Я могу понять это, когда происходит сбой оборудования или вы становитесь жертвой атаки типа «отказ в обслуживании», но обычные задачи обслуживания никогда не должны требовать более чем нескольких минут простоя. Все файлы и данные могут быть загружены, протестированы, а затем переключены в одно мгновение.
Кроме того, если у вас одинаковый контент, ваши пользователи никогда не должны видеть страницу 404. URL-адреса могут измениться, но старые адреса легко перенаправить на новые места.
11. Бонусные ошибки
Вот коллекция рантов, которые не попали в мой основной список:
- небольшая оценка клиент-серверных методологий. Это особенно очевидно, когда разработчики настольных компьютеров начинают программировать для Интернета — я знаю одного, кто написал компонент, который может быть использован только одним посетителем сайта одновременно!
- цитирование статистики как оправдание игнорирования или не тестирования в некоторых браузерах
- не использовать контроль источника, когда это важно
- постоянно переписывать и рефакторинг одного и того же кода
- часами рассуждаю, почему технология X лучше, чем технология Y, а не выполняет задачу
- разработчики, которые постоянно не в состоянии решить реальную проблему, чтобы они могли сосредоточиться на легкомысленных вопросах, которые более интересны
- очень недооценивает время разработки
- используя дубликаты идентификаторов на одной странице HTML
- используя кнопки сброса формы — когда кто-нибудь когда-либо нуждался в этом?
- полагаться на раздутые библиотеки, когда несколько строк JavaScript будет достаточно
- не проверяет вводимые пользователем данные или предполагает, что проверка на стороне клиента является адекватной
- использование JavaScript для применения эффектов, которые будут лучше обрабатываться CSS
- не играет хорошо с другим кодом JavaScript
- чрезмерное использование или неправильное использование Ajax
- создание отдельных файлов CSS для каждого браузера (не только условные комментарии IE6 / 7)
- добавляя встроенные стили везде
- нецелевое использование Flash
- использование изображений, когда HTML-текст и CSS-эффекты могут достичь одного и того же
- забыв добавить цвет фона для
body - используя туманный технический жаргон, чтобы сбить с толку клиентов и сотрудников.
</ Истекшим декламация>
Я пропустил ваши самые раздражающие ошибки начинающего веб-разработчика? Вы не согласны с какими-либо точками? Пусть начнется обратная реакция!…