Як команди розробників можуть запобігти повільній продуктивності у споживчих додатках?

Коли я раніше запитав, що відповідає за повільне програмне забезпечення, я отримав кілька відповідей, що це було соціальною проблемою та проблемою управління:

Це не технічна проблема, це проблема маркетингу та управління .... Зрештою, керівники продуктів відповідають за написання специфікацій того, що повинен отримати користувач. Багато речей може піти не так: менеджер продукту не вдається поставити відповідь на кнопку у специфікації ... Люди з якості контролю виконують посередню роботу з тестування на специфікацію ... якщо керівництво продуктом та персонал з контролю якості сплять за кермом, ми, програмісти, не можемо цього компенсувати. - Боб Мерфі

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

Отже, якщо це соціальна проблема, які соціальні механізми може створити організація, щоб уникнути доставки повільного програмного забезпечення своїм клієнтам?

При правильно написаних та повних вимогах не існує такого поняття, як відмінність помилок і низької продуктивності . Оскільки ви визначаєте продуктивність як нефункціональну вимогу, низька продуктивність стає помилкою, як і будь-яка інша помилка, і її випаде QA та вирішить розробники перед випуском.

Чи є соціальна проблема? Я не думаю, що так. Основне питання полягає в тому, що вимоги є неповними. Працюючи роками на посаді фрілансера, я ніколи не бачив нефункціональної вимоги, яка б говорила про те, що конкретне завдання повинно виконуватися в середньому за N секунд. Якщо менеджер / замовник / зацікавлений учасник чи що-небудь не турбується про ефективність продуктивності, чому я, як розробник, би це турбував, оскільки людей, які повинні дбати про це, зовсім не байдуже?

Є ще один фактор, який впливає на низьку продуктивність: той факт, що розробники працюють на дорогих ПК, які працюють добре . Коли ви роками працюєте на чотирьохядерному ПК з 8 ГБ оперативної пам’яті, SSD високого класу, новітню ОС тощо, дуже важко уявити, як ваша програма буде працювати в 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 і розробник буде просто витрачати свої зусилля на виправлення речей, які не мають значення для кінцевих користувачів.

Покладатись на розробників при тестуванні продуктивності - це настільки ж продуктивно, як і кочення кісток, щоб вибрати частину функціональності для пришвидшення. Ну, і це настільки ж надійно - "розробники, як правило, мають жахливу інтуїцію щодо того, де насправді будуть проблеми з продуктивністю в додатку" ( Брайан Гец ).

• Я був у проекті, коли керівництво кульгавого колись вирішило, що їхні яскраві хлопці з маркетингу та розумні програмісти досить хороші, щоб вирішити проблеми клієнтів щодо продуктивності. Яке це було чудове заняття. Відмовившись від випуску, півроку зусиль пішли на смітник, і компанія майже втратила стратегічного партнера. Зрештою, вони запросили професіоналів (експертів із бенчмаркінгу, статистики, UX, оптимізації низького рівня, подібних матеріалів) та професіоналів, які виправили цей безлад.

чи всі програмісти повинні робити власний контроль якості, щоб вони негайно побачили такі проблеми?

Те, що це можливо, не означає, що це шлях. Скоріше навпаки - на мій досвід, це був один із найнадійніших способів втратити продуктивність програмістів . Майже настільки ж хороші, як нескінченні зустрічі і навіть краще, ніж опитування кандидатів.

• Як колись тестер, я вважав, що поєднувати діяльність з розробки та забезпечення якості не повинно бути проблемою. Схоже, різниця між рутинним тестуванням розробників та систематичним контролем якості не матиме великого значення. Я вважав, що розмежування розробки / якості - це лише традиція в індустрії програмного забезпечення. Навчився досить важко, що це не так. Розмежування виявилося питаннями зосередженості та продуктивності та цілком серйозним.

Якщо виникла проблема, просто дайте мені орієнтир і встановіть цільову ефективність, і я зроблю все можливе, щоб досягти цього. Я не такий хороший у тестуванні продуктивності, але знаю трохи-два про оптимізацію.

Я думаю, ви виявите, що 99% часу проблема - це повзання сфери. Наприклад, з dvr. Ви можете подумати, що це легко, але тоді TIVO або конкурент вводить нову функцію, яку добре сприймають. Наступне, що вам відомо про нову функцію - на тарілці. Він може або не може бути сумісним з існуючим продуктом, і ми не переробляємо існуючий продукт, який займе багато часу. Таким чином, функція заклинюється, і вона забирає продуктивність. Впевнені, що дані є, щоб отримати інформацію, але якщо не було думки отримати цю інформацію, то є хороший шанс отримати її буде непросто. Тож тепер у нього є складний процес збирання цієї інформації щоразу, коли ви наближаєтесь до списку програм.

Ігнорування розробників, які, здається, не хвилюються ...

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

Наприклад, якщо є можливість виміряти час відповіді для вашої програми (наприклад, її веб-додаток, або запити в базу даних тощо). виконання (або понад визначений поріг) відповідей?

У багатьох, багатьох випадках - розробники не отримують цю інформацію з розгортань у реальному світі, і в результаті її дуже легко ігнорувати інформацію, яку ви не бачите.

Якщо, однак, щодня / кілька годин ви отримуєте електронний лист, який вказує, що на екран "х" потрібно 13 секунд, і він виконує наступний SQL-запит, SELECT TOP 1.... JOIN... OUTER JOIN... OUTER JOIN... CROSS JOIN...ви краще повірите, що розробник міг би (і, сподіваємось), все над виправленням це.

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

Примітка. Я думаю, що це те, що і розробникам слід запитувати доступ (або навіть розробляти таку функцію), і керівництво повинно надавати / фінансувати такі інструменти.

Чи можете ви придумати кращі приклади, коли ми можемо насправді покласти відповідальність на програмістів? Окрім Eclipse, і один із коментаторів вже вказав, що це роблять плагіни (моя перша установка кожної нової версії Eclipse працює як легша, але коли я додаю інші інструменти, вона починає сповільнюватися), ваші приклади можуть не бути програмістами і код, але пов'язаний із середовищем.

Минули дні запуску програми на комп’ютері у відриві та визначення, чи є вона "швидкою" чи "повільною". Інші приклади, які ви наводите, залежать від їхнього оточення - поточної перевантаженості мережі, перевантаженості серверів заднього кінця, неправильно налаштованих мережевих карт, несправного кабелю, кількості інших людей, які використовують його поблизу, або сотень інших змінних. напр. наш хостинг-провайдер стягував додаткову плату за гігабітні з'єднання з сервером, але врешті-решт ми визначили, що все пройшло через стародавній пристрій брандмауера з 10 Мб портами. Ці проблеми змінюються навколо і їх важко знайти.

Погоджено, програмісти можуть багато чого зробити (мінімізуючи пропускну здатність, прийоми інтерфейсу, які покращують чуйність і показують прогрес, щоб створити враження, що це швидко). Але коли ви котиться до реального світу, виникають всілякі обставини, про які ви дізнаєтесь лише на досвіді (і спостерігаєте, як ваші припущення розпадаються перед вами).

Скільки ви готові платити за краще програмне забезпечення? Скільки ринок чекатиме кращого програмного забезпечення? Скільки маленьких сувенірів захоче додати до наступного випуску?

Це ринок, що перерізав горло, там робиться багато компромісів. Якщо це справді лайно, ринок буде (або повинен) провалити товар. Можливо, є достатньо клієнтів, які можуть жити зі статусом-кво?

Я думаю, що найзагальніша відповідь на цю проблему - це також найскладніша в управлінні, яка полягає в тому, що кожен програміст повинен пам’ятати про продуктивність, що завгодно. Я також усвідомлюю, що це трохи коп.

Залежно від розміру проекту та відповідної команди, я вважаю, що в програмах, що займаються програмою, потрібно багато користі.

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

Досвід з перших рук важливий. Дайте розробникам швидкий комп'ютер для компіляції та нарощування, але дійсно повільний перевантажений комп'ютер (оскільки деякий відсоток користувачів насправді може) запустити свої додатки. (Це можна зробити в хмарних / серверних розробних середовищах, розділивши VM або сервери за функцією.) Дайте їм мобільний телефон із напівзагиблим акумулятором, і вимагайте від них використовувати його лише протягом днів початкового тестування мобільних додатків.

Якщо розробники співпереживають замовнику щодо продуктивності та часу автономної роботи, вони не будуть вважати продуктивність якоюсь напівфактичною специфікацією управління, яку слід поставити внизу списку пріоритетів. (Як і в: "Ей, я вважав, що це передчасна оптимізація", поки не пізно.)

Перестаньте купувати цей матеріал, і коментуйте низьку ефективність будь-яких онлайнових відгуків.

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

Єдині показники, які цікавлять виробника споживчих товарів, - це продажі та прибуток на одиницю.

Я погоджуюся, що програмістів слід краще навчати щодо максимальної ефективності тощо.

Але я думаю, що рішення не дає програмістам майже вмираючого обладнання для щоденного використання. Наскільки напружено буде, якщо ваша візуальна студія виходить з ладу двічі на день, для збирання матеріалу знадобилося х секунд, y секунди для відкриття рішення, z секунд для зміни вікон. Я не думаю, що це було не дуже рентабельно для компанії, оскільки апаратне забезпечення дешеве, а програміст час дорогий.

Оскільки наступною рукою, яка буде обробляти код, є команда з контролю якості (тестування), чи не краще було б навчити їх важливості продуктивності, мати стандарт прийнятного стандарту ефективності тощо як стандарт підприємства (ну, в ідеальному світі , стандарт продуктивності повинен бути специфічним, але це не трапляється дуже часто)? (тобто звичайна сторінка / вкладка, що змінюється ee, повинна відбуватися миттєво; "збереження оновлення має відбутися через х секунд", якщо це критична програма, то ...). Комп'ютер, на якому працюють команди QA, повинен бути типовим комп'ютером користувача. (ми не хочемо їх розсмоктувати, даючи їм 386, але не даємо їм чотирьохядерний ядер з 8 ГБ оперативної пам'яті, наприклад). Чи не вдасться вони відмовитися від програмістів, якщо вони будуть достатньо злий на продуктивність?

Я думаю, що клієнт / менеджер проектів повинен змусити програміста / команду qa / розробника / представника команди компанії зробити свою презентацію щодо найнижчого типового обладнання, яке вони мають. (наприклад, найслабший комп'ютер у компанії). Якщо це перезаписати, їм потрібно буде зібрати дані про те, як швидко зробити x обробку в старому програмному забезпеченні та порівняти його з тим, наскільки швидко він працює на новому програмному забезпеченні (це може бути повільніше, оскільки нове програмне забезпечення може залучати додатковий бізнес-процес, але повинно бути прийнятне вікно).

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

Для вашого типового програміста більшість офіційних міркувань щодо ефективності є вторинними просто: "чи це дратує, коли я намагаюся запустити його?" Якщо вони вважають це дратівливим, вони (принаймні намагаються) це виправити. Якщо вони задоволені тим, як він працює, найкраще, що ви отримаєте, - це напівсердечна спроба виправити. Це також допомагає знайти проблеми рано, перш ніж їх значно дорожче виправити.

Якщо доходить до того, що QA має виконувати правила, розробники насправді не вірять у це, оскільки вони вважають, що ефективність є достатньою, шанси досить хороші, що більшість отриманих «виправлень» отримають творчі способи подолання правил, не справжні виправлення, які покращують життя кінцевому користувачеві.

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