Средства проектирования структуры программы? (Вершина вниз разрабатывает),

Мне неприятно это говорить, но вам, вероятно, нужно сделать прямо противоположное - вместо того, чтобы проектировать всю систему заранее, используйте TDD / BDD, и ваши тесты будут определять дизайн.

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

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

Ну, даю вам свои 2 цента по этому поводу. Я согласен с Габриэлем, когда он говорит, что UML - это тот инструмент, который вам нужен. UML, как следует из его названия, - это язык для моделирования вашего приложения. Я также согласен с Дрором, когда он говорит, что многие инструменты проектирования дают сбой, когда вы начинаете рефакторинг своего кода. Больно пытаться заставить диаграмму следовать вашему коду. У вас есть две основные возможности:

• Использование инструментов UML и UML для разработки архитектуры приложений высокого уровня или основных модулей. Это помогает иметь в виду общую картину и выделять основные проблемы, которые могут у вас возникнуть. Когда вы начинаете кодировать и проводить рефакторинг, не пытайтесь обновлять диаграмму. Забудь их. Вы можете вернуться к ним на следующей большой итерации вашего дизайна.
• Используйте инструмент, способный синхронизировать код и дизайн. По моему опыту, единственным инструментом, способным это сделать, был Borland Together . (Я не использовал его в течение долгого времени ...)

В любом случае, по моему скромному мнению, два ключевых момента:

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

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

  my2c

Ответ из двух частей

Методология Разделяй и властвуй довольно проста:

• Подумайте об алгоритме в самом абстрактном смысле. Что нужно сделать?

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

• Чтобы все было аккуратно. Пусть у одной функции/метода будет только одна цель. Длинная и сложная функция - верный признак того, что вам нужно разбить ее на части.

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

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

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

Если у вас есть час, я очень рекомендую Google Design Tech Talk: OO Design for Testability.

Это действительно хороший вопрос. BDD, TDD и Agile в целом не говорят, что вы не можете делать предварительный дизайн, они просто говорят, что не проектируйте больше, чем вам нужно - откладывайте любое решение как можно позже. Я уверен, что есть набор инструментов, который вы знаете, который как раз и используется для этого, он называется UML :). Вы были абсолютно правы, когда намекнули на аспект усилия. Пока диаграммы UML являются просто изображениями, они становятся ненужными отходами и бременем обслуживания во время разработки, когда все может быстро и быстро меняться. Однако вы можете использовать какой-нибудь инструмент CASE, который позволит вам (после месяцев ругани: D ...) создавать диаграммы, которые можно использовать для генерации кода, и когда вам нужно что-то изменить на уровне модели, просто измените диаграмму и регенерацию (на самом деле это требует некоторой архитектуры и работы заранее, посмотрите на некоторые подходы, основанные на моделях). То, что я считаю лучшим в этом отношении, было бы чем-то посередине.Что-то, что позволит вам легко моделировать (рисовать и поддерживать диаграммы, блок-схемы, конечные автоматы ...) и создавать код. Что я считаю лучшим подходом, так это (внешние) доменные языки. Например. вы можете использовать такие инструменты, как Xtext, чтобы создать язык для конечных автоматов и сгенерировать для них код, например. в соответствии с шаблоном состояния GoF (или вы можете использовать инструмент SMC, который делает это только для конечных автоматов) для реализации бизнес-правил. Объедините это с BDD, и вы легко обнаружите некоторые проблемы, и вы сможете легко изменить правила, не повредив существующий код (благодаря шаблону проектирования). В моей магистерской диссертации я стремлюсь создать набор много DSL, которые позволят вам описать взаимодействие с приложением способом BDD, но позволят вам не просто генерировать тесты, такие как Cucumber, но также (частичный) макет приложения (если вы хотите видеть кнопку на какой-то странице, очевидно , на этой странице вы хотите иметь эту кнопку ...). Вы также взаимодействуете с некоторыми объектами предметной области, которые можно моделировать в соответствии с используемой архитектурой, например, в стиле Domain Driven Design. Я думаю, что это вполне реально, и тогда действительно стоит моделировать. Для нисходящего дизайна вам нужна какая-то абстракция, чтобы двигаться сверху вниз, поэтому необходим предварительный дизайн.