Производительность против удобочитаемости

Question

Чтение этот вопрос Я нашел это как (обратите внимание на кавычки) «код» для решения проблемы (кстати, это perl).

100,{)..3%!'Fizz'*\5%!'Buzz'*+\or}%n*

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

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

Answer 1

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

1. Заставь это работать.
2. Проясни.
3. Проверка производительности.
4. Если есть существенные проблемы с производительностью: рефакторинг для скорости.

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

Answer 2

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

Answer 3

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

Ключ в том, чтобы иметь хорошие тесты, чтобы рефакторинг был легким.

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

Answer 4

Мой любимый ответ на этот вопрос:

1. Заставь это работать
2. Сделай все правильно
3. Сделай это быстро

С точки зрения вещей никто не дает дерьма о читабельности, кроме следующего несчастного дурака, который должен заботиться о вашем коде. Однако, как говорится ... если вы серьезно относитесь к своему искусству, и это художественная форма, вы всегда будете стремиться сделать свой код максимально формальным, каким он может быть, оставаясь при этом читаемыми для других. Мой друг и наставник (который является BADASS во всех отношениях) однажды милостиво сказал мне в обзоре кода, что «дурак пишет код, который могут понять только они, гений пишет код, который может понять каждый». Я не уверен, откуда он это взял, но он застрял у меня.

Ссылка

Answer 5

Программы должны быть написаны, чтобы люди могли их читать, и только случайно машины для исполнения.
& mdash; Абельсон и Суссман, SICP

Хорошо написанные программы, вероятно, легче профиль и, следовательно, улучшить производительность .

Answer 6

согласен со всем вышеперечисленным, но также:

когда вы решите, что хотите оптимизировать:

1. Исправить алгоритмические аспекты перед синтаксисом (например, не выполнять поиск в больших массивах)
2. Убедитесь, что вы доказали, что ваши изменения действительно улучшили ситуацию, измерьте все
3. Прокомментируйте вашу оптимизацию, чтобы следующий парень, увидев эту функцию, не упростил ее до того места, с которого вы начали
4. Можете ли вы предварительно вычислить результаты или переместить вычисление туда, где это можно сделать более эффективно (например, в дб)

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

Answer 7

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

«Если вы спешите, проделайте длинный путь».

Answer 8

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

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

Answer 9

Читаемость всегда побеждает. Всегда. За исключением случаев, когда это не так. И это должно быть очень редко.

Answer 10

«Преждевременная оптимизация - корень всего зла». - Дональд Кнут