Чи повинен розробник прагнути насамперед читабельність чи продуктивність? [зачинено]

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

int SimpleMultiplyBy2(int x)
{
    return x * 2; 
}

і

int FastMultiplyBy2(int x)
{
    return x << 1;
}

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

Як розробнику, що було б краще для початкової спроби?

Ви пропустили один.

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

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

Спочатку IMO очевидну читабельну версію, поки не виміряється продуктивність і не потрібна швидша версія.

Візьміть це у дона Кнута

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

Читаність 100%

Якщо ваш компілятор не може зробити для вас оптимізацію "x * 2" => "x << 1" - отримайте новий компілятор!

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

У наведеному прикладі 99,9999% компіляторів згенерують однаковий код для обох випадків. Що ілюструє моє загальне правило - спочатку пишіть для читабельності та ремонтопридатності, а оптимізуйте лише тоді, коли вам потрібно.

Читаність точно. Не хвилюйтеся про швидкість, якщо хтось не скаржиться

Читаність.

Кодування для продуктивності має свої власні проблеми. Джозеф М. Новачок сказав це добре

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

Результат буде неясним, важким для написання, важким для налагодження та важким для обслуговування кодом, який не вирішить вашу проблему. Таким чином, він має подвійний недолік (a) збільшення витрат на розробку програмного забезпечення та обслуговування програмного забезпечення, і (b) взагалі відсутність ефекту продуктивності.

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

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

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

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

Поміщення коментаря з поясненням зробить його читабельним і швидким.

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

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

Найкраще подивитися на код (або в подібних успішних додатках), щоб перевірити, як це роблять інші розробники.

використання << буде шляхом мікрооптимізації. Тож правило Хоара (а не Натса):

Передчасна оптимізація - корінь усього зла.

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

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

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

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

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

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

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

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

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

Я не працюю в google, тому я б вибрав злий варіант. (оптимізація)

У 6-му розділі Джона Бентлі "Програмування перлів" він описує, як одна система в 400 разів пришвидшилася, оптимізувавши на 6 різних рівнях дизайну. Я вважаю, що, не дбаючи про продуктивність на цих 6 рівнях дизайну, сучасні реалізатори можуть легко досягти 2-3 порядків уповільнення у своїх програмах.

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

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

Але такі оптимізації, як n << C, як правило, нехтують і тривіальні, щоб їх можна було змінити в будь-який момент. Зробити код читабельним - це не так.

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

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

За підрахунками, близько 70% вартості програмного забезпечення припадає на обслуговування. Легкість читання робить систему простішою в обслуговуванні, а отже, знижує вартість програмного забезпечення протягом усього життя.

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

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

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

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

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

Читаність - ПЕРША ціль.

У 70-х рр. Армія випробувала деякі «нові» на той час техніки розробки програмного забезпечення (дизайн зверху вниз, структуроване програмування, назви декількох команд програмістів), щоб визначити, який із них мав статистично значущу різницю.

ЄДИНА техніка, яка зробила статистично значущу різницю у розвитку, була ...

ДОДАВАННЯ ПОРОЖНИХ РЯДКІВ до програмного коду

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

==============

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

У своїх знакових книгах Керніган та Плаугер наприкінці 1970-х років SOFTWARE TOOLS (1976) та SOFTWARE TOOLS IN PASCAL (1981) показали способи створення структурованих програм за допомогою дизайну зверху вниз. Вони створили програми обробки тексту: редактори, інструменти пошуку, попередні процесори коду.

Коли функцію форматування тексту було завершено ІНСТРУМЕНТУВАНО, вони виявили, що більшу частину часу обробки проводили у трьох процедурах, що виконували введення та виведення тексту (в оригінальній книзі функції io займали 89% часу. У книзі паскалів ці функції споживається 55%!)

Вони змогли оптимізувати ці ТРИ процедури і дали результати підвищеної продуктивності з розумним, керованим часом розробки та витратами.

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

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

заціни

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

Ефективність роботи слід покращувати лише тоді, коли у вашій програмі виникає проблема. Існує багато місць, де шийка пляшки замість цього синтаксису. Скажімо, ви знищуєте 1ns покращення на <<, але ігнорували 10 хвилин часу вводу-виводу.

Також щодо читабельності професійний програміст повинен вміти читати / розуміти терміни інформатики. Наприклад, ми можемо назвати чергу методів, а не говорити putThisJobInWorkQueue.

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

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

Я б сказав, подивіться на читабельність.

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

Якби ми просто завжди мали функції, які підказували нам, що вони роблять ...

Скільки коштує година процесорного часу?

Скільки коштує година програміста?

ІМХО обидві речі не мають нічого спільного. Спочатку слід вибрати код, який працює, оскільки це важливіше за продуктивність чи наскільки добре він читається. Щодо читабельності: ваш код завжди повинен бути читабельним у будь-якому випадку.

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