litceysel.ru
добавить свой файл
1 2 ... 7 8

40. Установи меня!

Маркус Бейкер (Marcus Baker)

Мне нисколько не интересна ваша программа.

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

Если исследования движения глаз не обманывают, то я должен был уже прочесть заглавие и искать синий подчеркнутый текст Download. Кстати, если я зашел на эту страницу Linux-браузером и мой IP принадлежит UK, то можно предположить, что мне нужна версия для Linux с зеркала в Европе, поэтому не нужно задавать лишних вопросов. Если стразу откроется диалоговое окно загрузки файла, я отправлю эту штуку в свою папку для загруженных файлов и продолжу чтение.

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

Первое препятствие – инсталляция. Думаете, что эта проблема невелика? Тогда загляните в свою папку загруженных файлов. Куча файлов .tar и .zip, верно? Какую часть из них вы распаковали? Сколько установили? У меня, например, лишь третья часть их не служит простым балластом для жесткого диска.

Даже если я хочу получить обслуживание на дому, я не желаю, чтобы вы входили в мой дом без приглашения. Прежде чем набрать install, я бы хотел точно знать, где вы собираетесь размещать свои данные. Это мой компьютер, и я хочу, по возможности, соблюдать на нем порядок. Я хочу также иметь возможность удалить вашу программу в тот миг, когда разочаруюсь в ней. Если мне покажется, что это невозможно, я просто не буду ее устанавливать. Моя машина работает стабильно, и я хочу, чтобы так было и впредь.

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


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

Если ваше программное обеспечение – это библиотека, я продолжаю читать вашу веб-страницу в поисках краткого руководства. Мне нужно что-то подобное «Hello world» в пяти незамысловатых строках кода, и чтобы результат был точно таким, как описывает ваш веб-сайт. Никаких огромных файлов XML или шаблонов, которые нужно заполнить – лишь один маленький скрипт. Не забывайте, что я также загрузил среду, предлагаемую вашим конкурентом. Того самого, который на всех форумах твердит, насколько его продукт лучше вашего. Если все работает, переходим к учебнику.

Насколько я понимаю, учебник существует? И написан понятным для меня языком?

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

И как только я мог усомниться в вас?

41. Связь между процессами влияет на время реакции приложения


Рэнди Стэффорд (Randy Stafford)

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


Мой опыт показывает, что когда в таких приложениях возникает проблема производительности, способы ее увеличения следует начинать не с изучения структур данных и алгоритмов. Быстрота реакции больше всего зависит от количества взаимодействий между удаленными процессами (IPC), осуществляемых в ответ на стимулирующее воздействие. Бывают и другие локальные узкие места, но количество связей между процессами обычно оказывает решающее влияние. Каждая удаленная связь между процессами добавляет некоторую ощутимую задержку в общее время реакции, и эти отдельные добавки суммируются, особенно если происходят последовательно.

Важным примером служит пульсирующая нагрузка в приложениях, использующих объектно-реляционное отображение (ORM). Пульсирующая нагрузка описывает последовательное выполнение множественных обращений к базе данных для чтения данных, необходимых, чтобы построить граф объектов (см. шаблон Lazy Load1 в книге Мартина Фаулера «Архитектура корпоративных программных приложений»). Когда клиентом базы данных является сервер приложений промежуточного уровня, выводящий веб-страницу, обращения к базе данных обычно происходят последовательно в едином потоке. Их отдельные периоды ожидания накапливаются, образуя суммарное время отклика. Даже если каждое обращение к базе данных длится всего 10 мс, страница, требующая 1000 обращений (что не редкость) появится с задержкой не менее чем в 10 секунд. Другими примерами могут служить вызов веб-сервисов, запросы HTTP веб-браузера, вызов распределенных объектов, шаблон связи «запрос-ответ» и взаимодействие с таблицей данных (datagrid) по специальным сетевым протоколам. Чем больше удаленных IPC требуется для ответа на стимулирующий раздражитель, тем большим будет время отклика

Есть несколько относительно очевидных и широко известных стратегий сокращения количества удаленных связей между процессами в расчете на один возбудитель. Одна из них предлагает принцип экономии, оптимизируя интерфейс между процессами, с тем чтобы передавались только те данные, которые нужны непосредственно и объем взаимодействия был минимален. Другая стратегия – возможно более широкое распараллеливание связей между процессами, чтобы общее время отклика определялось в основном IPC с наибольшей задержкой. Третья стратегия – кэширование результатов предшествующих IPC, чтобы в будущем вместо IPC использовать обращение к локальному кэшу.


Проектируя приложение, следите за количеством связей между процессами, образуемых в ответ на каждый возбудитель. Анализируя приложения с низкой производительностью, я часто сталкивался с тем, что отношение количества IPC к возбудителю составляет 1000:1. Сокращение этого отношения путем кэширования, распараллеливания или других приемов дает значительно больший эффект, чем изменение структуры данных или модификация алгоритма сортировки.

42. Сборка должна быть чистой


Йоханнес Бродуолл (Johannes Brodwall)

Приходилось ли вам смотреть на список выданных компилятором предупреждений, напоминающий очерк о том, как не надо кодировать, и думать при этом: «конечно с этим надо что-то делать, но сейчас у меня нет времени»? И наоборот: случалось ли вам видеть единственное предупреждение, появившееся во время компиляции, и тут же внести исправления, чтобы впредь оно не возникало?

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

Чтобы предупреждения снова стали полезными, я стараюсь придерживаться политики полной недопустимости вывода предупреждений во время сборки. Даже если предупреждение не существенно, я занимаюсь им. Если оно не критично, но все же относится к делу, я его исправляю. Если компилятор сообщает об опасности исключения с нулевым указателем, я исправляю его источник, даже если «знаю», что в реальной обстановке этой проблемы никогда не возникнет. Если встроенная документация (Javadoc или аналогичная) ссылается на параметры, которые удалены или переименованы, я исправляю документацию.

Если мне не интересно предупреждение и оно не существенно, я советуюсь с командой, не изменить ли нам политику выдачи предупреждений. Например, я считаю, что документирование параметров и возвращаемого значения метода во многих случаях не приносит никакой пользы, и предупреждать об их отсутствии нет необходимости. Также, при переходе на новую версию языка программирования могут появиться предупреждения в коде, где их раньше не было. Например, когда в Java 5 появились дженерики, старый код, в котором не был задан тип параметра дженерика, стал выдавать предупреждения. Мне не нужны такие назойливые предупреждения (пока, во всяком случае). Бесполезны предупреждения, которые не согласованы с реальностью.


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

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



следующая страница >>