My<cod/>.net
Agile архитектуры
Я начинаю свою дипломную работу, и тема будет "agile architectures"
В основном, он будет начинаться с описания традиционных методологий разработки программного обеспечения и последующего рождения методологий agile, заканчивая рекомендациями и дизайном гибкой архитектуры приложений, легко адаптируемой к присущим изменениям в программном обеспечении.
Мой вопрос в том, какие шаблоны и методы проектирования вы бы порекомендовали для такой архитектуры? Меня интересуют шаблоны, которые позволяют максимизировать развязку классов, такую как инъекция зависимостей, высокая ремонтопригодность и максимальная абстракция от конкретной проблемы.
Определенно IoC практика и контрактное программирование в целом будут в верхней части моего списка. Однако, исходя из опыта, я бы предостерег от слишком большого абстрагирования от проблемы просто ради абстракции. E.g. абстрагируясь, потому что вы можете, а не потому, что кто-то когда-либо сможет использовать эту абстракцию. Я видел, что такая архитектура испортилась и просто добавила слишком высокую степень сложности к системе, что ухудшило обслуживание системы.
Какой-то цикл обратной связи вокруг вашего процесса разработки-будь то модульные тесты, непрерывная интеграция и/или встречи "scrum". Я понимаю, что на самом деле это не относится к области agile "architectures", но если у вас нет процесса и agile, никакая степень архитектуры "agile-oriented" не будет иметь значения.
Основной метод проектирования, который я бы предложил, - это сначала построить функциональный, end-to-end скелет вашей архитектуры. Чтобы проверить его как можно раньше с помощью реальной обратной связи.
Это то, что прагматичные программисты называют "трассирующими пулями", а Алистер Кокберн - "ходячим скелетом".
Вы также можете определить, что такое приложение контекст вашей диссертации ? Вы рассматриваете только прикладное программное обеспечение или вы также имеете дело с более сложными системами ?
Если Роберту Мартину есть что сказать по этому поводу (а он назвал оригинальную встречу Манифеста Agile IIRC), то абсолютно архитектура имеет все к тому, чтобы с ловкостью. Весь первый раздел его книги Agile "разработка программного обеспечения, принципы, шаблоны и практики " посвящен архитектурным принципам SOLID. Это было несколько спорно в некоторых кругах, но я не понимаю, почему. Если ваша кодовая база хрупка и сильно связана, то она не может быть очень открыта для изменений, что является отличительной чертой гибкости. Концептуально отделить процесс от практики кода-это очень нехорошо.
Принцип 1 манифеста: "We value individuals and interations over processes and tools."
Определение Agile "process" как абстракции, отдельной от архитектуры кодовой базы, для меня нарушает дух этого первого принципа.
Это очень интересный вопрос. Можно ли создать архитектуру agile изолированно? Если мы смотрим на что-то вроде XP, то я немного сомневаюсь. Или, может быть, я неправильно понял,но это никогда не останавливало меня от расширения...
В XP, чтобы принять подход, о котором я знаю больше, у нас будет какая-то структура в течение очень короткого времени после того, как мы начнем проект; примерно в то время, когда первая история будет завершена. Во время первоначального написания истории мы начнем получать некоторое представление о том, что мы могли бы построить-это неизбежно: программисты склонны думать в терминах кода. Но если мы будем думать слишком далеко вперед, то окажемся на территории YAGNI .
Я вроде как думал, что большая часть архитектуры приложения, разработанного в среде agile, как ожидается, будет возникать благодаря, в частности, постоянному и специализированному рефакторингу для устранения дублирования.
Поэтому, возможно, вопрос заключается в том, чтобы оценить, есть ли определенные характеристики - или классы характеристик-которые архитектуры, эволюционировавшие в результате процесса agile, будут иметь тенденцию отображать. И тогда я думаю, что это будет зависеть от того, какое приложение мы создаем, хотя некоторые из уже упомянутых принципов (некоторые из которых я даже понимаю) должны быть вероятными.
Насколько я понимаю, Agile не проповедует никакого "Architectures" как такового. Agile-это методология, основанная на фундаментальных принципах, которые влияют на управление проектами, циклы выпуска и общую практику разработки, но, конечно, не на архитектуру программного обеспечения.
Все шаблоны программного обеспечения, перечисленные здесь, могут быть использованы с использованием сильного процесса водопада, который является анафемой для разработки Agile.
Быть agile означает, что вы принимаете изменения, т. е. принимаете изменения в требованиях и проектных решениях и принимаете рефакторинг и т. д.. многие вещи "traditional" way будут хмуриться, так как вы касаетесь чего-то, что работает/ранее согласовано.
В таких методах, как XP пытается сохранить высокое качество, написав модульные тесты. Давайте представим, что мы все согласны на написание модульных тестов.
Теперь вот где вы можете ввести некоторую архитектуру, чтобы система была тестируемой или тестируемой, потому что не все системы тестируемы. Например, сделать средний слой вызываемым и отделить слой UI от бизнес-логики и т. д.