При первом приближении к проекту лучше всего отступить и продумать все или просто погрузиться и начать кодирование и полировку позднее? По сути, вы сначала разрабатываете или пытаетесь быстро прототипировать?
Я был сожжен обоими методами, иногда я пытаюсь все продумать, но когда я действительно приступаю к nitty gritty, я сталкиваюсь с проблемами, которые я не принимаю во внимание, а иногда, когда я сначала код, я заканчиваю кодом который должен быть переделан, чтобы вписаться в лучший общий дизайн. Многие мои проблемы проистекают из неопытности, но любые советы приветствуются.
Идутся постепенно и итеративно.
Разработайте бит, выполните бит.
Начиная с дизайна, вы можете пострадать от эффекта туннеля, где у вас не может быть реальной обратной связи, прежде чем вы что-то реализуете.
Начиная без дизайна, вы можете принять решения, о которых вы пожалеете.
Идеальная ситуация - это возможность реализовать очень скелетную сквозную версию вашей системы, которая может быть протестирована и продемонстрирована клиенту.
В первую очередь всегда безопаснее разрабатывать, но это не означает, что прототипирование не работает. Реальная проблема с прототипированием сопротивляется стремлению сохранить код, который вы уже писали, вместо того, чтобы выбросить его, когда придет время сделать дизайн.
Нет серебряной пули. Похоже, что дизайн - это предпочтительный подход. Но вы не сможете предсказать все сложности, которые могут возникнуть при реализации вашего проекта. Некоторые из них потенциально могут быть демонстрационными стопорами. Кроме того, если вы пишете для клиента, хорошо иметь возможность показать что-то просто, чтобы убедиться, что вы находитесь на одной странице.
На моем рабочем месте мы делаем оба - мы делаем быстрый прототип, чтобы получить обратную связь и получить представление о любых потенциальных проблемах. Затем мы делаем формальный дизайн и формальную реализацию. В большинстве случаев мы можем сэкономить много кода с этапа прототипирования. Мне нравится этот подход, поскольку мы обычно получаем чистый, обслуживаемый код.
См. Gall Law. Ключ к итерации: немного поработайте, немного поработайте, немного испытайте, затем повторите, пока вы (или ваши клиенты) не удовлетворены. В этом суть новой породы "гибких" методологий.
Это зависит.
Прототипирование наиболее полезно, когда требования или решение не обязательно ясны. В качестве примера я делаю проект хранилища данных в среде (крупное коммерческое страхование), где финансовое примирение - это большое дело. Этот проект включал большое упражнение по созданию прототипов, чтобы получить систему, которая будет согласовываться с финансовыми. Поскольку бизнес-правила, связанные с этим, не были хорошо документированы, прототип сыграл важную роль в раскрытии всех угловых случаев.
В других случаях подход, основанный на разработке, может быть более уместным. Это наиболее применимо там, где требования и разумная архитектура решения достаточно очевидны.
Перед тем, как приступить к работе, вы должны иметь представление об объединенной архитектуре. Это особенно справедливо для крупномасштабных систем.
Прототипирование может использоваться для конкретных аспектов конструкции, например. уровня представления.
Я думаю, это зависит от того, какие бизнес-требования у вас есть. Если они (относительно) детализированы и полны, то я буду проектировать на основе этих требований. Если вначале вы ничего не можете сработать, попробуйте прототип и покажите своему клиенту, что у вас есть, для получения дополнительной информации о требованиях.
Вам следует разработать с использованием Agile Methodologies. Проще говоря, вы дизайн вы идете. Команда вместе с владельцем продукта определяет список тем для разработки, упорядочивает их по важности и разбивает развитие на итерации. Каждая итерация в качестве функций, которые должны быть разработаны и в начале итерации, проектирует каждую функцию.
Подробнее здесь.
При первом приближении к проекту, прототипу. Но не прототипируйте все. Прототип - одна важная вещь (один "пример использования", если это что-то значит) и "превратить внутренний глаз в свой путь" - следите за практическими проблемами, с которыми вы сталкиваетесь, пытаясь добиться этого.
Теперь, когда у вас есть представление о том, что нужно сделать, чтобы сделать что-то важное, вы можете проектировать не только из первых принципов.
Конечно, это предполагает, что вы работаете в среде, где вы можете превратить прототипы с минимальными затратами на текущие усилия в области развития. Но если вы работаете в такой среде, перепроверьте свои обсуждения дизайна с помощью прототипов. С какой-либо удачей вы можете сохранить некоторые из них.
обратите внимание, что гибкие методы не являются оправданием, чтобы избежать проектирования, они просто поощряют тестирование дизайна чаще и с меньшими приращениями
Мне нравится набросать дизайн и сломать его элементы до тех пор, пока не будет разумно уверен, что нет очевидных неизвестных или рисков; неизвестные и риски выделяются для проектов "спайк" с временным полем для определения осуществимости и заметок о возможных альтернативах, если предпочтительные методы оказываются неработоспособными
после удобной общей архитектуры перейдите в функции снизу вверх (или в порядке приоритета), чтобы завершить проект, написать начальные тесты, а затем реализовать
EDIT: обратите внимание, что вопрос "дизайн или прототип первый" делает плохое предположение, т.е. можно прототипировать без какой-либо конструкции, что, конечно же, не так (если вы не используете методологию с миллионами обезьян )
Сначала проектируйте, если вы не готовы рисковать выбросить всю работу, поставленную в ваш прототип, когда найдете, что он не может делать то, что вам нужно. Как минимум, вы должны сделать несколько проектов высокого уровня для своего проекта, которые могут помочь вам принять некоторые решения о том, как вы собираетесь создавать свой прототип, чтобы у вас было минимум усилий впустую.
Если я знаю, что хочу построить, я просто подойду к дизайну.
Если я создаю что-то для клиента, то я прототип, чтобы облегчить более конкретные требования от пользователей.
Возможно, это не ответ, а предложение из моего опыта.
В большинстве случаев мне было бы лучше, если бы я начал кодирование раньше. Вы можете проектировать до тех пор, пока корова не вернется домой, но если коровы находятся на горизонте, когда вы начинаете кодирование, вы можете найти, что ваш тщательный дизайн трудно реализовать вовремя.