×Закрыть

13 способов не делать отстойных веб-приложений

Оригинал

Я начинаю уставать ходить по интерактивным сайтам и обнаруживать, какой они мега-ацтой. Это особенно раздражает в случае компаний из списка Fortune 500 (вроде Bell/AT& T/что угодно — как их окрестили yellowpages.com). Все это дело не хитрое (not a rocket science), однако я поражен тем, какие говеные сайты делают компании с тугими кошельками. Это твоё лицо, ты пошел бы на свидание с грязным пятном во лбу или cо шпинатом на зубах?

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

1. Положи JavaScript и CSS в полагающееся им место

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

2. Используй сжатие

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

3. Если ты помещаешь DocType в свой код, сделай валидацию

Среди всего прочего в инете, корявый HTML встречается чаще всего. Зачем писать DocType на каждой странице и затем отдавать невалидный текст? Я всегда пишу на strict XHTML, даже если он не отдается в этом качестве, просто для того, чтобы быть уверенным, что он хорошо написан. Это вопрос дисциплины. Используй веб-девелоперский инструментарий или FireBug и все время проверяйся. Мне все равно, что ИЕ6 правильно показывает твой сайт. Держу пари, что ИЕ7 — нет. Зачем покупать автомобиль, который ездит только по асфальту, но по бетону — никогда?

4. Не выставляй свое грязное белье напоказ

Если твое приложение качественно протестированно (у тебя ведь есть QA, да?), конечный пользователь не должен когда-либо увидеть сообщение об ошибке. Господь не велит твоему коду выкидывать исключения и заблевывать пользователя отладочной инфой. Один сайт, на который я зашел, сломался и тут же показал мне страницу, полную всех переменных сервера и приложения, которые он только смог найти, и для красоты запихнул это всё в комменты на этой странице. Я видел такое множество сообщений типа «Невозможно подключиться к базе данных» или «Вылет по таймауту во время работы с БД», что казалось, что я присутствую на соревнованиях. И обычно так и было.

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

Что бы ты не делал, не включай тестовый код и рабочие комментарии в текст страницы или код JavaScript. Сайт yellowpages.com вызывает свой unittest.js файл на каждой странице. Я не хочу быть их тестером.

5. Сделай современный веб-дизайн

Сайт на базе таблиц — это такое средневековье... До сих пор тут и там натыкаюсь на плоды старого дизайна. Dreamweaver — твой враг. Если твои веб-дизайнеры не могут ручками делать сайты, используя современные технологии, и помещать стили в CSS, не подпускай их к Dreamweaver, пока они не научаться этому. Существуют миллионы сайтов, посвященных теме современного веб-дизайна, так что нет тебе прощения, если ты это не изучил. Если ты не можешь вручную писать HTML, то одно чтение статей впечатления не произведет. Веб-дизайн — это программирование + искусство. Доступность, удобство в использовании и масштабируемость даются легче, если делать дела современными методами, а также трактовать это как инженерную задачу.

6. Поддерживай все современные броузеры

Все равно их немного. Кроме IE6 и IE7, все остальные броузеры в общем похожи. Говорить, что ты поддерживаешь только IE6 — глупо в наше время, когда существуют две достаточно разные версии, в частности, IE7, являющийся чем-то приближенным к другим (но все ещё накрученный слишком по-своему). Пиши код по стандарту, адаптируй для IE6 и IE7.

Будешь ли ты покупать что-то в магазине с вывеской «Только для белых! »? Нет, вот и я не хочу покупать что-либо в онлайновом магазине, гласящем «Только IE». И ещё хуже, когда кое-где тебе не говорят, что твой броузер не поддерживается, до последней минуты. Это как если бы ты пошел в магазин, заполнил тележку, а кассир тебе и говорит «Таких, как ты, не обслуживаем». Не слишком умно говорить покупателям отвалить. Потому что они так и сделают.

7. Если твое приложение имеет особые требования, предварительно сделай проверку

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

8. Протестируй удобство использования на реальных пользователях

Удивительно, как много есть сайтов, с которыми трудно работать. Иногда я задумываюсь, есть ли кто-то, кроме разработчика, кто может использовать данный сайт под свои нужды. Если ты предлагаешь функцию поиска, можно кто-либо найти что-то полезное на сайте? Твоя навигация понятна? Как-то я искал систему безопасности для своих дверей и застрял на сайте Honeywell, где не смог найти ничего хоть сколько-нибудь полезного, и в итоге сдался после нескольких бесплодных попыток. Затем я отправился к их конкурентам. Разработчики, народ из QA, менеджеры и прочие не являются пользователями. Если я не могу найти то, что мне нужно, на твоем сайте, то как сможет моя мама?

9. Используй реальную базу данных

Access не является реальной БД. И FoxPro. Если не можешь себе позволить (или не хочешь покупать) что-то типа Oracle, тогда используй MySQL, или даже лучше Postgres (или мою любимую H2). Access — игрушка. Ты поедешь на газонокосилке по автостраде? Я всегда удивлялся компаниям, у которых критически важная информация хранится на чьем-то рабочем столе в Access-базе. И я даже не хочу вспоминать про ребят, которые правят данные через расшаренные листы Excel.

10. Не используй специальные фичи платформы

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

11. Осознай, что у твоих пользователей нет T3-канала

Средняя страница-директория на amazon.com весит примерно 350 Кб и требует 43 отдельных HTTP-запроса. Пфф... По крайней мере 20% (или даже больше) людей только в США до сих пор сидят на диалапе. Один приятель днем работает на магистральном коммутаторе, а потом идет домой, где у него только диалап.

Сжимай, комбинируй и кэшируй где только возможно. Я обнаружил, что у меня больше всего инета уходит на prototype.js. Как только я сжал его и стал отдавать в таком виде, он вообще почти пропал из списка. Только то, что у меня канал 6 Мб/сек, не означает, что ты не платишь за него со своей стороны. Большинство броузеров создают только 2 соединения за раз, так зачем все усложнять для себя и своих пользователей.

12. Подумай об доступности и интернационализации заранее

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

13. Тестируй рано, тестируй часто

Ты тестируешь свое веб-приложение? Тестирование должно начинаться задолго до того, как он будет закончен. Тестируй код, тестируй базу, тестируй удобство использования, тестируй рабочее окружение и инфраструктуру. Тестируй так, как если бы все твои пользователи тебя покинули, как только ты облажаешься (а они так и сделают!). Тестируй под все основные броузеры. На своем Macbook Pro я могу запустить IE6, IE7 (мне требуется немного больше места на диске), Firefox, Safari и Opera. Я уверен, что компания из списка Fortune 500 может позволить себе и больше.

Если ты сделаешь все эти вещи, тогда жизнь будет простой, люди будут любить тебя, ты станешь богатым, и будет тебе счастье.

Может быть, а может и нет; зато теперь ты знаешь, что твое приложение — не аццтой.

  • Популярное

29 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

О сжатии: http://www.computerra.ru/gid/2.../Цитата: ...сервер сжимает отсылаемое содержимое методами gzip или deflate с тем, чтобы клиент распаковал его на месте. Это загружает процессор как на клиенте, так и на сервере, однако уменьшает объем передаваемых данных. Это нормально. Однако вот как работает mod_gzip: он сжимает данные во временный файл на диске, а после отсылки данных удаляет этот файл. На больших системах вы очень быстро столкнетесь с ограничениями скорости ввода/вывода. Этого можно избежать, используя вместо mod_gzip mod_deflate (только в Apache 2), поскольку последний сжимает данные в оперативной памяти. Пользователи первой версии Apache могут создать RAM-диск и хранить временные файлы mod_gzip там — это не так быстро, как работа напрямую с оперативкой, но намного шустрее, чем писать все на жесткий диск.

2 Сергей: да вроде литературно и старался. Странно, что многим не понравилось. ОК, буду иметь ввиду.2 deinstal: да, красиво. (вместо детского сада — дзенский:))

Хехе... Автору РЕСПЕКТ.CSS в коде... Народ что за детский сад?... Советую познакомится с CSS Zen Garden, уверен мнение у вас поменяется. Так как такие фишки, как там показаны, вы никогда в жизни ни сделаете на таблицах и лепя CSS стили в код.

Переводчику: прямой перевод текста это полный остой, используйте литературный перевод.Про статью: 1, 3, 8 и 9 пункты вообще какие-то левые, так же достали тупые задроты помешанные на дивах.

Вот насчет «в меру» я и попытался сказать. Автор смело называет отстоем то, что не вписывается в его крайности. Неуд.

А еще, чтобы уменьшить количество реквестов к серваку — можно написать css и js в одном файле.Но это как по мне — изврат:)

Имхо, всего должно быть в меру.Конкретная задача ставит свои условия.Если ситуация требует использования включения css и js в код, то почему бы так и не сделать?

>>> JavaScript и CSS должны храниться в отдельных файлах, а не включены в код страницы>> очень спорно.> Почему? Кэширование — зло для девелопера? Какое там зло, просто манна небесная...Ситуация — страница редко посещается каждым пользователем, но посетителей много, скрипт размером в сто байт, сжатие включени, зачем этот единственный скрипт выносить в отдельный файл — что это даст? Работу в целом замедлит, трафик и кеш увеличит. В чем прикол этой манны?

Прочитал, думал может чего-нибудь умное и полезное — ан нет, все тоже старое и много раз описанное. Причем с некоторыми моментами не согласен, вот например с теми же таблицами...

Слишком иделализированно, ИМХО.Здесь автор обращается к разработчикам, а надо бы к руководителям компаний. Разве могут быть какие-либо притензии, когда джуниора вэб-девелопера ставят разрабатывать корпоративный сайт?

JavaScript и CSS должны храниться в отдельных файлах, а не включены в код страницы — очень спорно.

Почему? Кэширование — зло для девелопера? Да, для девелопера в девелопменте — бывает и зло иногда:)

В отличие от погоды, плохие сайты можно\нужно менять.

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

Вопрос на засыпку — кто-то увидел здесь новые мысли?

Новых мыслей, конечно же, не наблюдается, но статьи типа"$n способов как (не) (делать|создать) (что-то) "всегда почитать интересно:)

Но на это сетовать — это имхо детский сад, все равно, что жаловаться на плохую погоду.

В отличие от погоды, плохие сайты можно\нужно менять.

JavaScript и CSS должны храниться в отдельных файлах, а не включены в код страницы — очень спорно.

Почему? Кэширование — зло для девелопера?

Сайт на базе таблиц это такое средневековье — автор слишком много на себя берет

Согласен, дивы постоянно расползаюццо:)

JavaScript и CSS должны храниться в отдельных файлах, а не включены в код страницы — очень спорно.Сайт на базе таблиц это такое средневековье — автор слишком много на себя берет.11 — повтор 2.13 — повтор 3, 4, 6, 8.Вопрос на засыпку — кто-то увидел здесь новые мысли?

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

Да, в чём-то со мнением автора можно поспорить. Основная идея имхо бесспорна — количество денег компании как-то слабо влияет на качество ее представительства в интернете. Например, сайт Родовид-банка закачивает весь код страницы (видно по view source), но за полчаса кроме заголовка окна и белой страницы ничего не появляется. Зачем тогда вообще тратить деньги на сайт?

Да, сайты написанные конкретно под IE6- это очень большая проблемма. Я вот как-то поставил на одну из машин Винды 2000. Хотел через 5-й експлорер скачать драва для Интеловской видюхи. Не вышло. Видити ли, процесс закачки не может начаться из-за ошибки в Яваскрипте, блин. Поставил Оперу и скачал:)

Правда, ошибки на сайтах (в JS в частности) действительно достают. Так что тестирование и совместимость со всеми браузерами — это да.

А мне кажется, что претензии автора совсем не обоснованы. Можно согласится насчет кеширования и компрессии, размеров файлов может быть, а остальное — это либо внутренности, в которые пользователь никогда не загдядывает (как там разложен HTML/JS), Либо претензии к дизайну не от типичного представителя целевой аудитории. Насчет внутренностей — это личное дело разработчика. Мне кажется, сайты оценивать надо вообще без «view source».

Спасибо, исправил.

Ошибка перевода.П.4.Во фразе «Architect your logging system to track problems and provide information to the programmers »" logging system" = «система логгирования» (иногда говорят журнализации), но никак не «система логина» (аутентификации).

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

Пожалуйста, не переводите больше — вы не можете толком передать стиль оригинала.

Наверное, это к тому, что в заметке вместо «Вы» написано «ты».: D

Это к чему и кому?

Уважаемый автор, я что-то не припомню когда мы с вами пили на брудершафт...

После перевода на зубах застрял стиль автора:

Так много аццтойных сайтов. Как-то я лазил в инете, и мне пришлось объяснять своей маме, как отвалить. И она так и сделала!

:)

Подписаться на комментарии