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

Question

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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

Answer 4

они думали, вызывая другую функцию или подпрограмму или UDF будет препятствовать работе

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

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

Иногда (обычно ИМО) повторное использование является ремонтопригодность: это потому, что вы повторно то, что вы «в состоянии внести изменения в один легко определить место, а не гоняться за все те места, soneone скопированные и вставленные код».

Answer 5

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

Answer 6

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

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

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

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

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

Answer 7

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

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

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

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

Answer 8

Performance doesnt't пришел первым, даже в НАСА! В НАСА, если код неправильный и надежный, люди умирают.

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

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

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

Answer 9

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

«Компьютерные программы предназначены для чтения людьми и между прочим побежал компьютерами.»

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

Просто мой 2c, у вас прекрасные выходные!

Answer 10

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

поэтому мой заказ

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

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

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

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

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

---

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

Answer 11

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

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

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

Устранение Поддержание работоспособности - это в значительной степени ваша задача: возникает ли вопрос, который вы задаете сущности, которая должна быть изолирована?

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

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

---

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

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

Answer 12

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

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

Answer 13

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

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

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

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

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

Answer 14

Вот результаты основаны на Tag Count:

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

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