Должен ли разработчик ориентироваться на читаемость или производительность?

Часто разработчик будет сталкиваться с выбором между двумя возможными способами решения проблемы - одним из которых является идиоматический и читаемый, а другой - менее интуитивным, но может работать лучше. Например, в языках на основе C существует два способа умножения числа на 2:

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

и

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

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

Как разработчик, который был бы лучше как первоначальная попытка?

Ответ 1

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

Первый код для правильности, затем для ясности (эти два часто связаны, конечно!). Наконец, и только если у вас есть реальные эмпирические данные, которые вам действительно нужны, вы можете посмотреть на оптимизацию. Преждевременная оптимизация действительно зла. Оптимизация почти всегда стоит вам времени, ясности, ремонтопригодности. Лучше быть уверенным, что вы покупаете что-то стоящее с этим.

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

Ответ 2

IMO - очевидная читаемая версия, до тех пор, пока производительность не будет измерена и не потребуется более быстрая версия.

Ответ 3

Возьмите его из Дон Кнут

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

Ответ 4

Считываемость 100%

Если ваш компилятор не может выполнить оптимизацию "x * 2" = > "x < 1" для вас - получите новый компилятор!

Также помните, что 99,9% вашего времени программы затрачивается на ожидание ввода пользователя, ожидание запросов к базе данных и ожидание сетевых ответов. Если вы не делаете многократный 20-биллион раз, это не будет заметно.

Ответ 5

В данном примере 99,9999% компиляторов там будут генерировать одинаковый код для обоих случаев. Это иллюстрирует мое общее правило: сначала пишите для удобства чтения и обслуживания, и оптимизируйте его только тогда, когда вам нужно.

Ответ 6

Конечно, читаемость. Не беспокойтесь о скорости, если кто-то не жалуется

Ответ 7

читаемости.

У кодирования производительности есть собственный набор проблем. Джозеф М. Ньюком сказал, что well

Оптимизация имеет значение только тогда, когда вопросы. Когда это имеет значение, важно много, но пока вы не узнаете, что это вопросы, не тратьте много времени Делать это. Даже если вы знаете, что это важно, вам нужно знать, где это важно. Без данных о производительности вы не будете знать, что оптимизировать, и вы будете вероятно, оптимизировать неправильную вещь.

Результат будет неясным, трудно писать, трудно отлаживать и трудно поддерживать код, который не проблема. Таким образом, он имеет двойственный недостаток (а) увеличения разработка программного обеспечения и программного обеспечения расходы на техническое обслуживание и (b) отсутствие эффект производительности вообще.

Ответ 8

читаемость. Время для оптимизации - это когда вы добираетесь до бета-тестирования. В противном случае вы никогда не знаете, что вам нужно, чтобы провести время.

Ответ 9

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

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

Ответ 10

Часто упущенный фактор в этой дискуссии - дополнительное время, которое требуется программисту для навигации, понимания и изменения менее читаемого кода. Учитывая, что время программиста идет на сто долларов в час или более, это очень реальная стоимость. Любое увеличение производительности компенсируется этой прямой дополнительной стоимостью в разработке.

Ответ 11

Вставка комментария там с объяснением сделает его читаемым и быстрым.

Это действительно зависит от типа проекта и от того, насколько важна производительность. Если вы строите 3D-игру, тогда обычно есть много общих оптимизаций, которые вы хотите бросить туда по пути, и нет причин не делать этого (просто не слишком рано увлекайтесь). Но если вы делаете что-то сложное, прокомментируйте это, так что любой, кто смотрит на него, будет знать, как и почему вы сложны.

Ответ 12

Ответ зависит от контекста. Например, в программировании драйверов устройств или разработке игр вторая форма является приемлемой идиомой. В бизнес-приложениях не так много.

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

Ответ 13

И. Ваш код должен балансировать оба; читабельности и производительности. Потому что игнорирование одного из них приведет к обвинению ROI проекта, что в конце дня - все, что имеет значение для вашего босса.

Плохая читаемость приводит к снижению ремонтопригодности, что приводит к большему количеству ресурсов, потраченных на техническое обслуживание, что приводит к снижению ROI.

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

Ответ 14

с использованием < с помощью микро-оптимизации. Так правило Хоара (не Кнуца):

Преждевременная оптимизация является корнем всего зла.

и вы должны просто использовать более читаемую версию в первую очередь.

Это правило - ИМХО часто злоупотребляют как предлог для разработки программного обеспечения, которое никогда не может масштабироваться или работать хорошо.

Ответ 15

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

Ответ 16

Если вас беспокоит читаемость вашего кода, не стесняйтесь добавлять комментарий, чтобы напомнить себе, что и почему вы это делаете.

Ответ 17

Сдвиг по сравнению с умножением - это тривиальная оптимизация, которая получает рядом с ничего. И, как уже указывалось, ваш компилятор должен сделать это за вас. Кроме того, коэффициент усиления неактивен, как и процессор, на котором работает эта команда.

С другой стороны, если вам нужно выполнить серьезные вычисления, вам потребуются правильные структуры данных. Но если ваша проблема сложна, узнавать об этом является частью решения. В качестве иллюстрации рассмотрим поиск идентификационного номера в массиве из 1000000 несортированных объектов. Затем передумайте, используя двоичное дерево или хэш-карту.

Но оптимизации, такие как n < C, как правило, пренебрежимо малы и тривиальны в любой точке. Чтение кода невозможно.

Ответ 18

Это зависит от задачи, которую необходимо решить. Обычно читаемость более важна, но есть еще некоторые задачи, когда вы думаете о производительности в первую очередь. И вы не можете просто потратить день или на профилирование и оптимизацию после того, как все работает отлично, потому что сама оптимизация может потребовать перезаписи достаточной части кода с нуля. Но сегодня это не так.

Ответ 19

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

Сказав это, вы всегда можете помещать комментарии в то, где требуется прояснить кодировку.

Ответ 20

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

Ответ 21

Предполагается, что около 70% стоимости программного обеспечения находится в обслуживании. Читаемость упрощает обслуживание системы и, следовательно, снижает стоимость программного обеспечения на протяжении всей жизни.

Бывают случаи, когда производительность важнее читаемости, при этом говорят, что они немногочисленны и далеко друг от друга.

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

Ответ 22

Я не работаю в Google, поэтому я бы пошел на злой вариант. (Оптимизация)

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

Ответ 23

Как почти все сказали в своих ответах, я предпочитаю удобочитаемость. 99 из 100 проектов, которые я запускаю, не имеют жестких требований времени отклика, поэтому это простой выбор.

Прежде чем начать кодирование, вы должны уже знать ответ. Некоторые проекты имеют определенные требования к производительности, такие как "нужно иметь возможность запускать задачу X в Y (миллисекунд) секунд". Если это так, у вас есть цель работать, и вы знаете, когда вам нужно оптимизировать или нет. (надеюсь) это определяется на этапе требований вашего проекта, а не при написании кода.

Хорошая читаемость и возможность оптимизации в дальнейшем - результат правильного проектирования программного обеспечения. Если ваше программное обеспечение имеет звуковой дизайн, вы должны иметь возможность изолировать части своего программного обеспечения и переписывать их, если необходимо, без нарушения других частей системы. Кроме того, большинство реальных случаев оптимизации, с которыми я столкнулся (игнорируя некоторые реальные низкоуровневые трюки, случайные), переходили от одного алгоритма к другому или кэшировали данные в память вместо диска/сети.

Ответ 24

Считываемость - это ПЕРВАЯ цель.

В 1970 году армия проверила некоторые из "новых" технологий разработки программного обеспечения (сверху вниз, структурированное программирование, главные команды программистов, чтобы назвать несколько), чтобы определить, какая из них сделала статистически значимую разницу.

ТОЛЬКО метод, который сделал статистически значимую разницу в развитии, был...

ДОБАВЛЕНИЕ БЛОКОВЫХ ЛИНИЙ в программный код.

Улучшение удобочитаемости в тех предварительно структурированных, пред-объектно-ориентированных кодексах было единственным методом в этих исследованиях, который повысил производительность.

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

Оптимизация должна решаться только тогда, когда весь проект тестируется на единицу и готов к работе с прибором. Вы никогда не знаете, WHERE вам нужно оптимизировать код.

В своих знаковых книгах Kernigan и Plauger в конце 1970 года ПРОГРАММНЫЕ СРЕДСТВА (1976) и ПРОГРАММНЫЕ СРЕДСТВА В PASCAL (1981) показали способы создания структурированных программ с использованием дизайна сверху вниз. Они создали программы обработки текста: редакторы, инструменты поиска, предварительные процессоры кода.

Когда заполненная функция форматирования текста была INSTRUMENTED, они обнаружили, что большая часть времени обработки была потрачена на три процедуры, которые выполняли ввод и вывод текста (в оригинальной книге функции io занимали 89% времени. В книге pascal, эти функции потребляли 55%!)

Они смогли оптимизировать эти три процедуры и дали результаты повышенной производительности с разумным, управляемым временем разработки и стоимостью.

Ответ 25

Считывание сначала. Но даже больше, чем читаемость, простота, особенно с точки зрения структуры данных.

Мне напомнили, что студент делает программу анализа видения, которая не понимает, почему это было так медленно. Он просто следовал хорошей практике программирования - каждый пиксель был объектом, и он работал, отправляя сообщения своим соседям...

проверьте это

Ответ 26

Если нет читаемости, будет очень сложно добиться повышения производительности, когда вам это действительно нужно.

Производительность должна быть улучшена только в том случае, если это проблема в вашей программе, есть много мест, а не синтаксиса. Скажем, вы улучшаете 1ns улучшение на < но проигнорировал это 10-минутное время ввода-вывода.

Кроме того, в отношении удобочитаемости профессиональный программист должен уметь читать/понимать понятия компьютерной науки. Например, мы можем назвать метод enqueue, а не говорить putThisJobInWorkQueue.

Ответ 27

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

Ранняя чрезмерная оптимизация, конечно, довольно плоха, когда вы попадаете в проблему позже, когда вам нужно реорганизовать, но это не относится к оптимизации отдельных методов, блоков кода или операторов.

Ответ 28

Я бы сказал, что нужно читать.

Но в данном примере я думаю, что вторая версия уже достаточно читаема, так как имя функции точно заявляет, что происходит в функции.

Если бы у нас всегда были функции, которые говорили нам, что они делают...

Ответ 29

Сколько стоит процессор времени процессора?

Сколько стоит час времени программиста?

Ответ 30

ИМХО, обе вещи не имеют ничего общего. Сначала вы должны использовать код, который работает, поскольку это важнее производительности или того, насколько хорошо он читается. Что касается читаемости: ваш код всегда должен быть доступен для чтения в любом случае.

Однако я не понимаю, почему код не может быть доступен для чтения и одновременно обеспечивает хорошую производительность. В вашем примере вторая версия так же читаема, как и первая. Что менее читаемо? Если программист не знает, что сдвиг влево - это то же самое, что умножение на силу двух, а смещение вправо - то же самое, что и деление на две силы... ну, тогда у вас есть гораздо более основные проблемы, чем общая читаемость.