Приоритеты кодирования: производительность, ремонтопригодность, возможность повторного использования? - PullRequest
8 голосов
/ 07 февраля 2009

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

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

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

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

Ответы [ 14 ]

1 голос
/ 07 февраля 2009

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

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

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

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

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

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

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

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

0 голосов
/ 07 февраля 2009

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

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

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

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

0 голосов
/ 07 февраля 2009

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

...