Я понимаю преждевременную оптимизацию правильно?
Я боролся с приложением, которое я пишу, и я думаю, что начинаю видеть, что моей проблемой является преждевременная оптимизация. Перфекционистская сторона меня хочет сделать все оптимальным и усовершенствовать в первый раз через, но я нахожу, что это усложняет дизайн вполне немного. Вместо того, чтобы писать небольшие, тестируемые функции, которые делают одну простую вещь хорошо, я склоняюсь к зубрежке в как можно большей функциональности, чтобы быть более эффективным.
Например, я избегаю нескольких прохождений в базу данных для той же информации за счет моего кода, становящегося более сложным. Одна часть меня хочет просто не, волнуются об избыточных вызовах базы данных. Это помогло бы написать правильный код, и выбираемый объем данных является небольшим так или иначе. Другая часть меня чувствует очень грязное и грязное выполнение этого.:-)
Я склоняюсь только к движению к базе данных многократно, которая я думаю, право, переезжают сюда. Более важно, чтобы я закончил проект, и я чувствую, что добираюсь, завис из-за оптимизации как это. Мой вопрос: действительно ли это - правильная стратегия использовать при предотвращении преждевременной оптимизации?
2 ответа
В целом это правильная стратегия. Заставьте код работать, тщательно пройдя автоматизированные тесты.
Затем вы можете запустить автоматические тесты, пока программа находится под управлением профилировщика, чтобы узнать, на что программа тратит время и / или память. Это покажет вам, где оптимизировать.
И он покажет вам, как оптимизировать рабочий код, а не код, который может работать или не работать, когда все вместе собрано.
Вам не нужен код, который дает сбой оптимальным образом.
Цитата, которую я не мог вспомнить, взята из Мича Раверы:
Если это не сработает, неважно, насколько быстро это не сработает.
Мы должны забыть о небольшой эффективности, скажем, примерно в 97% случаев: преждевременная оптимизация - это корень всех зол. - Hoare
Хотя @John Saunders решает эту проблему, применение только TDD может не полностью решить ваши проблемы. Я придерживаюсь TDD, и когда вы выполняете TDD правильно, и если вы можете эффективно применять рефакторинг, вы обычно получаете гораздо более компактный код и то преимущество, которое, как вы знаете, работает. Никаких аргументов нет.
Однако я вижу, что слишком много разработчиков пишут код, игнорирующий производительность - избегание преждевременной оптимизации не может служить оправданием написанию небрежного / ленивого / наивного кода. Написание модульных тестов не предотвращает этого. Хотя тот, кто пишет модульные тесты, вероятно, лучший программист, а лучшие программисты менее склонны писать плохой код так часто.
Сделайте напишите тесты, и сделайте включите тестирование производительности в свой набор тестов для сценариев, определенных вашими заинтересованными сторонами. например получить 100 продуктов со скидкой для конкретного поставщика и включить уровни запасов и формат в виде XML менее чем за 3 секунды
Заблуждение, что «преждевременная оптимизация» - это то же самое, что «забота о производительности», не должно служить ориентиром при разработке программного обеспечения. - Рэндалл Хайд
Если вы оставите проблемы с производительностью слишком поздно, вы можете обнаружить, что их слишком сложно или слишком дорого менять.
Некоторые статьи