Дизайн и Кодирующий - от начала до конца или нижняя часть к вершине? [закрытый]

Я склонен разрабатывать сверху вниз и реализовывать вверх дном.

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

Вы могли бы хотеть просмотреть Гибкий Манифест. Вершина вниз и вверх дном утверждена на Созданном Все это Сразу проектирование и строительство.

"Рабочее программное обеспечение по подробной документации" означает первую вещь, которую Вы создаете, самая маленькая полезная вещь, можно получить выполнение.Наверх? Нижняя часть? Ни один.

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

То, что я заметил, - то, что Гибкий подход - маленькие части, которые работают - имеют тенденцию ломать проблему к частям, которые могут быть схвачены внезапно. top-down/bottom-up больше не имеет значения так же. Действительно, это не может иметь значения вообще.

Который ведет, сделайте: "Как Вы разлагаетесь для Гибкой разработки?" Прием должен постараться не создавать Большую Вещь, которую необходимо затем анализировать. При анализе проблемы Вы находите агентов, пытающихся выполнять варианты использования и переставший работать, потому что у них нет всей информации, или у них нет ее вовремя, или они не могут выполнить свои решения или что-то как этот.

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

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

У нас есть модель. Это часто создается из деталей в большую концептуальную модель. Затем иногда разлагаемый снова на модель нормализован для OLTP. Или разложенный на схему "звезда" нормализован для OLAP. Затем мы обрабатываем назад для создания ORM, отображающегося из нормализованной модели. - Вниз-.

У нас есть обработка. Это часто создается из сводок бизнес-процессов вниз в детали обработки шагов. Затем программное обеспечение разработано на основе шагов. Затем программное обеспечение повреждается в классы и методы. Вниз - Вниз.

[Отклонение. С просвещенными пользователями это разложение определяет новые должности и способы работать. С неосведомленными пользователями остаются старые задания, и мы пишем горы документации для отображения старых заданий на новое программное обеспечение.]

У нас есть компоненты. Мы часто смотрим на части, посмотрите на то, что мы знаем о доступных компонентах и делаем своего рода соответствие. Это - процесс randomest; это сродни способу, которым формируются кристаллы - существуют центры образования ядра, и дизайн отчасти укрепляется вокруг тех центров. Веб-сервисы. База данных. Управление транзакциями. Производительность. Объем. Различные функции, которые так или иначе помогают нам выбрать компоненты, которые реализуют некоторых или все наше решение. Часто чувства вверх дном (от функции до продукта), но иногда сверху вниз ("я держу молоток, назовите все гвоздем" ==, используют RDBMS для всего.)

В конечном счете мы должны кодировать. Это является восходящим. Отчасти. Необходимо определить структуру пакета. Необходимо определить классы в целом. Та часть была вершиной вниз. Вы имеете к методам записи в классах. Я часто делаю это вверх дном - набрасывает вчерне метод, пишет модульный тест, заканчивает метод. Набросайте вчерне следующий метод, запишите модульный тест, закончите метод.

Ведущий принцип является Гибким - создают что-то, что работает. Детали разнообразны - вниз, передняя сторона, назад, данные, процесс, агент, предметная область, бизнес-возможность.

Да. Сделайте все те вещи.

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

Также гибким способом, запишите свой тест (тесты) сначала!

Затем все программное обеспечение является непрерывным циклом

• Красный - код проваливает тест
• Зеленый - код проходит тест
• Осуществите рефакторинг - улучшения кода, которые являются сохранением намерения.

дефекты, новые возможности, изменения. Все это следует за тем же шаблоном.

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

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

При разработке мне нравится делать середину. Мне нравится моделировать домен, затем разрабатывать классы, перемещаться в базу данных и UI оттуда. Если существуют определенные функции, которые основаны на UI или основаны на базе данных, я могу разработать их впереди также.

При кодировании мне обычно нравится делать вверх дном (база данных сначала, затем предприятия, затем UI) если вообще возможный. Я нахожу, что намного легче сохранить вещи прямо с этим методом.

Снаружи - в дизайне.

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

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

Однако это не работает с нисходящим кодированием! В нисходящем кодировании Вы постоянно используете переменные, поля, константы, функции, процедуры, методы, классы, модули, черты, mixins, аспекты, пакеты и типы, которые Вы еще не реализовали! Так, IDE будет постоянно вопить на Вас из-за ошибок компиляции, будут красные волнистые строки везде, Вы не получите завершения кода и так далее. Так, IDE в значительной степени мешает Вам делать сверху вниз кодирование.

Я сортирую, соглашаются со всеми людьми, говорящими "ни одного", но все падают где-нибудь на спектр.

Я - больше нисходящего вида парня. Я выбираю один высокий уровень feature/point/whatever и реализую его как полную программу. Это позволяет мне изобразить схематически основной план и структуру в рамках ограничений проблемной области.

Затем я запускаю с другой функции и осуществляю рефакторинг все из оригинала, который может использоваться вторым в новые, общие объекты. Пена, промывка, повторяется, пока приложение не является законченным.

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

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

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

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

Мои наставники «научили» меня тому, что сначала очень кратко сверху вниз, чтобы понять задействованные сущности, а затем двигаться снизу вверх. чтобы выяснить основные элементы, которые я хочу создать, затем вернуться назад и посмотреть, как я могу спуститься на один уровень вниз, зная, что я знаю о результатах моего снизу вверх, и так далее, пока «они не встретятся посередине».

Надеюсь, что это поможет.