97 этюдов для программистов. Опыт ведущих экспертов - Пит Гудлиф
Так над чем вы сейчас работаете? Это действительно нужно?
Установи меня!
Маркус Бэйкер
Мне нисколько не интересна ваша программа.
У меня полно своих проблем и длиннющий список задач. На ваш сайт я зашел лишь благодаря непроверенным слухам, будто ваша программа решит все мои проблемы. Уж простите мне мое недоверие.
Если исследования движения взгляда верны, я уже прочел заголовок и шарю по странице в поисках синей подчеркнутой ссылки Загрузить сейчас. Кстати, если я зашел на эту страницу из браузера, работающего под Linux, и мой IP принадлежит Великобритании, то можно предположить, что мне нужна версия для Linux с зеркала в Европе, так что об этом, пожалуйста, не спрашивайте. Я так понимаю, что диалоговое окно загрузки файла откроется сразу, так что я отправлю эту штуку в свою папку для загруженных файлов и продолжу чтение.
Выполняя любое действие, человек анализирует соотношение затрат и выгоды. Если ваша программа хоть на секунду упадет ниже приемлемого для меня качества, я тут же ее выброшу и найду что-то другое. Немедленное вознаграждение — вот в чем сила.
Первый барьер — установка. Думаете, невелика беда? Так загляните в свою папку загруженных файлов. Полно файлов .tar и .zip, верно? Какую часть из них вы распаковали? Сколько установили? У меня, например, лишь третья часть из них служит чем-то, кроме балласта для жесткого диска.
Даже если я хочу получить обслуживание на дому, я не желаю, чтобы вы входили в мой дом без приглашения. Прежде чем набрать команду install, я бы хотел точно знать, где вы собираетесь размещать свои данные. Это мой компьютер, и я хочу по возможности соблюдать на нем порядок. Я хочу также иметь возможность удалить вашу программу в ту же секунду, как я разочаруюсь в ней. Заподозрив, что это невозможно, я просто не буду ее устанавливать. Моя машина работает стабильно, и я хочу, чтобы так было и впредь.
Если у вашей программы графический интерфейс, я хотел бы выполнить какую-нибудь простую задачу и увидеть результат. «Мастера» тут не помогут, потому что они делают какие-то вещи, которых я не понимаю. Весьма вероятно, что я захочу прочесть или записать файл. Я не хочу создавать проект, импортировать каталоги или сообщать вам свой электронный адрес. Если все работает, переходим к учебнику (tutorial).
Если ваше программное обеспечение — библиотека, я продолжаю читать вашу веб-страницу в поисках краткого руководства для начинающих. Мне нужно что-то вроде «Hello, World» в пяти незамысловатых строках кода, и чтобы результат был точно таким, как описывает ваш веб-сайт. Никаких огромных файлов XML или шаблонов, которые нужно заполнить, — лишь один файл с исходным кодом. Не забывайте, я загрузил еще и продукт вашего конкурента. Ага, того самого, который на всех форумах твердит, насколько его продукт лучше вашего. Если все работает, переходим к учебнику.
У вас ведь есть учебник, да? На понятном мне языке?
И если в учебнике говорится о моей проблеме, я приободряюсь. Теперь, когда я читаю о том, что я смогу делать, мне становится интересно и даже увлекательно. Я откидываюсь в кресле и прихлебываю чай — я ведь уже говорил, что живу в Великобритании? Теперь я поиграю с вашими примерами и попробую научиться пользоваться вашим творением. Если оно решит мои проблемы, я пошлю вам благодарственное письмо. Я буду также посылать сообщения об ошибках, когда приложение падает, и предложения по новым функциям. Я даже расскажу своим друзьям, что ваша программа лучше других, даже если не пробовал программы ваших конкурентов. И все потому, что вы с таким вниманием отнеслись к моим первым робким шагам.
И как только я мог усомниться в вас?
Межпроцессная коммуникация влияет на время отклика приложения
Рэнди Стэффорд
Время отклика имеет критическое значение для эргономики программ. Мало что так раздражает, как ожидание ответа программной системы, особенно если взаимодействие с ней состоит из повторяющихся циклов воздействия и отклика.[14] Возникает ощущение, будто программа крадет у вас время и снижает продуктивность. Однако причины замедленного отклика программисты осознают не всегда, особенно в современных приложениях. В литературе, посвященной контролю производительности, по-прежнему много внимания уделяется структурам данных и алгоритмам, то есть вопросам, способным оказывать влияние на производительность в некоторых случаях, но едва ли в современных многоуровневых приложениях корпоративного уровня.
Мой опыт показывает, что когда в таких приложениях возникает проблема производительности, поиски ее решения следует начинать не с изучения структур данных и алгоритмов. Время отклика больше всего зависит от количества взаимодействий между удаленными процессами (interprocess communications, IPC), осуществляемых в ответ на воздействие. Да, встречаются и другие локальные узкие места, но число взаимодействий между удаленными процессами обычно имеет решающее значение. Каждое взаимодействие между удаленными процессами добавляет некоторую ненулевую задержку в общее время отклика, и эти отдельные добавки суммируются, особенно если возникают последовательно.
Каноническим примером служит пульсирующая нагрузка в приложениях, использующих объектно-реляционное отображение (ORM). Пульсирующая нагрузка описывает последовательное выполнение множественных обращений к базе данных для чтения данных, необходимых для построения графа объектов (см. шаблон Lazy Load[15] в книге Мартина Фаулера «Patterns of Enterprise Application Architecture»,[16] Addison-Wesley Professional). Когда клиентом базы данных является сервер приложений промежуточного уровня (middle-tier), который компонует веб-страницу, обращения к базе данных обычно происходят последовательно в едином потоке. Их периоды ожидания суммируются, образуя суммарное время отклика. Даже если каждое обращение к базе данных длится всего 10 мс, страница, требующая 1000 обращений (что не редкость), появится с задержкой не менее чем в 10 секунд. Другими примерами могут служить обращение к веб-службам, HTTP-запросы веб-браузера, вызов распределенных объектов, шаблон связи «запрос-ответ» и взаимодействие с таблицей данных по специальным сетевым протоколам. Чем больше удаленных IPC требуется для ответа на воздействие, тем большим будет время отклика.
Существует ряд относительно очевидных и широко известных стратегий сокращения количества взаимодействий между удаленными процессами в расчете на одно воздействие. Одна из таких стратегий заключается в применении принципа бережливости — мы можем оптимизировать интерфейс между процессами, чтобы передавались только те данные, которые нужны непосредственно, а объем взаимодействия был минимален. Другая стратегия — как можно более широкое распараллеливание связей между
