Що викликає погану ефективність у споживчих додатках? [зачинено]

Моєму відеореєстратору Comcast потрібно щонайменше три секунди, щоб реагувати на кожне натискання клавіш дистанційного керування, перетворюючи просте завдання перегляду телевізора на розчаровуючий перемикання кнопок. Мій iPhone займає щонайменше п’ятнадцять секунд, щоб відображати текстові повідомлення та збої ¼ з тих разів, коли я намагаюся піднести додаток для iPod; просто отримання та читання електронного листа часто займає більше хвилини. Навіть у navcom в моїй машині є м'який і невідповідний контроль, часто ковтаючи послідовні входи, якщо я роблю їх менше ніж за кілька секунд.

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

Що за цим? Це технічна проблема, чи соціальна? Хто чи що відповідає?

Це тому, що всі вони написані керованими, зібраними сміттям мовами, а не рідним кодом? Це окремі програмісти написали програмне забезпечення для цих пристроїв? У всіх цих випадках розробники додатків точно знали, на яку апаратну платформу вони націлені та які її можливості; вони не врахували це? Це той хлопець, який ходить навколо, повторюючи "оптимізація - корінь усього зла", чи зводив їх із збитків? Це був менталітет "о, це просто додаткові 100 мс" кожного разу, поки всі ці мілісекунди не складуть хвилин? Чи я винен, що в першу чергу придбав ці продукти?

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

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

Гарне питання. Що я бачу щодня, це і є.

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

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

Натомість "найсучасніший":

1. покладатися на афоризми, такі як "уникнення передчасної оптимізації" та 90/10 ху-хоу.
2. поговоріть сміливо про профілювання, а іноді насправді спробуйте, часто з невтішними результатами, як ви бачите у всіх питаннях про це.
3. повернутися на старі добрі здогадки, замасковані під досвід та знання.

Але насправді, це негативно. Щоб бути позитивним, цей метод працює майже весь час, і він не міг бути простішим. Ось докладний приклад .

Це не технічна проблема, це проблема маркетингу та управління.

Ви, можливо, в цей момент закочуєте очі, але будь ласка, будьте зі мною.

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

Отже, давайте візьмемо ваш відеокамера Comcast. В ідеалі все буде працювати так:

1. Керівник продукту пише специфікацію: "Коли користувач натискає кнопку на пульті дистанційного керування і знаходиться в межах 25 футів DVR, відеореєстратор повинен відповісти на натиск протягом 250 мілісекунд".
2. Технічні працівники будують обладнання, пишуть вбудоване програмне забезпечення тощо.
3. Тестери QA або затверджують, що система відповідає специфікації, або повертають її до технічної групи для виправлення.

Звичайно, багато чого може піти не так:

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

Ви бачили там усіх бездумних програмістів? Не було жодної.

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

Але насправді, якщо керівництво продуктами та QA співробітники сплять за кермом, ми, програмісти, не можемо цього компенсувати.

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

Тому що програмісти не ідеальні.

Я програміст вбудованих речей. Частина мого коду не ідеальна. Більшість мого вбудованого коду швидко.

Виправити проблеми з продуктивністю в кінці проекту дуже важко.

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

Іноді на вашому вбудованому пристрої є планувальник процесів, який не робить те, що ви хочете, як користувач. Чорт важко виправити як вбудований розробник.

Складність викликає відставання через затримку в шаруванні. Ви запитали функції. Спробуйте справді стару Nokia, наприклад, стару 3210. Zippy швидкий інтерфейс користувача. Не багато функцій.

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

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

Якщо це не вказано, розробник звикне до нього. Ми всі це робимо. "Моя дитина не негарна"

І це не мови GC; Вбудована Java в реальному часі настільки швидка, що страшно. (Вбудований Python з іншого боку - це загальна собака)

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

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

Це тому, що всі вони написані керованими, зібраними сміттям мовами, а не рідним кодом?

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

Це окремі програмісти написали програмне забезпечення для цих пристроїв?

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

У всіх цих випадках розробники додатків точно знали, на яку апаратну платформу вони націлені та які її можливості; вони не врахували це?

Частково. Для початку точна апаратна платформа, напевно, не відома, оскільки про це часто домовляються з різними виробниками паралельно під час розробки програмного забезпечення. Насправді можуть бути навіть невеликі (але не обов'язково незначні) зміни базового обладнання після первинного випуску. Однак я погодився б, що загальні можливості будуть відомі.

Частина проблеми полягає в тому, що програмне забезпечення, ймовірно, не розробляється на апаратному забезпеченні, це робиться в емуляторах. Це ускладнює облік справжньої продуктивності пристрою, навіть якщо емулятори на 100% точні - чого вони не є.

Звичайно, це насправді не виправдовує недостатнє тестування відповідного обладнання для прототипу перед випуском. Ця провина, ймовірно, лежить поза контролем dev / qa.

Це той хлопець, який ходить навколо, повторюючи "оптимізація - корінь усього зла", чи зводив їх із збитків?

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

Більш ймовірно, що занадто багато програмістів приймають одну з двох крайнощів щодо оптимізації.

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

Це був менталітет "о, це просто додаткові 100 мс" кожного разу, поки всі ці мілісекунди не складуть хвилин?

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

Справа в тому, що сучасне обчислювальне обладнання (в тому числі вбудовані пристрої) відбувається набагато швидше, ніж люди їм дають заслугу. Більшість людей, навіть «досвідчені» програмісти, не в змозі оцінити, наскільки швидко працюють комп'ютери. 100 мс - це довго - дуже довго . І як це відбувається, цей "дуже довгий час" скорочує 2 способи:

• Перший полягає в тому, що програмісти непотрібно турбуються про те, що комп'ютер робить надзвичайно швидко. (Так трапляється, що саме таке занепокоєння " збільшення значення в 300 разів за секунду " призвело мене сюди насамперед.)
• Друга полягає в тому, що вони часом не виявляють належної стурбованості, коли справи займають дуже довго (на часовій шкалі обчислень). Так:
  • якщо вони ігнорують наслідки затримки під час спілкування по мережі або із пристроєм зберігання даних;
  • якщо вони ігнорують вплив заблокованої нитки і чекають чергової нитки;
  • якщо вони забудуть, що так як комп'ютери працюють так швидко, він дуже здатний повторити завдання набагато частіше, ніж слід, не розробник усвідомлює проблему
  • ... якщо виникає будь-яке поєднання таких оглядів, рутина буде несподівано працювати дуже повільно (на часовій шкалі обчислень). Кілька повторень, і це навіть буде помітно людям, - але, можливо, буде складно виправити, тому що сотні взаємопов’язаних речей швидко працюють самі по собі.

Чи я винен, що в першу чергу придбав ці продукти?

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

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

Але вони цього не роблять, тому ми і не; і з кожним роком нові мобільні телефони працюють повільніше на швидшому апаратному забезпеченні.

(Питання не задаються.)

• Чи винні люди з маркетингу? Частково. Їм потрібні дати випуску. І коли зазначена дата наступає, вибір між "примушувати її працювати" та "зробити це швидше" - не потрібний.
• Чи винні у цьому торгові люди? Частково. Вони хочуть отримати більше функцій у контрольному списку. Вони перекручують списки функцій і ігнорують продуктивність. Вони (іноді) дають нереалістичні обіцянки.
• Чи винні менеджери? Частково. Недосвідчені менеджери можуть допустити багато помилок, але навіть дуже досвідчені менеджери можуть (цілком справедливо) принести в жертву час для вирішення проблем ефективності на користь інших проблем.
• Чи винні специфікації? Частково. Якщо щось залишається поза специфікацією, про це набагато простіше "забути" згодом. І якщо конкретно не зазначено, яка мета? (Хоча я особисто вважаю, що якщо команда пишається своєю роботою, вони б турбувалися про результати роботи незалежно.)
• Чи винна освіта? Можливо. Навчання, ймовірно, завжди буде на ногах. Я, безумовно, не схвалюю "освіту", яка швидко витісняє початківців з поверхневим розумінням розробки програмного забезпечення. Однак освіта, яка підкріплена теорією і прищеплює культуру навчання, не може бути поганою.
• Чи винні оновлення? Частково. Нове програмне забезпечення, стара апаратура справді спокушає долю. Ще до виходу версії X планується X + 1. Нове програмне забезпечення сумісне, але чи є старе обладнання досить швидким? Це було випробувано? Конкретне виправлення продуктивності може бути включено в нове програмне забезпечення - заохочуючи необдумане оновлення програмного забезпечення.

В основному, я вважаю, що багато факторів, що сприяють цьому. Тож, на жаль, немає срібної кулі, яка б її виправити. Але це не означає, що це приреченість і похмурість. Є способи сприяти покращенню речей.

Отже, в який момент справи пішли не так у цих продуктів?

ІМХО, ми не можемо реально визначити жодну точку. Існує багато факторів, що сприяють розвиткові.

• Лічильники квасолі: скорочення витрат, ринкові терміни. Але знову ж таки ми зробили б аванси, які ми досягли без тиску?
• Високий попит і низький попит кваліфікованих працівників галузі. Не лише програмісти, а й менеджери, тестери та навіть продавці. Відсутність навичок та досвіду призводить до помилок. Але знову ж таки це призводить і до навчання.
• Найкраща технологія. Поки технологія не дозріє, вона буде регулярно кусатися несподіваними способами. Але потім знову ж таки це найчастіше дало низку переваг.
• Складне ускладнення. З часом галузь розвивалася: додавали більше інструментів, технологій, шарів, технік, абстракцій, апаратних засобів, мов, варіацій, варіантів. Це робить дещо неможливим «повне» розуміння сучасних систем. Однак ми також здатні зробити набагато більше за набагато коротший час.

Що ми можемо зробити як програмісти, щоб не завдати цього болю власним клієнтам?

У мене є кілька пропозицій (як технічних, так і нетехнічних), які можуть допомогти:

• Наскільки це можливо, використовуйте власний продукт. Немає нічого, як досвід з перших рук, щоб розкрити незручні, повільні або незручні речі. Однак вам потрібно буде свідомо уникати обходу недоліків через "інсайдерські знання". Наприклад, якщо у вас немає проблем із синхронізацією контактів, оскільки ви робите це із заднім сценарієм Python - ви не використовуєте "продукт". Що підводить наступний момент ...
• Слухайте своїх користувачів (бажано, з перших рук, але принаймні з другої руки через підтримку). Я знаю, що програмісти (як правило) вважають за краще ховатися подалі і уникати взаємодії з людьми; але це не допомагає виявити проблеми, які виникають інші люди під час використання вашого продукту. Наприклад, ви можете не помітити, що параметри меню повільні, оскільки ви знаєте всі ярлики і використовуєте їх виключно. Навіть якщо в посібнику повністю задокументовано всі ярлики, деякі люди все одно віддадуть перевагу меню - незважаючи на те, що вони є недостатньо повільними.
• Прагніть постійно вдосконалювати свої технічні навички та знання. Розвивайте вміння критично аналізувати все, що ви дізнаєтесь. Регулярно переоцінюйте свої знання. У деяких випадках будьте готові забути те, що ви думали, що знаєте. Що виховує ...
• Деякі технології / методи можуть бути дуже хитрими, що призводять до тонких непорозумінь та неправильної реалізації. Інші, завдяки еволюції загальних знань чи доступних інструментів, можуть вийти на користь або вийти з неї (наприклад, Singletons). Деякі теми настільки хитрі, що вони розмножують купу "hocus-pocus pundits", які розповсюджують величезну частину дезінформації. Особливим моїм помилкою є дезінформація навколо багаторізкових різьб. Хороша багатопотокова реалізація може значно покращити роботу користувачів. На жаль, багато дезінформованих підходів до багатопотокової роботи значно знизять продуктивність, збільшать помилкові помилки, збільшать ризики мертвих блокувань, ускладнять налагодження тощо. Тому пам’ятайте: тільки тому, що це сказав експерт, це не робить це правдою.
• Взяти на себе право власності. (Ні серйозно, я не граю в бінго зал.) Ведіть переговори з менеджерами, власниками продуктів, продавцями щодо функцій, які мають перевагу над деякими пунктами контрольного списку. Вимагайте кращих технічних характеристик. Не по-дитячому, а задаючи питання, які змушують людей замислюватися про продуктивність.
• Будьте вимогливим споживачем. Виберіть телефон, у якого менше функцій, але він швидший. (Не швидший процесор, швидший інтерфейс користувача.) Потім похвалитися цим ! Чим більше споживачів починають вимагати продуктивності, тим більше лічильників бобів почнуть складати бюджет.

Ваша перша помилка, і, ймовірно, чому ви отримали відмову від голосу, вона заслуговує на очевидно очевидне перебільшення. Ви справді сподіваєтесь повірити, що iPhone та iPad такі погані.

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

Ви звинувачуєте програмістів. Вони написали код, звичайно, але вони не визначали і не повинні визначати вимоги клієнтів, апаратне забезпечення, вартість BOM, вартість НДДКР, маркетинговий бюджет ..... все, що потрібно зробити продукт , це не програмне забезпечення.

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

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

Якщо у вас є iPhone 3G, Apple випустила кілька оновлень ОС, які були оптимізовані лише для нових пристроїв. Пізніші оновлення ОС для 3G можуть забезпечити трохи кращі показники роботи 3G.

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

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