Дизайн и кодирование - сверху вниз или снизу вверх?[закрыто]
https://stackoverflow.com/questions/130933
-
02-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Какой подход, по вашему опыту, является лучшим при написании кода?
- Разбейте задачу на достаточно мелкие части, а затем реализуйте каждую из них.
- Разбейте проблему на части, но затем реализуйте, используя подход "сверху вниз".
- Какой-нибудь другой?
Решение
Вот что я делаю:
Сначала разберитесь с доменом.Поймите проблему, которую необходимо решить.Убедитесь, что вы и клиент (даже если этот клиент - вы!) согласны с тем, какую проблему необходимо решить.
Затем предлагается высокоуровневое решение проблемы, и на основе этого дизайн превратится в пузырьки или маркеры на странице или что-то еще, но суть в том, что он разделится на компоненты, которые можно спроектировать.
На этом этапе я пишу тесты для еще не написанных классов, а затем конкретизирую классы для прохождения этих тестов.
Я использую подход, основанный на тестировании, и создаю работающие, протестированные компоненты.Это то, что работает у меня.Когда известны интерфейсы компонентов и известны "правила" того, как они взаимодействуют друг с другом и предоставляют друг другу услуги, тогда, как правило, это становится простым упражнением по "соединению всего воедино".
Вот как я это делаю, и у меня это хорошо сработало.
Другие советы
Я склонен проектировать сверху вниз и внедрять снизу вверх.
Что касается реализации, то мне кажется, что лучше всего подходит создание мельчайших функциональных элементов и сборка их в структуры более высокого уровня.Но для дизайна мне нужно начать с общей картины и разбить ее на части, чтобы определить, какими будут эти фрагменты.
Возможно, вы захотите ознакомиться с Гибкий Манифест.Сверху вниз и снизу вверх основаны на дизайне и конструкции Built It All At Once.
"Работающее программное обеспечение поверх исчерпывающей документации" означает, что первое, что вы создаете, - это самая маленькая полезная вещь, которую вы можете запустить.Сверху?Снизу?Ни то, ни другое.
Когда я был моложе, я работал над проектами, которые - по контракту - осуществлялись строго сверху вниз.Это не сработает.Действительно, это не может сработать.В результате вы получаете горы избыточного дизайна и кода.Это не был разумный подход, если применять его бездумно.
Что я заметил, так это то, что гибкий подход - небольшие фрагменты, которые работают, - как правило, разбивает проблему на части, которые можно охватить все сразу.Принцип "сверху вниз" / "снизу вверх" больше не имеет такого большого значения.На самом деле, это может вообще не иметь значения.
Какие зацепки делают:"Как вы выполняете декомпозицию для гибкой разработки?" Хитрость в том, чтобы избежать создания Большое Дело который вы должны затем разложить.Если вы анализируете проблему, вы обнаруживаете, что субъекты пытаются выполнить варианты использования и терпят неудачу, потому что у них нет всей информации, или они не получают ее вовремя, или они не могут выполнить свои решения, или что-то в этом роде.
Часто это не такие Уж Большие Вещи, которые нуждаются в разложении.Когда они появятся, вам нужно проработать проблему в Цели В обратном направлении направление.От целей к вещам, которые позволяют вам достичь этой цели, к вещам, которые позволяют задействовать вспомогательные средства, и т.д.Поскольку цели часто бывают Масштабными, это, как правило, происходит сверху вниз - от общей бизнес-цели до детализированного бизнес-процесса и шага.
В какой-то момент мы рассмотрим эти различные шаги, ведущие к поставленным целям.Мы выполнили часть анализа (разложили все по полочкам).Теперь начинается часть синтеза:мы собираем то, что у нас есть, в то, что мы действительно можем построить.Синтез идет Снизу Вверх.Однако давайте не будем увлекаться.У нас есть несколько точек зрения, каждая из которых отличается от других.
У нас есть модель.Это часто строится из деталей в более крупную концептуальную модель.Затем иногда снова разлагается на модель, нормализованную для OLTP.Или разложен на звездообразную схему, нормализованную для OLAP.Затем мы возвращаемся к созданию отображения ORM на основе нормализованной модели.Вверх - Вниз - Вверх.
У нас есть процессинг.Это часто строится на основе краткого описания бизнес-процессов вплоть до деталей этапов обработки.Затем программное обеспечение разрабатывается с учетом этих шагов.Затем программное обеспечение разбивается на классы и методы.Вниз - Вверх - Вниз.
[Отступление.Для просвещенных пользователей эта декомпозиция определяет новые названия должностей и способы работы.У непросвещенных пользователей старые рабочие места остаются, и мы пишем горы документации, чтобы сопоставить старые рабочие места с новым программным обеспечением.]
У нас есть компоненты.Мы часто смотрим на детали, анализируем то, что нам известно о доступных компонентах, и проводим своего рода сопоставление.Это самый случайный процесс;это сродни способу образования кристаллов - есть центры зарождения, и дизайн как бы затвердевает вокруг этих центров.Веб-сервисы.База данных.Управление транзакциями.Производительность.Объем.Различные функции, которые каким-то образом помогают нам выбирать компоненты, реализующие часть или все наше решение.Часто ощущается снизу вверх (от функции к продукту), но иногда и сверху вниз ("Я держу в руках молоток, называю все гвоздями" == используйте СУБД для всего.)
В конце концов, нам приходится писать код.Это снизу вверх.Вроде того.Вы должны определить структуру пакета.Вы должны определить классы как единое целое.Эта часть была сверху вниз.Вы должны писать методы внутри классов.Я часто делаю это снизу вверх - разрабатываю метод, пишу модульный тест, завершаю метод.Набросайте следующий метод, напишите модульный тест, завершите работу над методом.
Движущий принцип - Гибкость: создайте что-то, что работает.Детали разбросаны по всей карте - сверху, снизу, спереди, сзади, данные, процесс, субъект, предметная область, ценность для бизнеса.
ДА.Делайте все эти вещи.
Это может показаться саркастичным (извините, я возвращаюсь к форме), но это действительно тот случай, когда правильного ответа нет.
Также в гибком режиме сначала напишите свой тест (ы)!
Тогда все программное обеспечение представляет собой непрерывный цикл
- Красный - код не прошел тест
- Зеленый - код проходит проверку
- Рефакторинг - улучшения кода, сохраняющие намерение.
дефекты, новые функции, изменения.Все это происходит по одной и той же схеме.
Ваш 2-й вариант - разумный путь.Если вы разобьете проблему на понятные фрагменты, подход "сверху вниз" выявит все основные недостатки дизайна до того, как вы реализуете все мелкие детали.Вы можете написать заглушки для функциональности более низкого уровня, чтобы все было взаимосвязано.
Я думаю, что есть нечто большее, что следует учитывать, чем дизайн "сверху-вниз".Очевидно, что вам нужно разбить дизайн на управляемые единицы работы, но вам также необходимо учитывать расстановку приоритетов и т.д.И в итеративном проекте разработки вы часто будете переопределять проблему для следующей итерации после того, как предоставите решение для предыдущей.
При проектировании я предпочитаю придерживаться середины.Мне нравится моделировать домен, затем разрабатывать классы, оттуда переходить к базе данных и пользовательскому интерфейсу.Если есть конкретные функции, основанные на пользовательском интерфейсе или базе данных, я также могу разработать их заранее.
При написании кода мне обычно нравится работать снизу вверх (сначала база данных, затем бизнес-объекты, затем пользовательский интерфейс), если это вообще возможно.Я нахожу, что с помощью этого метода намного проще все прояснить.
Я считаю, что с хорошими разработчиками программного обеспечения (а по моему мнению, все разработчики программного обеспечения также должны быть разработчиками программного обеспечения на каком-то уровне) волшебство заключается в способности работать одновременно сверху вниз и снизу вверх.
Чему меня "научили" мои наставники, так это начинать с очень краткого обзора сверху вниз, чтобы понять задействованные сущности, затем переходить к обзору снизу вверх, чтобы выяснить базовые элементы, которые я хочу создать, затем вернуться назад и посмотреть, как я могу спуститься на один уровень ниже, зная то, что я знаю о результатах моего поиска снизу вверх, и так далее, пока "они не встретятся посередине".
Надеюсь, это поможет.
Снаружи-в дизайне.
Вы начинаете с того, чего пытаетесь достичь на верхнем уровне, и вы знаете, с чем вам придется работать на нижнем уровне.Продолжайте работать с обоими концами, пока они не сойдутся посередине.
Я вроде как согласен со всеми людьми, которые говорят "ни то, ни другое", но каждый попадает куда-то в спектр.
Я больше предпочитаю работать сверху вниз.Я выбираю одну высокоуровневую функцию / точку / что угодно и реализую ее как законченную программу.Это позволяет мне набросать базовый план и структуру в рамках проблемной области.
Затем я начинаю с другой функции и реорганизую все исходное, что может быть использовано вторым, в новые общие объекты.Вспеньте, смойте, повторяйте до полного завершения нанесения.
Однако я знаю много людей, которые работают снизу вверх, которые слышат о проблеме и начинают думать обо всех подсистемах поддержки, которые им могут понадобиться для создания приложения поверх нее.
Я не считаю ни тот, ни другой подход неправильным или правильным.Они оба могут добиться результатов.Я даже пытаюсь найти ребят снизу, с которыми можно работать, поскольку мы можем подойти к проблеме с двух разных точек зрения.
Оба подхода являются допустимыми.Иногда один просто "чувствует" себя более естественно, чем другой.Однако есть одна большая проблема:некоторые основные языки и особенно их фреймворки и библиотеки действительно сильно о поддержке IDE, такой как подсветка синтаксиса, фоновая проверка типов, фоновая компиляция, интеллектуальное завершение кода, IntelliSense и так далее.
Однако, это не работает с нисходящим кодированием! В нисходящем кодировании вы постоянно используете переменные, поля, константы, функции, процедуры, методы, классы, модули, признаки, микшины, аспекты, пакеты и типы это вы еще не реализовали! Таким образом, IDE будет постоянно кричать на вас из-за ошибок компиляции, повсюду будут красные волнистые линии, вы не получите завершения кода и так далее.Итак, IDE в значительной степени запрещает вы не занимаетесь кодированием сверху вниз.
Я делаю вариант "сверху вниз".Обычно я сначала пытаюсь создать интерфейс, а затем использую его в качестве своего списка функций.Что хорошо в этой версии, так это то, что она по-прежнему работает с IDE, которая в противном случае жаловалась бы.Просто закомментируйте один вызов функции для того, что еще не было реализовано.
