Приоритеты кодирования:Производительность, Ремонтопригодность, возможность повторного использования?

Question

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

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

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

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

Answer 1

1.Ремонтопригодность: Если код нечитаем, он бесполезен, независимо от того, насколько он быстр.И это определенно не будет использовано повторно.

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

3.Производительность: Как правило, большая часть кода достаточно производительна.А если нет, используйте профилировщик кода.Чаще всего узкое место намного перевешивает любые небольшие оптимизации кода, которые вы могли бы произвести за счет либо удобочитаемости, либо возможности повторного использования.

Answer 2

Я думаю, вы пропустили что-то из списка:надежность;

итак, мой приказ таков

• Надежность и точность
• Ремонтопригодность
• Возможность повторного использования
• Производительность

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

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

Я работал над системами реального времени, включая имитацию полета, и даже в этой среде производительность принимается во внимание, но не является первостепенной задачей ¹.

Я бы сказал, что, по моему опыту, мне когда-либо приходилось оптимизировать менее 1% написанного мной кода.

---

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

Answer 3

Самый простой ответ, конечно, "это зависит".

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

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

Answer 4

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

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

Как и Гиннесс, заявленный в вопросе, пока программное обеспечение не занимает исключительное количество времени, они, похоже, не возражают.

Другая главная проблема, которую они, по-видимому, испытывают, - это удобство использования.Приложение должно быть простым и понятный в использовании.

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

Answer 5

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

1. Один из них работает в режиме реального времени, и требуется много работы, чтобы убедиться, что его производительность предсказуема (не обязательно быстро повышается), но изменения не являются серьезной проблемой, они существенно меняются только тогда, когда IETF изменяет / устаревает RFC, и на это мало что указывает.(Тем не менее, я очень горжусь его уровнем ремонтопригодности).

   • Другому приложению иногда требовалось 16 часов для обработки данных за 1 день.Излишне говорить, что абсолютная производительность быстро стала главным приоритетом.Но даже в этом приложении акцент на производительности сильно варьируется: от "неважного" в коде для каждого пакета через код для каждого клиента, код для каждой задачи, код для каждого файла, код для каждой записи, код для каждого поля до "чрезвычайно важного" в коде для каждого байта.

   • Конечное приложение содержит большую часть бизнес-логики, производительность никогда не является проблемой, ремонтопригодность и гибкость являются ключевыми, и это приложение извлекает наибольшую выгоду из всех модных методологий, однако, когда я только что потратил недели или месяцы на рефакторинг для повышения производительности, очень сложно написать "string1 + string2 + string3 + string4", даже если это наиболее читабельно, а производительность не имеет значения.

Answer 6

Отредактировано 2010-03-02:Изначально возникший вопрос:

Все ли работают на НАСА?Всегда ли производительность стоит на первом месте?Так много ответов ...

Нет - большинство из нас не работают на НАСА.

НЕТ:надежность и ремонтопригодность превыше производительности.Возможность повторного использования тоже хороша.

В широких пределах производительность не важна.

Answer 7

Это интересный вопрос, и ответы на него достаточно интересны.Приоритет зависит от реализации.Я хотел бы представить один из примеров, когда пользователи не стали бы жертвовать производительностью ради ремонтопригодности или возможности повторного использования.Да, есть фактор надежности - должна быть какая-либо ошибка.Итак, когда мы сравниваем ремонтопригодность, производительность и возможность повторного использования.

У одного нашего клиента был сайт онлайн-торговли.При пиковых нагрузках для завершения транзакции на уровне промежуточного программного обеспечения в среднем требуется около 14 мс.Спустя некоторое время производительность приложения снизилась (по некоторым причинам), а среднее время транзакций увеличилось до 24 мс.Теперь, как обычный разработчик, мы бы подумали, что 10 мс не так уж и критичны.Но если мы думаем с точки зрения бизнеса, то это вызывает тревогу.Каким образом?давайте проанализируем:

Давайте предположим, что при пиковых нагрузках ресурсы используются полностью, и за 14 мс мы смогли выполнить 100 транзакций.Теперь при снижении производительности транзакции занимают на 10 мс больше, что составляет 71,42% дополнительного времени.Теперь это означало бы, что мы сможем обслуживать только 28.58 транзакций вместо 100 транзакций.Это означает серьезные потери для бизнеса.

Фактически, существует много литературы о важности производительности приложений.Есть очень хорошая книга "Количественный подход к компьютерной архитектуре", в которой объясняется, как факторы производительности, ремонтопригодности, надежности, доступности могут быть количественно определены в терминах бизнеса / пользователя.

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

Answer 8

они думали, что вызов другой функции, подпрограммы или Udf снизит производительность

Это неправильное мышление.

Я бы заказал:Ремонтопригодность, Производительность, Возможность повторного использования.

Иногда (обычно IMO) возможность повторного использования является ремонтопригодность:это потому, что вы повторно использовали что-то, что вы "можете внести изменения в одном легко определяемом месте и не гоняться за всеми этими местами, чтобы не копировать и не вставлять код".

Answer 9

Производительность не стоит на первом месте, даже в НАСА!В НАСА, если код неверен и надежен, люди умирают.

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

Для меня этот порядок был бы:

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

Answer 10

В изолированном ответе производительность практически всегда будет на первом месте.

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

Ремонтопригодность еще больше на это влияет то, как код взаимодействует с неизвестным нам кодом.Ответ решит проблему в заданном вами объеме:Вы можете запросить или пометить как SQL, или SQL Server, или MySQL.Остальное мы просто не знаем:Сколько у вас похожих путей к коду?Как часто этот фрагмент кода будет меняться в течение срока действия проекта?Будете ли вы придерживаться этой конкретной версии сервера базы данных в течение десяти лет или будете часто обновляться?

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

Удобочитаемость в основном сделано, остальное - ваша работа.Отвечая, мы обычно заинтересованы в том, чтобы вы поняли ответ, поэтому он должен быть читабельным, по крайней мере, для вас.Если вы скопируете этот фрагмент в свой код и добавите // That weird query прокомментируй это, это больше не моя проблема.

Добавьте к этому тот факт, что производительность легче понять:Из двух функционально эквивалентных ответов вы всегда выберете тот, в котором говорится "как в ответе Джо, но немного быстрее", если только он не допускает огромных ошибок в отделе M + R.

---

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

Однако низкий приоритет оптимизации имеет две основные причины:

Answer 11

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

• Пишите не больше кода, чем необходимо.
• Используйте стандартные библиотеки.
• Предпочитайте прозрачность сообразительности.
• Пишите небольшие, тестируемые функции.

Answer 12

Вот результаты, основанные на количестве тегов:

• Производительность - 952
• Возможность повторного использования (несколько связанных тегов) - 43
• Ремонтопригодность - 14

Что это значит:Производительность, должно быть, важна?Производительность сложнее, поэтому задается больше вопросов.Вопросы о производительности более конкретны / уместны, чтобы задавать их на этом сайте?

Answer 13

Я делай работаю в НАСА.Однако я (во всяком случае, в настоящее время) не поддерживаю и не разрабатываю код реального времени или что-либо еще, что так критично к производительности.Большая часть программного обеспечения, разработанного в НАСА, вероятно, таковой не является.Увидев в свое время ужасающий код, я также соглашусь с ответом Джонатана о надежности и ремонтопригодности, за которыми следует производительность, а затем возможность повторного использования для большинства приложений.

Answer 14

Одна из моих любимых цитат - из SICP ...

"Компьютерные программы предназначены для чтения людьми и, как правило, выполняются компьютерами".

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

Просто мой 2c, приятных выходных!