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


26

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

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

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

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

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

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


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

12
@errantlinguist: Якщо програма дійсно "повільна, як патока", то, очевидно, ви повинні мати можливість легко виявити "критичні 3%" Кнута, і тому доводити будь-які аргументи проти її оптимізації. І якщо ви не можете цього виявити ... тоді ви ще не зробили домашнє завдання і ще не готові до оптимізації. Тож незрозуміло, де проблема.
Ніколь Болас

6
@errantlinguist: Якщо ви представили докази того, що цей розділ коду є суттєвою проблемою продуктивності для програми, а програма в цілому йшла повільніше, ніж це було потрібно, і вони все ж заперечували необхідність зміни коду, то це не означає " t матерія. Ви маєте справу з людьми, які не сприймають міркувань, заснованих на доказах, і, таким чином, нерозумні.
Нікол Болас

6
@errantlinguist: Ключове питання: Чи скаржились клієнти на те, що додаток у цій галузі повільний?
Gort the Robot

5
Я голосую за закриття, оскільки ОП явно шукає лише когось для підтвердження думки, а не відповіді на актуальне запитання. Я не думаю, що це також (або повинно) залишатися відкритим на Workplace.SE.
BlueRaja - Danny Pflughoeft

Відповіді:


35

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

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

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

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

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

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

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


15
@errantlinguist: можливо, я не дав про себе зрозуміти, або це просто не те, що хотілося почути? Моя порада: не намагайтеся використовувати * філософські аргументи "Кнута про" 3% "або" 97% ". Тримайте це фактично, інакше ваші колеги, ймовірно, мають рацію, що ваші аргументи про ефективність є невідповідними.
Doc Brown

4
@errantlinguist: у випадку, якщо ви описали у своєму коментарі відповідь Карла Білефельда, ви, здається, маєте всі аргументи на вашій стороні, не потребуючи використання "вистави". Я б пішов на крок далі і сказав, що якщо ви сперечаєтесь про результативність у такому випадку, ви робите величезну помилку, тому що ваші колеги мають рацію: виступ там зазвичай не має значення. Сперечайтеся про простоту, читабельність, ремонтопридатність, менше рядків коду, але не (!) Про продуктивність, навіть не як бічну увагу. Не пропонуйте їм можливості використовувати Knuth проти вас.
Doc Brown

2
@errantlinguist: чи не ховати його - поставити ці аспекти в центр уваги, коли це правильно , що ці аспекти повинні бути в центрі уваги, і не використовувати продуктивність в якості аргументу , коли ви не можете довести це , що вона робить важливе значення для кінцевого користувача.
Doc Brown

2
@errantlinguist: Я не впевнений, як ви дійшли до цього висновку. Відповідь Дока Брауна здається абсолютно зрозумілою: ви вирізаєте ці непродуктивні аргументи, які ви маєте зі своїми колегами, дотримуючись фактичних тверджень про те, що є, а що не є прийнятною ефективністю.
jl6

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

18

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

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

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

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

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

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


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

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

@StevenBurnap: Так - чи є в природі веб-додатки, які насправді не повільні? - Я хотів би бачити один із тих же наук.
errantlinguist

1
google.com проходить досить швидко. :-P
Gort the Robot

Спробуйте використовувати google.com для мобільного з'єднання EDGE. Так, це смішна крайова справа, але вона точно не буде досить швидкою . ;) (Pun фактично не призначений-- дійсно)
errantlinguist

7

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

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

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

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

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

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

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

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

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

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

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

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

Лідерство

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

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


6

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

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

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

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

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

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

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


Ну, я повністю погоджуюся з вашим початковим реченням. Однак я впевнений, що частина програмного забезпечення може бути "дратівливою повільністю для призначеного випадку використання", не маючи чітко визначених вимог до продуктивності.
Doc Brown

@DocBrown: Звичайно, але у будь-якому випадку саме клієнт вирішує, чи занадто повільно це чи ні, а не розробник.
ЖакБ

Я ніколи не стикався з діловими вимогами, які прямо заявляють вимоги до ефективності.
errantlinguist

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

4

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

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

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

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

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

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


2
Можна додати, що Кнут явно не вважає, що аналіз складності часу алгоритмів та вибір дизайну на цій основі - це передчасна оптимізація.
sdenham

3

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

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


На жаль, я фактично зробив зворотний випадок, коли я використовую, наприклад, Dequeзі стандартної бібліотеки Java, щоб замінити величезну кількість логіки, побудованої навколо ArrayListвикористовуваного як стека під час роботи над кодом ... і це було позначено для зміна в огляді. Іншими словами, рецензент хотів мати більше коду, який також повільніше і більш схильний до помилок, оскільки він не був знайомий з ним Deque.
errantlinguist

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

5
@errantlinguist: коли ваш рецензент запропонував явно гірше (що означає складніше) рішення як заміну на чисте та просте, вам слід заперечити про це. Не сперечайтесь про продуктивність! Серйозно, ніколи навіть не використовуйте слово "вистава" у цій дискусії. Аргументуйте лише про читабельність та ремонтопридатність. І якщо рецензент наполягає на своєму поганому коді, ескалація.
Doc Brown

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

2

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

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

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

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


Це не означає, що вам слід вимкнути мозок. Це не означає, що ви повинні зберігати 10 000 записів клієнтів у однозначно пов'язаному списку. > Хоча я погоджуюся з вами на 100% з цього приводу, я фактично бачив пов'язані списки, використовувані таким чином, і мені сказали "не торкатися цього".
errantlinguist

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

3
На жаль, річ "окремо пов'язаного списку" була не випадковим прикладом, а чимось я особисто зіткнувся.
Гурт Робота

1

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

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

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

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


5
Ніколи не існує "неправильного шляху" чи "правильного шляху". Зазвичай існує нескінченна кількість способів, які проходять у континуумі від "Боже мій, як це навіть працює!" до "Джон Кармак та Дональд Кнут не могли зробити це кращим під час парного програмування".
Gort the Robot

@StevenBurnap Це правда. Однак я думаю, що для людей, як правило, є кілька правильних способів і багато неправильних способів. (По мірі того, як ми стаємо кращими програмістами, цей спектр починає змінюватися - наші старі "правильні шляхи" іноді можуть ставати нашими новими "неправильними шляхами", тоді як наші нові правильні шляхи кращі, ніж старі.) Я думаю, що добре робити справи в найкращий, найправильніший для вас спосіб . Це призводить до того, що ми стаємо кращими програмістами, стаємо кращими товаришами по команді (наставницькі справи!) Та пишемо кращий код.
обідне м'ясо317

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

1

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

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

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


Я відреагував відповідь і деталізував деталі трохи, чи міг би хтось подати відгук? :)
сара

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

в основному те, що я хочу натрапити на останні два абзаци, - це "ті оптимізації можуть навіть не мати значення". в такому випадку краще вибирати свої бої.
сара
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.