Гибкие архитектуры [закрыты]

Question

Я начинаю свою дипломную работу, и тема будет "гибкие архитектуры".

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

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

Answer 1

Я рекомендую следующее:

1. Шаблон репозитория
2. Шаблон спецификации
3. Внедрение зависимостей
4. Проектирование, ориентированное на предметную область

В основном все на ALT.NET толпа проповедует.

Answer 2

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

Своего рода цикл обратной связи вокруг вашего процесса разработки - будь то модульные тесты, непрерывная интеграция и / или встречи "scrum".Я понимаю, что на самом деле это не входит в сферу применения гибких "архитектур", но если у вас нет гибкого процесса, никакая степень "гибко ориентированной" архитектуры не будет иметь значения.

Answer 3

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

Это то, что Прагматичные программисты называют "Трассирующими пулями", а Алистер Кокберн - "ходячий скелет".

Можете ли вы также определить, что такое приложение в контексте вашей диссертации?Вы только рассматриваете прикладное программное обеспечение или вы также имеете дело с более сложными системами?

Answer 4

Это интересный вопрос.Можно ли создать гибкую архитектуру изолированно?Если мы смотрим на что-то вроде XP, то я немного сомневаюсь.Или, может быть, я что-то неправильно понял, но это никогда не мешало мне расширяться...

В XP, если использовать подход, о котором я знаю больше, у нас должна быть какая-то структура в течение очень короткого времени после запуска проекта;на самом деле, примерно в то время, когда будет завершена первая история.Во время первоначального написания истории мы начнем получать некоторое представление о том, что мы могли бы создать - это неизбежно:программисты склонны мыслить в терминах кода.Но заглядывание слишком далеко вперед приводит нас к ЯГНИ территория.

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

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

Answer 5

Насколько я понимаю, Agile не проповедует никаких "Архитектур" как таковых.Agile - это методология, основанная на фундаментальных принципах, влияющих на управление проектами, циклы выпуска и общую практику разработки, но, конечно, не на архитектуру программного обеспечения.

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

Answer 6

Луковая Архитектура

пример

Answer 7

Быть гибким означает, что вы принимаете перемены, т.е.адаптироваться к изменениям в требованиях и проектных решениях, согласиться на рефакторинг и т.д..многие вещи "традиционным" способом вызвали бы неодобрение, поскольку вы прикасаетесь к чему-то, что работает / ранее согласовано.

В таких методах, как XP, пытается поддерживать высокое качество, написав модульные тесты.Давайте представим, что мы все согласны с написанием модульных тестов.

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

Answer 8

Если Роберту Мартину есть что сказать по этому поводу (а он назвал оригинальный Agile Manifesto meeting IIRC), то абсолютно все, что связано с Agility, связано с архитектурой.Весь первый раздел его книги Гибкая разработка программного обеспечения, принципы, шаблоны и практики речь идет о ТВЕРДЫЙ архитектурные принципы.В некоторых кругах это вызвало некоторую полемику, но я не понимаю почему.Если ваша кодовая база хрупкая и сильно взаимосвязана, то она не может быть очень открытой для изменений, что является отличительной чертой гибкости.Концептуально отделять процесс от практики написания кода - это очень негибкая вещь.

Принцип 1 манифеста:"Мы ценим отдельных людей и взаимодействие больше, чем процессы и инструменты".

Определение Agile "процесса" как абстракции, отдельной от архитектуры кодовой базы, на мой взгляд, нарушает дух этого первого принципа.