Разработчик должен стремиться к удобочитаемости или производительности сначала? [закрытый]

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

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

и

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

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

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

74
задан 3 revs 8 October 2008 в 16:11
поделиться

33 ответа

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

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

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

96
ответ дан 2 revs 7 November 2019 в 07:27
поделиться

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

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

1
ответ дан paperhorse 7 November 2019 в 07:27
поделиться

Запишите для удобочитаемости сначала, но ожидайте, что читатели будут программисты . Какой-либо достойный программист должен знать различие между умножением и сдвигом разряда, или быть в состоянии считать тернарный оператор, где это используется соответственно, быть в состоянии искать и понять сложный алгоритм (Вы комментируете свое право кода?), и т.д.

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

0
ответ дан wprl 7 November 2019 в 07:27
поделиться

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

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

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

1
ответ дан Erik van Brakel 7 November 2019 в 07:27
поделиться

Удобочитаемость является ПЕРВОЙ целью.

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

ЕДИНСТВЕННАЯ техника, которая сделала статистически значимые различия в разработке, была...

ДОБАВЛЯЮЩИЕ ПУСТЫЕ СТРОКИ для программирования кода.

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

оптимизация ==============

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

В их ориентире заказывает Kernigan и Plauger в конце ПРОГРАММНЫХ ИНСТРУМЕНТОВ 1970-х (1976), и ПРОГРАММНЫЕ ИНСТРУМЕНТЫ В ПАСКАЛЕ (1981) показали, что способы создать структурированные программы с помощью вершины вниз разрабатывают. Они создали программы обработки текста: редакторы, средства поиска, кодируют препроцессоры.

, Когда завершенная текстовая функция форматирования была ОСНАЩЕНА, они обнаружили, что большая часть времени обработки была проведена в трех стандартных программах, которые выполнили ввод текста и произвели (В исходной книге, функции i-o взяли 89% времени. В книге Паскаля эти функции использовали 55%!)

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

1
ответ дан SystemSmith 7 November 2019 в 07:27
поделиться

Я сказал бы, идут для удобочитаемости.

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

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

0
ответ дан Dan Soap 7 November 2019 в 07:27
поделиться

Считается, что приблизительно 70% стоимости программного обеспечения находятся в обслуживании. Удобочитаемость делает систему легче поддержать и поэтому снижает стоимость программного обеспечения по его жизни.

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

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

1
ответ дан Peter Tomlins 7 November 2019 в 07:27
поделиться

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

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

0
ответ дан Mecki 7 November 2019 в 07:27
поделиться

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

1
ответ дан ICR 7 November 2019 в 07:27
поделиться

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

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

0
ответ дан Andy Lester 7 November 2019 в 07:27
поделиться

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

Однако можно всегда вставлять комментарии, где для гладкого кодирования нужно разъяснение.

1
ответ дан Lance Roberts 7 November 2019 в 07:27
поделиться

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

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

проверка это

1
ответ дан Mike Dunlavey 7 November 2019 в 07:27
поделиться

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

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

5
ответ дан 3 revs 7 November 2019 в 07:27
поделиться

100% удобочитаемости

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

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

19
ответ дан 2 revs, 2 users 91% 7 November 2019 в 07:27
поделиться

Удобочитаемость. Время для оптимизации - когда Вы добираетесь до тестирования бета-версии. Иначе Вы никогда действительно знаете то, на чем необходимо провести время.

5
ответ дан NotMe 7 November 2019 в 07:27
поделиться

Удобочитаемость.

Кодирование для производительности имеет свой собственный набор проблем. Joseph M. Newcomer сказал это хорошо

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

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

8
ответ дан nwahmaet 7 November 2019 в 07:27
поделиться

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

8
ответ дан Paul Tomblin 7 November 2019 в 07:27
поделиться

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

8
ответ дан Miles 7 November 2019 в 07:27
поделиться

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

1
ответ дан akalenuk 7 November 2019 в 07:27
поделиться

Часто пропускаемым фактором в этих дебатах является дополнительное время, которое требуется для программиста, чтобы переместиться, понять и изменить меньше кода readible. Рассмотрение времени программиста идет за сто долларов в час или больше, это - очень реальная стоимость.
Любому увеличению производительности противостоят эти прямые дополнительные расходы в разработке.

4
ответ дан Rik 7 November 2019 в 07:27
поделиться

Возьмите его от Don Knuth

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

46
ответ дан Ryan 7 November 2019 в 07:27
поделиться

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

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

3
ответ дан ilitirit 7 November 2019 в 07:27
поделиться

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

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

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

3
ответ дан 2 revs 7 November 2019 в 07:27
поделиться

использование < < был бы микро оптимизацией. Так Hoare (не Knuts) правило:

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

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

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

3
ответ дан kohlerm 7 November 2019 в 07:27
поделиться

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

2
ответ дан mspmsp 7 November 2019 в 07:27
поделиться

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

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

4
ответ дан Gerald 7 November 2019 в 07:27
поделиться

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

2
ответ дан Michael McCarty 7 November 2019 в 07:27
поделиться

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

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

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

1
ответ дан mstrobl 7 November 2019 в 07:27
поделиться

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

58
ответ дан kenny 7 November 2019 в 07:27
поделиться

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

0
ответ дан DarthNoodles 7 November 2019 в 07:27
поделиться
Другие вопросы по тегам:

Похожие вопросы: