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

Question

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

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

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

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

Answer 1

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

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

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

Answer 2

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

так что мой заказ

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

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

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

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

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

---

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

Answer 3

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

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

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

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

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

Answer 4

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

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

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

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

Answer 5

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

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

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

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

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

Answer 6

Ответ присоски, конечно, "это зависит".

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

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

Answer 7

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

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

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

Нет: надежность и ремонтопригодность опережают производительность. Повторное использование тоже хорошо.

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

Answer 8

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

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

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

Answer 9

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

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

Answer 10

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

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

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

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

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

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

---

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

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