Приоритеты кодирования: производительность, ремонтопригодность, возможность повторного использования?
Это произошло в основном благодаря ответам на вопросы SQL. UDF и подзапросы намеренно опущены из-за производительности. Я не включил надежность не в то, что это следует воспринимать как должное, но код должен работать.
Производительность всегда на первом месте? Так много ответов предоставляется с производительностью в качестве основного приоритета. Мои пользователи, кажется, больше озабочены тем, как быстро можно изменить код. Таким образом, отчет занимает 15 секунд вместо 12 для запуска. Они могут жить с этим, пока я не извиняюсь за то, что не предоставил решения.
Очевидно, что если 15 секунд превращаются в 15 минут, проблема возникает, но пользователям нужна функциональность. Они хотят, чтобы приложение адаптировалось к изменениям бизнес-правил и запросам на усовершенствование. Я хочу иметь возможность просматривать код через 6 месяцев и иметь возможность вносить изменения в одно легко идентифицированное место, а не отыскивать все эти места, когда один скопировал и вставил код, потому что они думали, что вызов другой функции или подпрограммы или Udf будет мешать производительности.
Все, что говорится, я бы приказал: ремонтопригодность (изменение является фактом жизни.), Производительность (никто не любит смотреть на песочные часы.), Возможность повторного использования (трудно определить, какой код следует использовать снова.).
14 ответов
1. Поддерживаемость: если код не читаемый, он бесполезен, независимо от того, насколько быстро он работает. И это определенно не будет использоваться повторно.
2. Возможность многократного использования: не весь код можно использовать многократно, но его много. Если вы можете, во что бы то ни стало сделать ваш код проще. Самое простое - разделяй и властвуй. Например, создавайте простые компоненты, которые вы будете использовать снова и снова. Виджеты пользовательского интерфейса являются наиболее распространенными. Но то же самое с коммунальными услугами. Также помогает создание структуры / фреймворка для вашего кода. Код подтверждения ошибки и т. Д.
3. Производительность. Как правило, большая часть кода достаточно производительна. А если нет, используйте профилировщик кода. Чаще, чем узкое место, значительно перевешивает любые небольшие оптимизации кода, которые вы могли бы сделать за счет либо читабельности, либо повторного использования.
Я думаю, что вы пропустили один из списка: надежность;
так что мой заказ
- Надежность и точность
- Ремонтопригодность
- Повторное использование
- Спектакль
Неважно, насколько быстрым является код, когда он неправильный, во-первых, код должен быть надежным.
Производительность находится внизу списка. Никогда не оптимизируйте слишком рано, а улучшайте производительность только тогда, когда производительность является проблемой.
Я работал над системами реального времени, включая моделирование полета, и даже в таких условиях производительность принимается во внимание, но это не является главной задачей 1.
Я бы сказал, что по моему опыту мне всего лишь пришлось оптимизировать менее 1% написанного мной кода.
1 Иногда что-то не достаточно быстро, и, конечно, производительность учитывается при проектировании и кодировании, но это просто не в начале списка.
Ответ присоски, конечно, "это зависит".
В случае бизнес-приложений время отклика для соответствующего действия должно быть обратно пропорционально частоте, с которой оно выполняется. Если это функция, к которой пользователям нужно обращаться 4 или 5 раз в час, лучше бы она была более быстрой, чем получение этого отчета на конец месяца.
Я думаю, что в некоторой степени вы ответили на свой вопрос и предоставили довольно веские причины для этого. Единственный, что вы пропустили, это Надежность - и вот тут-то и начинается аналогия с НАСА. Если вы пишете код для НАСА или для финансового учреждения, это чертовски хорошо, лучше быть надежным и надежным... и Я думаю, что это будет первым приоритетом.
Это интересный вопрос, и ответы на него достаточно интересны. Приоритет зависит от реализации. Я хотел бы представить один из примеров, где пользователи не жертвуют производительностью ради удобства обслуживания или повторного использования. Да, есть фактор надежности - должна быть какая-либо ошибка / ошибка. Поэтому, когда мы сравниваем ремонтопригодность, производительность и возможность повторного использования.
У одного из наших клиентов был сайт интернет-трейдинга. При пиковых нагрузках средняя транзакция может занять около 14 мс на уровне промежуточного программного обеспечения. Спустя некоторое время производительность приложения ухудшилась (по ряду причин), а среднее время транзакций увеличилось до 24 мс. Теперь, как обычный разработчик, мы бы подумали, что 10 мс не так уж страшно критичны. Но если мы думаем с точки зрения бизнеса, то это вызывает тревогу. Как? давайте проанализируем:
Предположим, что при пиковых нагрузках ресурсы полностью используются, и за 14 мс мы смогли выполнить 100 транзакций. Теперь, с ухудшением производительности, транзакции занимают 10 мс дополнительно, что составляет 71,42% дополнительного времени. Теперь это будет означать, что мы сможем обслуживать только 28,58 транзакций вместо 100 транзакций. Это означает серьезную потерю для бизнеса.
Infact есть много литературы о важности производительности приложений. Есть очень хорошая книга "Количественный подход к компьютерной архитектуре", в которой объясняется, как факторы производительности, работоспособности, надежности, доступности можно количественно определить с точки зрения бизнеса / пользователя.
Я не буду указывать порядок важности, так как он зависит от контекста.
Вы должны иметь возможность перераспределить эти приоритеты в зависимости от проекта, и сложная вещь - это быстрое изменение поведения при переключении между проектами или даже различными разделами кода. Я работаю над тремя приложениями с очень разными профилями.
Один из них - в режиме реального времени, и большая часть работы направлена на то, чтобы его производительность была предсказуемой (не обязательно быстро светящейся), но изменения не являются серьезной проблемой, они значительно меняются только тогда, когда IETF изменяет / устаревает RFC, и нет никаких признаков того, что. (Тем не менее, я очень горжусь его уровнем ремонтопригодности).
Другое приложение иногда занимало 16 часов для обработки данных за 1 день. Излишне говорить, что абсолютная производительность быстро стала главным приоритетом. Но даже в этом приложении акцент на производительность сильно варьируется: от "неважного" в коде пакета до кода клиента, кода задачи, кода файла, кода записи, -полевой код для "чрезвычайно важного" в байт-коде.
Конечное приложение содержит большую часть бизнес-логики, производительность никогда не является проблемой, ремонтопригодность и гибкость являются ключевыми, и это приложение больше всего выигрывает от всех модных методологий, однако, когда я потратил недели или месяцы на рефакторинг производительности, это очень сложно написать "string1 + string2 + string3 + string4", даже если это наиболее читаемо, а производительность не имеет значения.
Отредактировано 2010-03-02: Первоначально вопрос возник:
Все работают на НАСА? Производительность всегда на первом месте? Так много ответов...
Нет, большинство из нас не работают в НАСА.
Нет: надежность и ремонтопригодность опережают производительность. Повторное использование тоже хорошо.
В широких пределах производительность не важна.
Я являюсь подрядчиком НАСА и занимаюсь разработкой и обслуживанием программного обеспечения, главным образом для целей администрирования, таких как создание отчетов и отслеживание проектов.
Я проработал там около 1,5 лет, и я считаю, что их главной заботой является удобство обслуживания и скорость, с которой вы сможете внедрить эту новую функцию или модуль.
Как и Гиннес, изложенный в вопросе, пока программное обеспечение не занимает исключительное количество времени, они, похоже, не возражают.
Другая главная забота, которую они, кажется, имеют, это удобство использования. Приложение должно быть простым и понятным в использовании.
В заключение, поддержка, удобство использования, а затем и производительность, по-видимому, являются основными задачами НАСА для инструментов внутренней отчетности и отслеживания.
Производительность не на первом месте, даже в НАСА! В НАСА, если код не верен и надежен, люди умирают.
Более того, по моему опыту, даже когда производительность важна, она до определенной степени; обычно существует такой уровень производительности, что при его превышении практически нет никакой дополнительной ценности. В отличие от этого, есть дополнительная ценность в улучшении правильности, независимо от того, насколько надежен фрагмент кода; кусок кода не может работать так, как ожидалось, слишком часто.
Для меня порядок будет:
- Ремонтопригодность: если это не легко изменить, он не будет оставаться корректным в течение длительного времени, даже если сейчас это правильно.
- Повторное использование: повторное использование повышает производительность, и меньшее количество кода, как правило, более надежно, чем большее количество кода.
- Производительность: иногда производительность имеет значение, но вы будете удивлены, насколько много кода не критично для производительности, даже в приложениях, критичных для производительности. Оптимизация производительности имеет значение только для узких мест.
Правильность важнее, чем ремонтопригодность, возможность повторного использования или производительность. Если вы стремитесь к правильности, вы, вероятно, получите другие три в сделке.
- Пишите не больше кода, чем необходимо.
- Используйте стандартные библиотеки.
- Предпочитаю прозрачность разуму.
- Напишите небольшие тестируемые функции.
Вот результаты, основанные на подсчете тегов:
- Производительность - 952
- Возможность повторного использования (несколько связанных тегов) - 43
- Ремонтопригодность - 14
Что это значит: производительность должна быть важной? Производительность сложнее, поэтому задают больше вопросов. Вопросы производительности более конкретны / уместны задавать на этом сайте?
они думали, что вызов другой функции или подпрограммы или Udf будет препятствовать производительности
Это неправильно думать.
Я бы заказал: ремонтопригодность, производительность, возможность повторного использования.
Иногда (обычно IMO) возможность повторного использования - это удобство сопровождения: потому что вы повторно использовали что-то, что вы "способны сделать изменение в одном легко идентифицируемом месте и не преследовать все эти места, когда один скопировал и вставил код".
В единичном ответе, производительность практически всегда будет на первом месте.
Мы не знаем, попадете ли вы в этот фрагмент кода миллион раз подряд, поэтому производительность по-прежнему является проблемой. Мы не знаем, станет ли наш драгоценный фрагмент кода узким местом вашего приложения, поскольку мы не знаем, как оно взаимодействует. (То же самое происходит при написании библиотечного кода: я не знаю, как это используется. Одной из причин повторного использования кода IMO является не просто "перемещение похожего кода в общую сущность".)
На работоспособность еще больше влияет то, как код взаимодействует с неизвестным нам кодом. Ответ решит проблему в заданной вами области: вы можете запросить или пометить как SQL, или SQL Server, или MySQL. Остальное мы просто не знаем: сколько у вас похожих путей кода? Как часто этот кусок кода будет меняться в течение жизни проекта? Будете ли вы придерживаться этой конкретной версии сервера базы данных в течение десяти лет или будете часто обновляться?
Решение вопросов обеспечения - это в основном ваша работа: является ли вопрос, который вы задаете, сущностью, которая должна быть изолирована?
Читаемость в основном сделана, остальное ваша работа. При ответе мы обычно заинтересованы в том, чтобы вы понимали ответ, поэтому он должен быть удобочитаемым, по крайней мере, для вас. Если вы скопируете этот фрагмент в свой код и добавите // That weird query прокомментируйте это, не моя проблема больше.
Добавьте к этому тот факт, что производительность легче понять: из двух функционально эквивалентных ответов вы всегда выберете тот, который говорит "как Джо, но чуть быстрее", если только он не делает огромных ошибок в отделе M+R.
Теперь, когда вы пишете это, похоже, что причина преждевременной оптимизации заманчива. Это неправильный приоритет по нескольким причинам.
Низкий приоритет для оптимизации имеет две основные причины:
Одна из моих любимых цитат из SICP...
"Компьютерные программы предназначены для чтения людьми и запускаются компьютерами".
Я оцениваю все эти аспекты моей работы; но удобочитаемость (некоторые используют термин "выразительность") моего кода и тех, с которыми я работаю, возглавляют мой список важности.
Просто мой 2с, хороших выходных!
Я работаю в НАСА. Тем не менее, я (в настоящее время, во всяком случае) не поддерживаю и не разрабатываю код в реальном времени или что-либо, что критично для производительности. Большая часть программного обеспечения, созданного в НАСА, вероятно, нет. Увидев какой-то ужасающий код в свое время, я также согласен с ответом Джонатана о надежности и удобстве обслуживания, за которым следует производительность и возможность повторного использования для большинства приложений.