Вот такой простой и весьма приятный опыт.
Но откуда же возник этот ненужный код? Почему один из программистов вдруг решил написать лишнего и почему это не вскрылось во время рецензирования (code review) или парного программирования? Почти наверняка дело обстояло так:
• Эти дополнительные функции были интересны программисту, и он с удовольствием их написал. (Совет: Пишите полезный код, а не прикольный код.)
• Кто-то решил, что это может понадобиться в будущем, так почему не написать код сразу. (Совет: Это противоречит YAGNI. Не пишите прямо сейчас то, что прямо сейчас не нужно.)
• «Излишество» не выглядело столь уж большим, и проще было сходу реализовать эту функцию, чем обращаться к клиенту и выяснять, нужна ли она ему. (Совет: Писать и сопровождать лишний код всегда дольше. Да и клиент — славный малый. Маленький кусочек лишнего кода со временем разрастается, как снежный ком, в огромный кусок работы по сопровождению.)
• Чтобы оправдать дополнительную функцию, программист придумал новые требования, которых не было ни в документации, ни на обсуждениях. Фактически это поддельные технические требования. (Совет: Требования к системе устанавливаются не программистами, а заказчиком.)
Так над чем вы сейчас работаете? Это действительно нужно?
Установи меня!Маркус Бэйкер
Мне нисколько не интересна ваша программа.
У меня полно своих проблем и длиннющий список задач. На ваш сайт я зашел лишь благодаря непроверенным слухам, будто ваша программа решит все мои проблемы. Уж простите мне мое недоверие.
Если исследования движения взгляда верны, я уже прочел заголовок и шарю по странице в поисках синей подчеркнутой ссылки Загрузить сейчас. Кстати, если я зашел на эту страницу из браузера, работающего под 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 требуется для ответа на воздействие, тем большим будет время отклика.
Существует ряд относительно очевидных и широко известных стратегий сокращения количества взаимодействий между удаленными процессами в расчете на одно воздействие. Одна из таких стратегий заключается в применении принципа бережливости — мы можем оптимизировать интерфейс между процессами, чтобы передавались только те данные, которые нужны непосредственно, а объем взаимодействия был минимален. Другая стратегия — как можно более широкое распараллеливание связей между процессами, чтобы общее время отклика определялось в основном IPC с наибольшей задержкой. Третья стратегия — кэшировать результаты предшествующих IPC, чтобы в будущем вместо IPC использовать обращение к локальному кэшу.
Проектируя приложение, следите за количеством взаимодействий между процессами, происходящих в ответ на каждое воздействие. Анализируя приложения с низкой производительностью, я часто сталкивался с тем, что отношение количества IPC к воздействию составляет 1000:1 и больше. Сокращение этого отношения путем кэширования, распараллеливания или других приемов даст значительно больший эффект, чем изменение структуры данных или модификация алгоритма сортировки.
Сборка должна быть чистойЙоханнес Бродуолл
Приходилось ли вам видеть список предупреждений компилятора (warnings) размером с очерк на тему, как не стоит писать код, и думать при этом: «Конечно, с этим надо что-то делать… только сейчас у меня нет на это времени»? И наоборот, случалось ли вам увидеть единственное предупреждение, появившееся во время компиляции, и тут же исправить его?
Когда я начинаю новый проект с нуля, нет никаких предупреждений, нет беспорядка, нет проблем. Но объем кода растет, и, если не принять меры, не исключено, что беспорядок, хлам, предупреждения и проблемы начнут постепенно накапливаться. В большом потоке «шума» значительно тяжелее отыскать действительно важное предупреждение среди сотен других, которые мне не интересны.
Чтобы предупреждения снова стали полезными, я стараюсь придерживаться политики полной недопустимости предупреждений во время сборки. Даже если предупреждение несущественно, я его устраняю. Если оно не критично, но все же относится к делу, я исправляю код. Если компилятор сообщает об опасности исключения с нулевым указателем, я исправляю источник этой опасности, даже если «знаю», что в реальной обстановке эта проблема никогда не возникнет. Если встроенная в код документация (Javadoc или ее аналог) ссылается на параметры, которые удалены или переименованы, я исправляю документацию.