Инструменты проектирования структуры программы? (Дизайн сверху вниз)

Question

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

Итак, на этой ноте, в основном не зависящей от языка, есть ли какие-нибудь полезные инструменты, о которых я (вероятно) не знаю? Например, у меня часто возникало желание попробовать построить блок-схемы для моих программ, но я не уверен, насколько это поможет, и меня немного смущает, как я могу сделать достаточно сложную блок-схему для обработки логики полная программа, и все ее функции ... то есть, кажется, что блок-схемы будут ограничивать схему проекта ... или, возможно, вырастут до неуправляемого масштаба. Методы BDD хороши, но с системой, которая так привязана к структуре, привязка к языку и модульное тестирование кажутся необходимостью (для того, чтобы это того стоило), и кажется, что трудно найти что-то, что работает хорошо как с Python, так и с Java (два моих основных языка).

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

Answer 1

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

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

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

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

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

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

---

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

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

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

Answer 2

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

Answer 3

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

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

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

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

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

  my2c

Answer 4

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

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

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