Как команды разработчиков могут предотвратить низкую производительность в пользовательских приложениях?

Когда я ранее спрашивал, что отвечает за медленное программное обеспечение, я получил несколько ответов, в которых говорилось, что это социальная проблема и проблема управления:

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

Люди работают над приложениями большого размера. Когда они работают, возникают проблемы с производительностью, как и ошибки. Разница в том, что ошибки «плохие», они кричат ​​«найди меня и исправь меня». Проблемы с производительностью просто сидеть и усугубляться. Программисты часто думают: «Ну, у моего кода не будет проблем с производительностью. Скорее, менеджмент должен купить мне более новую / большую / более быструю машину». Дело в том, что если разработчики периодически просто ищут проблемы с производительностью ( что на самом деле очень просто ), они могут просто их устранить. - Майк Данлавей

Итак, если это социальная проблема, какие социальные механизмы может внедрить организация, чтобы избежать доставки медленного программного обеспечения своим клиентам?

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

Есть ли социальная проблема? Я так не думаю. Основная проблема заключается в том, что требования являются неполными. Работая годами фрилансером, я никогда не видел неработающего требования, говорящего о том, что конкретное задание должно выполняться в среднем за N секунд. Если менеджер / клиент / заинтересованная сторона или кто-то еще не беспокоится об активе производительности, почему я, как разработчик, беспокоюсь об этом, поскольку людям, которые должны заботиться об этом, все равно?

Есть еще один фактор, который влияет на низкую производительность: тот факт, что разработчики работают на дорогих ПК, которые работают хорошо . Когда вы годами работаете на четырехъядерном ПК с 8 ГБ ОЗУ, высокопроизводительным твердотельным накопителем, новейшей ОС и т. Д., Очень трудно представить, как ваше приложение будет работать в Windows XP на двухъядерном ПК. с 512 МО оперативной памяти и старым жестким диском, заполненным на 90% и не дефрагментированным в течение многих лет. К сожалению, в некоторых странах последний случай - тот, который мы видим для большинства потребителей приложения. Чем больше разрыв между ПК-разработчиками и ПК-потребителями, тем сложнее для разработчика заботиться о производительности своего приложения.

Проблема(?):

• Клиент (или конечный пользователь) не жалуется на это (достаточно)
• Таким образом, менеджер проекта (/ продукта) не считает это требованием
• Таким образом, разработчик не получает время, чтобы это исправить.

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

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

Но ты не можешь сделать все. Это оптимизировать или добавить функции, и те, кто тратит деньги, решают.

Но есть и хорошие новости: я заметил, что SaaS / Cloud / Buzzword-приложения очень помогают здесь. Когда люди выбирают между несколькими похожими веб-приложениями и начинают тестировать вживую, вместо того, чтобы сначала создавать искусственные списки «требуемых» функций, они быстрее реагируют на реакцию и, таким образом, на производительность будет обращать больше внимания.

К сожалению, я считаю, что самая большая проблема в том, что ты не можешь сделать все. У вас есть дата отгрузки, и вы знаете, что она медленная, но вам НУЖНО вывести на рынок функции X, Y, Z.

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

Таким образом, вы беспокоитесь о функциональности и эстетике (потому что пользователи часто уделяют внимание эстетике). В следующем выпуске вы исправите производительность.

Но премьер-министр просто дает вам список функций, и нет времени, чтобы исправить производительность.

И замкнутый круг продолжается.

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

Люди должны знать, как - а они не знают

Они могут думать, что они делают, но просто просмотрите все вопросы и ответы, связанные с производительностью, на StackOverFlow и на этом форуме. Больно, что многие показывают очень мало здравого смысла о производительности.

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

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

Небеса знают, я пробовал на этих форумах, как в -

• Основной супер-простой метод
• Ускорение в 43 раза - сделайте это с вашим профилировщиком
• Причины, почему в отвратительной детализации

Любой может сделать это. Им просто нужно сделать это на самом деле .

Сделать производительность требованием.

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

Тем не менее, эти программисты, очевидно, все еще полезны для компании, но они назначаются для задач, которые не считаются критически важными для производительности, поэтому вы получите проигрыватель Blu-ray, который может воспроизводить потоки Netflix без сбоев без пропуска кадров, но это занимает 30-60 секунд. чтобы открыть пункт меню, который отображает вашу очередь.

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

Если производительность является требованием, проверьте его.

В противном случае Уолли может написать бесконечный цикл и уйти раньше: «Это займет некоторое время». Он может претендовать.

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

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

Производительность (например, потребление ресурсов) должна быть заложена в бюджет подсистем. Затем приемочные тесты подсистемы могут их проверить.

Тогда вы можете проверить рано и часто на производительность. Даже модульные тесты могут проверить это.

Поэтому теперь разработчики используют его в качестве критерия приемлемости и могут организовать свой подход в соответствии с ним.

Там, где я сейчас работаю, стресс-тест производительности в 2 раза больше, чем у любого набора данных о клиентах, о котором мы знаем. Регулярно ломается новая версия продукта. Хорошее тестирование.

Я помню, как однажды в середине 90-х годов я проводил некоторое время, пытаясь что-то оптимизировать, и коллега сказал мне: «Это работает на пенсии, кого это волнует?» .... это было откровением. К сожалению, это была лишь верхушка айсберга, я слышал такое отношение на протяжении всей моей карьеры, хотя со временем «пентиум» изменился.

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

Но программисту не нужно получать письмо от QA, чтобы понять, что 3-секундная задержка между нажатием клавиши и ответом недопустима

Согласитесь, это не должно. Это должно занять больше: доказательство того, что полученное отставание актуально для конечных пользователей .

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

Доверие разработчиков к тестированию производительности примерно так же продуктивно, как бросить кубик, чтобы выбрать часть функциональности для ускорения. О, и это примерно так же надежно, как "- разработчики, как правило, имеют ужасную интуицию о том, где на самом деле будут проблемы с производительностью в приложении" ( Брайан Гетц ).

• Я был в проекте, где неумелое руководство однажды решило, что их талантливые маркетологи и умные программисты достаточно хороши, чтобы справиться с проблемами производительности клиентов. Какой это был замечательный урок! Отказ от выпуска, пол года усилий ушло на мусорное ведро, и компания практически потеряла стратегического партнера. В конце концов, они пригласили профессионалов (экспертов по бенчмаркингу, статистике, UX, низкоуровневой оптимизации и т. П.) И профессионалов исправили этот беспорядок.

Должны ли все программисты самостоятельно проводить тестирование, чтобы они сразу же увидели такие проблемы?

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

• Как бывший тестер, я однажды подумал, что не должно быть проблемой совмещать деятельность по разработке и обеспечению качества. Похоже, разница между рутинным тестированием разработчиков и систематическим контролем качества не будет иметь большого значения. Я думал, что разделение dev / QA - просто традиция в индустрии программного обеспечения. Выучил довольно сложный способ, что это не так. Разделение оказалось вопросом целенаправленности и продуктивности, причем довольно серьезным.

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

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

Игнорирование разработчиков, которые, кажется, не заботятся ...

Я думаю, что часто разработчики, работающие над кодом, не имеют инструментов для измерения производительности на постоянной основе.

Например, если можно измерить время отклика для вашего приложения (например, его веб-приложения или запросов к базе данных и т. д.) - Получаете ли вы в настоящее время уведомления (по электронной почте, SMS и т. д.), которые указывают на «10 лучших» худших выполнение (или превышение определенного порога) ответов?

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

Однако, если каждый день / несколько часов вы получаете электронное письмо с сообщением о том, что загрузке экрана «x» требуется 13 секунд, и он выполняет следующий SQL-запрос, SELECT TOP 1.... JOIN... OUTER JOIN... OUTER JOIN... CROSS JOIN...вам лучше поверить, что разработчик может (и, надеюсь, будет) полностью исправить Это.

Таким образом , хотя я хотел бы верить , что все программисты делают работу серьезно отнестись Я думаю , что отсутствие видимости на вопрос (ы) часто является виновником.

Примечание: я думаю, что это то, что разработчики должны запрашивать доступ (или даже разрабатывать такую ​​функцию), а руководство должно предоставлять / финансировать такие инструменты.

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

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

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

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

Это рынок, где много компромиссов. Если это действительно дерьмо, то рынок (или должен) провалит продукт. Может быть, есть достаточно клиентов, которые могут жить со статус-кво?

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

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

Например, я работал в команде, в которой команда проекта (включая около 30 разработчиков) имела как минимум 2 человека, занимающихся оптимизацией производительности. Это конкретное приложение также было довольно подвержено проблемам с производительностью, поскольку существовало множество компонентов взаимодействия, не только через веб-сервисы, но и с точки зрения устаревших уровней с различными компонентами отображения данных и адаптера.

Опыт из первых рук важен. Предоставьте разработчикам быстрый компьютер для компиляции и сборки, но очень медленно перегруженный компьютер (как может быть у некоторого процента пользователей) для запуска своих приложений. (Это можно сделать в облачной / серверной среде разработки, разделив виртуальные машины или серверы по функциям.) Дайте им сотовый телефон с полуразряженной батареей и попросите их использовать только его в течение первых дней тестирования мобильных приложений.

Если разработчики сочувствуют клиенту в отношении производительности и срока службы батареи, то они не будут рассматривать производительность как некоторую полусумную спецификацию управления, которую следует поместить внизу списка приоритетов. (Как в: «эй, я думал, что это преждевременная оптимизация», пока не стало слишком поздно.)

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

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

Единственными показателями, которые интересуют производителя потребительских товаров, являются объем продаж и прибыль на единицу.

Я согласен с тем, что программистов лучше учить максимизировать производительность и т. Д.

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

Поскольку следующая рука, которая будет обрабатывать код, - это команда QA (тестирование), не лучше ли будет рассказать им о важности производительности, иметь стандарт того, что является приемлемым стандартом производительности, и т. Д. Как стандарт предприятия (ну, в идеальном мире). Стандарт производительности должен быть в спецификации, но это не часто случается)? (т. е. обычные корпоративные ee-изменения страницы / вкладки должны происходить мгновенно, «сохранение обновления должно произойти через x секунду», если это критически важное приложение, то ...). Компьютер, на котором работают команды QA, должен быть типичным компьютером пользователя. (мы не хотим разозлить их, дав им 386, но не дайте им четырехъядерное ядро ​​с 8 ГБ оперативной памяти, например). Неужели они не решатся на программистов, если они будут достаточно взбешены производительностью?

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

Я говорил это раньше, но скажу еще раз: я думаю, что один из лучших способов справиться с этим - просто заставить ваших разработчиков работать на (относительно) передовом оборудовании.

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

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

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