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

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

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

Попередні спроби

Кілька разів я намагався надати повну цитату від Дональда Кнута , щоб пояснити, що "передчасна оптимізація погана" ↛ "вся оптимізація погана":

Слід забути про невелику ефективність, скажімо, про 97% часу: передчасна оптимізація - корінь усього зла. Але ми не повинні пропускати наші можливості на критичних 3%.

Однак, надаючи цілу цитату, ці люди іноді насправді стають більш впевненими, що те, що я роблю, - це передчасна оптимізація ™ і копатись та відмовлятися слухати. Це майже так, якби слово "оптимізація" їх лякає: я кілька разів міг запропонувати фактичні зміни коду, що покращують продуктивність, не ветуючи їх, просто уникаючи використання слова "optimiz (e | ation)" ( а також "продуктивність" - це слово теж страшно), а замість цього використовується якийсь вираз на зразок "альтернативна архітектура" або "покращена реалізація". З цієї причини насправді здається, що це справді є догматизмом, а не вони насправді оцінюють те, що я говорю критично, а потім відкидаю це як не потрібне та / або занадто дороге.

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

На мій досвід, вам доведеться або кусати кулю, і спробувати спочатку "наївну реалізацію" (і, мабуть, будете здивовані, як часто це досить швидко), або ви принаймні зробите приблизну оцінку часу виконання, наприклад:

"Наївна реалізація буде O (n³), і n більше 100 000; це триватиме кілька днів, тоді як не наївна реалізація буде працювати в O (n), що займе лише кілька хвилин" .

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

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

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

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

Запитайте себе так:

• Чи програмне забезпечення НЕ відповідає специфікації продуктивності?
• Чи програмне забезпечення має проблеми?

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

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

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

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

Як працювати з людьми, які обробляють стіну дискусією за ту хвилину, яку вона має відношення до продуктивності?

Почніть із загальних принципів, які ґрунтуються на стратегічному напрямку вашої групи.

Мої принципи:

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

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

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

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

Якщо припустити необхідність оптимізації, це правильно

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

"Програмісти витрачають величезну кількість часу на роздуми або занепокоєння швидкості некритичних частин своїх програм. Ці спроби ефективності насправді мають сильний негативний вплив при розгляді налагодження та обслуговування. Ми повинні забути про невелику ефективність, скажімо про 97% часу: передчасна оптимізація - це корінь усього зла. Але ми не повинні пропускати свої можливості в цих критичних 3% ". - Дональд Кнут

Зважте витрати додаткової складності

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

Лідерство

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

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

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

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

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

Більш загально, є дві можливості щодо оптимізації:

1. Оптимізований код також коротший, простіший для розуміння та легший в обслуговуванні.

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

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

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

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

Але ми не повинні пропускати наші можливості на критичних 3%. Хороший програміст не буде заспокоєний самовдоволення такими міркуваннями, він буде розумним уважно переглянути критичний код; але лише після виявлення цього коду

- Дональд Кнут, Структурне програмування з переходом до заяв , обстеження обчислень ACM, т. 6, № 4, грудень 1974, с.268

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

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

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

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

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

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

Це "передчасний" в "передчасна оптимізація". Коли це не "передчасно"? Коли клієнти скажуть вам "це занадто чортово повільно, виправте це!" Ось тоді ви копаєте код і намагаєтесь зробити це швидше.

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

Ви можете робити речі неправильно, або робити все правильно.

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

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

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

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

Більш орієнтований на фактичне програмування, не витрачайте час на довгі аргументи з приводу того, що у вас просто відчуття кишечника "швидше". Якщо у веб-додатку ви бачите, хто пише метод, який викликається один раз за запитом, і він має складну часову складність O (n ^ 2), коли ви знаєте, що це дійсно проблема часу O (log (n)), тоді обов'язково, якщо це такий ні розумник, йти вперед.

Будьте в курсі, хоча ми, як люди, програмісти насправді погані (і я маю на увазі ДУЖЕ) у здогадуванні, які частини наших додатків будуть вузькими місцями. Ерік Ліпперт пише про цю цікаву тему в цій публікації в блозі. Завжди підтримуйте технічне обслуговування. Будь-які проблеми з ефективністю, які врешті-решт виявляються, можуть бути легко (добре, відносно) виправлені, коли у вас буде більше інформації.