Недовольный пользователь: Что же случилось с Web-проектированием?

Опции документа Опции документа, требующие включения JavaScript, не отображаются Обсудить Выскажите мнение об этой странице Помогите нам улучшить содержание

Уровень сложности: простой

Питер Сибах, писатель, Независимый

03.10.2007

Вам когда-либо приходило в голову, что сегодняшние Web-разработчики могли бы кое-что позаимствовать у традиционного компьютерного программирования? Недовольный пользователь говорит об азах разработки программного обеспечения и спрашивает, куда деваются лучшие методы разработки, когда речь заходит о Web-приложениях.

На этот раз я первый готов признать, что это мой недочет. В Интернете что-то неладно, и боюсь, что я в этом виноват. Вернемся в прошлое, когда Интернет представлялся таким многообещающим. Я и практически все программисты шутили над теми, кто уверял, что может "программировать на HTML". И мы были не одни в этом вагоне: в большинстве компаний четко разделяли "разработку" и "дизайн" и делают это до сих пор

Проблема, связанная со строгим разделением разработчиков и дизайнеров, привела к тому, что Интернет заполняется сайтами, созданными людьми, ничего не знающими о стандартах и технологиях. В настоящее время большинство Web-страниц далеко выходят за рамки ограниченных возможностей HTML, и очень многие из них используют "чистые" языки программирования, например, Java или C++ (то есть реальный код с управляющими конструкциями и переменными и т.д.), наряду с изрядными фрагментами JavaScript, PHP, HTML, CSS и, разумеется, XML.

Дизайнеры были научены не думать о себе как о программистах и практически не несли ответственности за то, как их дизайн преобразуется в код - то есть людям, реализующим дизайн, приходилось работать больше. Хуже того, даже Web-разработчики, нашедшие время разобраться, как работает, например, Ajax, и не стали жертвами революции Adobe Flex, не считают себя Web-инженерами. В итоге появилось поколение Web-дизайнеров и разработчиков, пытающихся создавать все более сложные Web-сайты без учета лучших методов разработки программного обеспечения, таких как сбор требований, принцип DRY (не повторяй самого себя) и способы применения рефакторинга для выхода из тупика программирования.

В этом месяце мы поговорим о некоторых лучших методах разработки программного обеспечения (как правило, основанных на горьком опыте программистов за несколько десятков лет), которые, по-видимому, были утеряны в спешке при создании дивного нового Интернета.

Вы, конечно, знаете, что такое требования?

Сбор требований является важным аспектом разработки программного обеспечения, о котором постоянно забывают при разработке Web-приложений. На вопросы вроде "Нужен ли доступ к этому сайту с браузеров сотовых телефонов?" или "Должны ли URL-адреса быть достаточно понятными для использования в навигации по сайту?" редко имеются хорошо структурированные ответы. Вместо этого решения принимаются на лету, а пользователям приходится разбираться с результатами. Например, недавно я был сильно разочарован, когда в моем любимом Интернет-комиксе приняли новое соглашение по именованию, и стало невозможно просматривать архивы комиксов по дате, что ранее я делал годами.

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

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

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

В начало

Не повторяй самого себя

Принцип "Не повторяй самого себя", также известный как принцип DRY, считается основой хорошего проектирования. Удивительно, но его редко соблюдают при разработке Web-приложений. Смысл заключается в том, чтобы не дублировать материалы, компоненты или усилия. Практически неизбежно, что из двух имеющихся версий одной панели навигации одна в конечном итоге будет обновлена, а другая - нет. Это не только создает путаницу для пользователей, но означает больше усилий во всех отношениях. Ответ был известен еще нашим дедам - "Не повторяй самого себя!"

Одним из наиболее очевидных примеров пренебрежения Web-разработчиками принципа DRY можно считать оптимизацию страниц для определенного браузера в эпоху «войн браузеров». Многие не считали за труд форматировать Web-страницы на уровне мельчайших деталей, переполняя их тегами для шрифтов и отображения. Нередки были случаи, когда для каждого абзаца на Web-странице тщательно задавался нужный шрифт!. Разумеется, это неизбежно приводило к проблемам по мере развития сайта. Что произойдет, если изменится дизайн логотипа компании и потребуется изменить шрифт на странице в соответствии с новым логотипом? Люди тратили многие часы на то, чтобы открыть каждый файл, найти и заменить все теги шрифтов, надеясь при этом ничего не пропустить и не сделать ошибок (например, изменив "Times" на "Verdana" в тексте и забыв это сделать в тегах шрифтов).

Все изменило появление CSS (каскадные таблицы стилей). Теперь информация о макете размещается в отдельном центральном файле таблицы стилей. Обновление элемента в CSS приводит к изменению всех страниц, использующих эту таблицу стилей. Хотя Web-разработчики по-прежнему иногда забывают следовать принципу DRY при создании таблиц стилей, –что приводит к дублированию усилий и лишней трате времени.

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

                

	h1 { font-family: Helvetica, sans-serif; font-size 250% }
	h2 { font-family: Helvetica, sans-serif; font-size 200% }
	h3 { font-family: Helvetica, sans-serif; font-size 150% }
	h4 { font-family: Helvetica, sans-serif; font-size 100% }

Но что случится, если по некоторым причинам потребуется использовать другой шрифт? Код CSS в листинге 1 придется обновить четыре раза. Не так уж много для небольших блоков кода, но в более сложных таблицах стилей это может стать опасным. Моя программистская сущность подсказывает, что лучше было бы написать код с одним упоминанием шрифта, подобно представленному в листинге.

                

	h1, h2, h3, h4 { font-family: Helvetica, sans-serif; }
	h1 { font-size 250% }
	h2 { font-size 200% }
	h3 { font-size 150% }
	h4 { font-size 100% }

Возможно, у вас возникнет вопрос, почему я уделяю этому так много внимания. Код в листинге 2 не короче кода в листинге 1, и можно сказать, что этот код менее понятен непрограммистам. Если бы размер таблиц стилей никогда не превышал четырех строк, вероятно, я бы согласился. Но таблицы стилей имеют тенденцию к увеличению. В конечном счете маленький фрагмент CSS на листинге 2 может увеличиться до сотен строк кода. И кто сможет сказать, что никогда не придется изменять Helvetica на Times, и что не будет сделано никаких ошибок, и будут изменены абсолютно все вхождения тегов? Что еще хуже, можно выполнить глобальный поиск и замену на трех страницах CSS, а потом обнаружить, что кто-то задал Helvetica для других фрагментов текста, и этот код изменять не требуется.

Проблема заключается в том, что Интернет большой, и большинство Web-разработок выполняются с головокружительной скоростью. В отличие от разработчиков программного обеспечения, в среде которых такие принципы, как DRY, зазубривались в течение десятилетий, Web-разработчикам нужно работать быстро и уделять первостепенное внимание экономии времени прямо сейчас. То, что позволяет сэкономить время в данный момент, возможно, не сэкономит время в долгосрочной перспективе. Если для проекта создается несколько таблиц стилей с множеством общих данных, избавьте себя от бесконечной головной боли и с помощью правил @import соберите в отдельную таблицу стилей все повторяющиеся элементы. Потом вы скажете себе спасибо.

В начало

Рефакторинг, на помощь!

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

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

Наиболее часто рефакторинг применяется к коду, подобному коду Java или C++, но несложно заметить, что рефакторинг можно применить к CSS, макету страниц и другим аспектам Web-проектирования. Подробнее о рефакторинге Web-страниц см. в разделе Ресурсы .

В начало

Разработка через тестирование

Разработка через тестирование (TDD) – это довольно новый метод проектирования программного обеспечения. В действительности отсутствие тестирования и отладки рабочего кода является одним из негативных аспектов, унаследованных от прошлых поколений программистов. Как и их предшественники, многие Web-разработчики сегодня стараются отложить тестирование на последние минуты - в результате серьезные дефекты обнаруживаются тогда, когда, исправлять их уже слишком поздно. Пользователи будут недовольны программами, работающими с ошибками, независимо от того, куплены ли они в магазине или скачаны из Интернета

TDD – это методология гибкой разработки, согласно которой тестировать надо так же, как голосовать - пораньше и почаще! При разработке Web-страницы убедитесь, что известны целевые платформы, и будет ли страница работоспособной на этих платформах. Соберите требования, создайте макет Web-страницы и определите, будет ли он работать на данных платформах. Если Web-страница должна отображаться в Safari, с самого начала тестируйте ее в Safari. (Для коммерческих проектов стоимость компьютера Mac mini является несравнимо малой в сравнении с затратами на исправления после того, как будут выявлены проблемы с Safari).

Общая проблема тестирования любых пользовательских интерфейсов (включая и Web-интерфейс) заключается в том, что опытные пользователи не имеют привычки делать очевидные ошибки. Реальные пользователи такие ошибки совершают, поэтому устойчивость к таким ошибкам очень важна. Протестируйте свой сайт с помощью людей, не очень знакомых с выбранной схемой навигации. Если это невозможно, помучайте сайт самостоятельно. Что случится, если пользователь заблудится посреди процедуры оплаты покупки? Некоторые так и сделают. Что произойдет, если пользователь попытается ввести в цифровое поле слово нет? Что, если пользователь введет название города в поле почтового индекса?

Как и рефакторинг, TDD обычно применяется к коду, но на практике этот метод также можно применять и к проектированию Web-страниц. Подробнее о разработке через тестирование см. в разделе Ресурсы .

В начало

Заключение

Разработка программного обеспечения представляет собой область деятельности, в которой, по собственному признанию, до сих пор не разобрались многие лучшие эксперты в этой сфере. Большинство представленных в данной статье лучших методов являются результатом многолетних проб и ошибок. Но с течением времени они стали стандартом для разработки программного обеспечения. Это существенный шаг вперед по сравнению с группой обезьян, копающихся в компиляторе в попытке создать еще один UNIX®.

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

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

Действия: относитесь к своей работе с гордостью и старайтесь улучшить ее при каждом удобном случае. Web-страницы становятся основным функциональным компонентом для миллионов людей. Вы, Web-разработчики, имеете возможность сделать эту часть жизни лучше - так делайте это!

На этом прощаюсь

13 марта 2001 г. на сайте developerWorks была опубликована первая статья в колонке "Недовольный пользователь". За прошедшие шесть лет я написал в колонку "Недовольный пользователь"75 статей - 76, если считать и эту. Несмотря на все мои усилия по продвижению разработки, ориентированной на пользователей, и изменению мира Web-разработки по одному Web-сайту за один раз, сегодня я получил электронное письмо из брокерской Интернет-конторы, адресованное "Уважаемому Лоху". Так-то.

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

И еще одно: Web-парни, сообщите мне, когда все проблемы, о которых я писал в последние шесть или около того лет, будут решены. В этот день я начну искать другие проблемы для своих статей. Пока же мои статьи иногда можно будет найти на сайте developerWorks, но официально недовольным я больше не буду.

Это было славное время. Хотелось бы поблагодарить всех, кто высказывал свои мнения относительно этой колонки - как позитивные, так и нет.

Поделитесь мнением... Отзыв на digg.com Публикация на del.icio.us Публикация на slashdot

Ресурсы

• Оригинал статьи: The cranky user: What ever happened to Web engineering?;(EN)
  
  
• The cranky user series (Серия "Недовольный пользователь") (март 2001 г. - июль 2007 г.): Просмотрите все статьи колонки Питера Сибаха в данной серии;(EN)
  
  
• When Web pages don't work (Когда Web-страницы не работают) (Крис Пол, сайт developerWorks, февраль 2005 г.): Несколько способов, с помощью которых Web-проектировщики могут нечаянно отпугнуть потенциальных пользователей;(EN)
  
  
• Demystifying Extreme Programming: test-driven programming (Развенчание мифа об экстремальном программировании: программирование через тестирование) (Рой У. Миллер, сайт developerWorks, апрель 2003 г.): Пример TDD;(EN)
  
  
• Манифест гибкой разработки программного обеспечения: Гибкая разработка программного обеспечения (также известная как экстремальное программирование) – это одна из многочисленных попыток реформирования процесса разработки программ. Возможно, этот подход лучше всего подходит к постоянно изменяющейся среде Web-разработки;(EN)
  
  
• Домашняя страница о рефакторинге: Рефакторинг – это метод улучшения программ, который можно с успехом применять к большинству Web-страниц;
  
  
• Javascript Refactoring For Safer Faster Better AJAX (Рефакторинг Javascript для более быстрого, защищенного и лучшего AJAX) (Павел Симаков, сайт Software Secret Weapons, май 2007 г.): Статья содержит конкретный пример рефакторинга Web-страницы;(EN)
  
  
• Спецификация CSS 2.1: Более подробная информация о CSS;(EN)
  
  
• Домашняя страница Эдварда Тафта: Работы Эдварда Тафта по обеспечению большей доступности отображаемой информации для читателей имеют огромное значение для Web-разработчиков;(EN)
  
  
• JND.org: Домашняя страница Дона Нормана, статья которого The Design of Everyday Things (Дизайн обычных вещей) – это еще один пример обширного и глубокого ресурса, который не знаком большинству Web-разработчиков;(EN)
  
  
• Улучшение качества кода Java: Форум Эндрю Гловера о качестве кода является ресурсом сообщества developerWorks, предназначенным для улучшения качества Web-приложений.(EN)
  
  

• Примите участие в обсуждении материала на форуме.
  
  
• Блоги developerWorks:(EN) Присоединяйтесь к сообществу developerWorks .(EN)

Об авторе

		Питер Сибах (Peter Seebach) работает с компьютерами много лет и постепенно приспособился. Хотя он до сих пор не понимает, почему мышку надо чистить так часто.

Выскажите мнение об этой странице

Пожалуйста, найдите минутку и заполните форму, чтобы повысить уровень сервиса. Помогла ли данная информация достичь Вашей цели? Да Нет Не знаю   Пожалуйста, напишите комментарий, чтобы мы могли улучшить данную страницу:   Насколько полезна эта информация? (1 = Бесполезна, 5 = Очень полезна) 1 2 3 4 5

В начало