Какой шаблон проектирования лучше всего подходит для итеративной разработки?

Используйте для разработки динамический язык, такой как Python или Ruby: вам не нужно бороться со многими проблемами, которые есть у других языков, которые в первую очередь являются причиной появления «шаблонов проектирования».

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

Я не уверен, что это значимый вопрос. Но я не позволю этому остановить меня ...

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

Обновлено: Но если вам нужен окончательный ответ, тогда Мост. Этот подходит. Или посетитель, мне он тоже нравится. Или большинство из тех, которые начинаются на «F». :)

Шаблоны проектирования - это инструменты, помогающие решать определенные типы проблем. Использование шаблонов регулируется проблемами, определяемыми объемом требований, а не методологией разработки.

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

Однако вы можете подчеркнуть некоторые моменты в архитектуре вашего приложения:

• Делайте вещи предельно модульными. Обними Слабая связь.
• Установите очистку концептуальные границы между модулями. Под концептуальным я подразумеваю, что для начала он должен быть ясным, естественным. Случайный программист, спросивший об этом, должен ответить: «Ух ты, очевидно, как ты это сделал!».
• Начни с малого. Не пытайтесь создать ZOMG-this-will-be-the-best-and-most-universal-class-library-and-program-and-something. Заставьте вещи работать, а затем расширьте, но только при необходимости.
• Убедите себя, что YAGNI (вам это не нужно). Не делайте того, в чем не уверены. Это не означает промедление или что-то в этом роде. Это означает, что ничего не делайте, потому что «я не знаю, это может пригодиться в будущем», «технически модно», «я включу это на всякий случай».
• DRY - не повторяйся. Убедитесь, что вы не столкнетесь с проблемами дублирования кода. Подумайте о генераторах кода, хороших абстракциях и продуктивном общении в команде.

Думаю, вопрос можно было бы переписать, чтобы он имел больше смысла в этих словах:

«Какие архитектурные шаблоны и стратегии полезны для достижения гибкости при использовании стратегии тестовой и инкрементальной разработки?»

Я отвечу так: шаблоны, которые помогут вам разделить классы и компоненты, например:

• Инверсия управления и внедрение зависимостей - поможет вам сохранить зависимости между вашими классами и компонентами, отделенными от определенных реализаций, которые разрешаются до времени выполнения (или времени запуска), позволяя использовать заглушки для еще не реализованной функциональности и для модульных тестов.

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

• Фабрики и прочее творческие шаблоны - они дают вам гибкость в разделах вашего кода, отвечающих за создание экземпляров объектов.

Также помните, что одна из мантр инкрементальной и итеративной разработки - «Сделайте самое простое, что только может сработать». Не переусердствуйте.

Имеет ли это смысл в соответствии с тем, что вы спросили?