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

Одна из моих любимых кавычек от SICP...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Отредактированный 02.03.2010: вопрос первоначально запускается:

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

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

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

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

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

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

Мне порядок был бы:

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

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

Это неправильно думает.

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

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

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

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

   • Другое приложение время от времени занимало 16 часов для обработки данных 1 дня. Само собой разумеется, абсолютная производительность быстро стала высшим приоритетом. Но даже в рамках этого приложения подчеркивание производительности варьируется существенно, от 'не важный' в per-batch-code через per-client-code, per-task-code, per-file-code, per-record-code, per-field-code к 'чрезвычайно важному' в per-byte-code.

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

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

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

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

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

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

Ответ сосунка, конечно, "он зависит".

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

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

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

таким образом, мой порядок

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

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

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

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

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

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

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

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

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

Infact там является партией литературы по важности производительности приложения. Существует очень хорошая книга "Количественный Подход к Архитектуре ЭВМ", которая объясняет, как факторы производительности, maintability, надежности, доступность может быть определена количественно в условиях бизнеса/пользователя.

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

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

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