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

Question

Два партнера:

1) Скажем, вы разрабатываете приложение нового типа и разрабатываете новые алгоритмы для выражения концепций и контента - имеет ли смысл попытаться активно не рассматривайте методы оптимизации на этом этапе, даже если в глубине души вы боитесь, что это может закончиться как O (N!) для миллионов элементов?

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

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

Answer 1

"активно не учитывайте оптимизацию" звучит для меня очень странно. Обычно правило 80/20 работает довольно хорошо. Если вы тратите 80% своего времени на оптимизацию программы для менее чем 20% случаев использования, может быть, лучше не тратить время, если эти 20% случаев не имеют значения.

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

Answer 2

Подумайте об оперативных сценариях. (варианты использования)

Скажи, что мы делаем штуковину для поиска пиццерии.

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

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

Или вы торговая система: точные суммы. Меньше миллисекунды за сделку, если можете, пожалуйста. (Они, вероятно, примут 10 мс), поэтому, agian: вы смотрите на каждую идею с точки зрения соответствующих сценариев.

Скажем, это приложение для телефона: должно начинаться с (сколько секунд)

Демонстрации для клиентов с ноутбуков ВСЕГДА являются сценарием. Мы должны продать продукт.

Техническое обслуживание, когда какой-то человек обновляет предмет, ВСЕГДА является сценарием.

Так что теперь, в качестве примера: все сложные, тяжелые, искусственные ИИ подходы, настроенные на шутки, не подходят. Или для других штрихов файл конфигурации сервера XML не достаточно удобен для пользователя.

Посмотрите, как это помогает.

Answer 3

Я расскажу небольшую историю о том, что случилось со мной, но на самом деле это не ответ.

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

Теперь возникла проблема. Во время демонстраций для потенциальных клиентов для этого программного обеспечения и бета-тестирования на демонстрационном устройстве (автономном ноутбуке) происходит сбой из-за слишком большого объема используемой памяти. Он также не работает на сервере dev с действительно большими файлами.

Так было ли это оптимизацией или это была известная будущая ошибка. Должен ли я исправить это или oprtimize это сейчас? ну, это должно быть определено, поскольку они являются и другими приоритетами.

Мне просто жаль, что я потратил время на повторную оптимизацию кода ранее.

Answer 4

Если меня беспокоит способность кодов обрабатывать рост данных, прежде чем я зайду слишком далеко, я попытаюсь настроить наборы данных с большими приращениями порций, чтобы проверить их как

1000 записей
10000 записей
100000 записей
1000000 записей

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