Некоторое время назад со своими сотрудниками обсуждал вопрос о том, что такое архитектура.
Слово весьма заезженное, его часто употребляют в наших профессиональных обсуждениях. Однако четкого определения мне мои коллеги дать не смогли.
В связи с этим хочу провести тут опрос на эту тему. Пожалуйста, дайте ответы на следующие вопросы:
Что такое архитектура ПО?
Где проходит граница между архитектурой и не-архитектурой? И, главное, почему, какой критерий отличия?
Зачем нужно (и нужно ли) прорабатывать архитектуру ПО?
Здравствуйте, 0x7be, Вы писали:
0>Слово весьма заезженное, его часто употребляют в наших профессиональных обсуждениях. Однако четкого определения мне мои коллеги дать не смогли.
0>Что такое архитектура ПО? 0>Где проходит граница между архитектурой и не-архитектурой? И, главное, почему, какой критерий отличия?
формальное определение не дам, но субъективно под этим лично я понимаю зафиксированный документально свод информации, описывающий макроаспекты построения компонентов, обоснующий наличие каждого из них, и раскрывающий ключевые детали их сочетания и взаимодействия, а также основные технические рекомендации и ограничения на подходы к их реализации (иными словами, какие библиотеки третьих сторон, в т.ч. платные, могут быть использованы, что запрещено и проч.). в них могут и должны устанавливаться рамки ответственности разных сторон, вовлечённых в разработку.
основной контингент читающих — вовлечённые в разработку и приёмку (в широком смысле, т.е. включая аналитиков, разных поставщиков, тестировщиков и т.п., а также представителей заказчика и/или интегратора)
можно, естественно, говорить и об архитектурах более низкого уровня (раскрытие деталей конкретного компонента и проч.), но с ними доводится сталкиваться реже, т.к. чаще всего круг потребителей такой информации более узок, и он может разговаривать уже на ЯП. микроархитектуры, однако, полезны там, где может появляться соприкоснование сторон (например, разработчиков компонента и используемой для его реализации библиотеки)
0>Зачем нужно (и нужно ли) прорабатывать архитектуру ПО?
убеждён, что нужно. ключевой момент — потребители.
чем выше разнообразие вовлечённых потребителей, особенно по-разному заинтересованных экономически и/или политически, тем важнее им дать всю информацию из единого центра — это дисциплинирует, даёт возможность разговаривать на одном языке и избежать технического недопонимания на стадиях реализации; в начале — дать возможность поставщикам определить необходимые профили персонала, в процессе — определить порядок взаимодействия разных сторон и людей и организовать своевременную подготовку тестовых стендов, в конце — обеспечить формальной стороной интеграционную приёмку.
несколько дней назад консультировал проект, в котором общение со стороны заказчика-интегратора построено на внушении, а не документировании. архитектуру никто из поставщиков до конца не понимает, всё делается на лету, а на проекте есть решения, не позволяющие легко войти, и есть персонал, не готовый ни технически, ни морально к такому развитию событий. консультанты тоже ни к селу, ни к городу, т.к. их привлекают для решения проблем первого плана, осознанных сиюминутно, когда фактически им приходится отвечать на более фундаментальные вопросы.
Здравствуйте, 0x7be, Вы писали:
0>Что такое архитектура ПО? 0>Где проходит граница между архитектурой и не-архитектурой? И, главное, почему, какой критерий отличия? 0>Зачем нужно (и нужно ли) прорабатывать архитектуру ПО?
Обсуждение любых абстрактно-философских вещей наподобие паттернов и сфероконичной архитектуры в вакууме — это всегда очень много букв. Просто потому, что у каждого свои тараканы своё представление об идеальном и подружить их очень непросто.
Здравствуйте, Sinix, Вы писали:
S>Взаимоисключающие параграфы вижу я
S>Обсуждение любых абстрактно-философских вещей наподобие паттернов и сфероконичной архитектуры в вакууме — это всегда очень много букв. Просто потому, что у каждого свои тараканы своё представление об идеальном и подружить их очень непросто.
А почему обязательно это должны быть абстрактно-философские вещи?
Имхо, это признак незрелости нашей отрасли или отдельных людей.
Хочется как раз побольше конкретики и лапидарности
Здравствуйте, 0x7be, Вы писали:
S>>Обсуждение любых абстрактно-философских вещей наподобие паттернов и сфероконичной архитектуры в вакууме — это всегда очень много букв. Просто потому, что у каждого свои тараканы своё представление об идеальном и подружить их очень непросто. 0>А почему обязательно это должны быть абстрактно-философские вещи?
Потому что для чего-то более приземлённого нужно учитывать язык программирования, инструментарий, используемый процесс разработки, уровень команды и тд и тп. Вот вам прекрасный пример обсуждения
. Как только переходим на конкретику — обсуждение сворачивается, потому что тут или знаешь, или нет, обсуждать нечего. А вот потрындеть за "что такое паттерн?" — это всегда пожалуйста
0>Имхо, это признак незрелости нашей отрасли или отдельных людей. 0>Хочется как раз побольше конкретики и лапидарности
Тогда велкам в книги по конкретной технологии. Для дотнета есть книга-исключение, "Framework Design Guidelines": сугубо практичные и проверяемые рекомендации, без воды и закидонов типа "так говорил Фаулер". Для других языков ничего подобного не попадалось, но я особенно и не искал.
Здравствуйте, Sinix, Вы писали:
S>Потому что для чего-то более приземлённого нужно учитывать язык программирования, инструментарий, используемый процесс разработки, уровень команды и тд и тп. Вот вам прекрасный пример обсуждения
. Как только переходим на конкретику — обсуждение сворачивается, потому что тут или знаешь, или нет, обсуждать нечего. А вот потрындеть за "что такое паттерн?" — это всегда пожалуйста
То есть ты считаешь, что само понятие архитектуры существует исключительно в контексте конкретной технологии?
Здравствуйте, 0x7be, Вы писали:
S>>Потому что для чего-то более приземлённого нужно учитывать язык программирования, инструментарий, используемый процесс разработки, уровень команды и тд и тп. 0>То есть ты считаешь, что само понятие архитектуры существует исключительно в контексте конкретной технологии?
Ну и где я такое говорил?
Вопрос был про "почему так много букв вместо пары абзацев", ответил выше:
Просто потому, что у каждого свои тараканы своё представление об идеальном и подружить их очень непросто.
По архитектуре — перечитай пост Gaperton-а по ссылке выше, он там предлагает не смешивать мух с котлетами (дизайн с архитектурой). И подробно расписывает, какое отношение имеет архитектура к используемым технологиям.
Здравствуйте, 0x7be, Вы писали:
0>Что такое архитектура ПО? 0>Где проходит граница между архитектурой и не-архитектурой? И, главное, почему, какой критерий отличия? 0>Зачем нужно (и нужно ли) прорабатывать архитектуру ПО?
Я люблю использовать поразительные заголовки, лучшие из которых (как вот этот) несут важную информацию, неочевидную с первого взгляда. Помните второе определение Джонсона: "Архитектура – это набор решений, которые вы бы хотели принять верно на ранних этапах работы над проектом". Почему кто-то хочет, чтобы некоторые решения были правильными с самого начала? Конечно же потому, что они думают, что их будет сложно изменить позднее. Так, мы можем прийти к определению, что архитектура – это “решения, изменить которые считается сложным”.
...
Мне кажется, что одной из главных задач архитектора является удаление архитектуры путем устранения необратимости в дизайне ПО.
Здравствуйте, artelk, Вы писали:
A>Мне нравится Фаулервское объяснение: http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
Я полностью согласен с его подходом к определению, но исключительно сомневаюсь в реализуемости принципа устранения архитектуры
Здравствуйте, artelk, Вы писали:
A>Мне нравится Фаулервское объяснение:
Там есть куда более интересный кусок от Ralph Johnson:
There is no theoretical reason that anything is hard to change about software.
If you pick any one aspect of software then you can make it easy to change,
but we don’t know how to make everything easy to change.
Making something easy to change makes the overall system a little more complex,
and making everything easy to change makes the entire system very complex. Complexity is what makes software hard to change.
Вот это тру-инженерный подход, в отличие от "мыши станьте ёжиками" Фаулера.
У последнего вообще любая выдернутая из контекста цитата выглядит как шикарное готовое решение. Которое на практике неизменно приводит к "никогда такого не было, и вот опять"
Впрочем, он сам признавался:
I love writing a startling heading [that] have an important meaning that’s not immediately obvious
Согласен.
IT>Хорошая аналогия у Гипертона — архитектура и дизайн соотносятся как стратегия и тактика.
Теперь объясняйте, что такое стратегия, тактика и где между ними происходит граница
UPD: а ведь между ними герр Мольтке ещё и оперативный уровень ввернул
A>Мне кажется, что одной из главных задач архитектора является удаление архитектуры путем устранения необратимости в дизайне ПО.
Я даже знаю как это сделать.
KISS
Сохраняёте её простой и мальенькой.
Если программа целиком умещается в голове программиста, то её всегда можно перестроить.
Здравствуйте, gandjustas, Вы писали:
G>4 года назад было такое же обсуждение G>Вот что тогда написал — http://gandjustas.blogspot.ru/2011/01/blog-post.html
Тут дело такое — меня интересует не сколько конкретное определение, сколько обоснование, почему так
Ну или, если хочешь, некий четкий критерий, который бы мог определить, является ли то или иное решение архитектурным или нет.
Лично я считаю, что архитектура — это всё то, что дорого поменять и, следовательно, в чем дорого ошибиться.
Соответственно, разработка архитектуры — это по сути управление рисками.
Соответственно, любое решение, которое потом передумать нам "по карману" не является архитектурным
Соответственно, определяющим является толщина кармана.
Как-то так.
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, gandjustas, Вы писали:
G>>4 года назад было такое же обсуждение G>>Вот что тогда написал — http://gandjustas.blogspot.ru/2011/01/blog-post.html 0>Тут дело такое — меня интересует не сколько конкретное определение, сколько обоснование, почему так 0>Ну или, если хочешь, некий четкий критерий, который бы мог определить, является ли то или иное решение архитектурным или нет.
0>Лично я считаю, что архитектура — это всё то, что дорого поменять и, следовательно, в чем дорого ошибиться. 0>Соответственно, разработка архитектуры — это по сути управление рисками. 0>Соответственно, любое решение, которое потом передумать нам "по карману" не является архитектурным 0>Соответственно, определяющим является толщина кармана. 0>Как-то так.
Кроме толщины кармана есть еще time to value, то есть время до того, как потребитель получит ценность.
А еще есть другой аспект. Зачастую не все архитектурные решения принимает разработчик. В корпоративных системах или навороченных веб-сервисах архитектура может определяться другими компонентами. Поэтому очень важно чтобы то, что ты сделаешь в приложении вписалось в архитектуру системы.
Что касается управления рисками, то любое управление по сути управление рисками — будь то управление архитектурой или отделом продаж.
Здравствуйте, gandjustas, Вы писали:
G>Кроме толщины кармана есть еще time to value, то есть время до того, как потребитель получит ценность. G>А еще есть другой аспект. Зачастую не все архитектурные решения принимает разработчик. В корпоративных системах или навороченных веб-сервисах архитектура может определяться другими компонентами. Поэтому очень важно чтобы то, что ты сделаешь в приложении вписалось в архитектуру системы.
ИМХО, это не критерий отделения архитектуры от неархитектуры. Это просто требования и ограничения, которые надо учитывать при разработке, чтобы не сесть в лужу.
G>Что касается управления рисками, то любое управление по сути управление рисками — будь то управление архитектурой или отделом продаж.
Абсолютно согласен.
Здравствуйте, Sinix, Вы писали:
S>По архитектуре — перечитай пост Gaperton-а по ссылке выше, он там предлагает не смешивать мух с котлетами (дизайн с архитектурой). И подробно расписывает, какое отношение имеет архитектура к используемым технологиям.
Это можно в двух словах объяснить. Архитектура — это формальные и/или неформальные правила, руководствуясь которыми люди превращают требования в дизайн. "Наши данные мы храним в MS SQL, с которым работаем при помощи вот такого ORM" -- простейший пример такого правила. "...руководствуясь которыми люди делают..." — это очень важно, ибо если есть какие-то правила, а люди ими на деле не руководствуются, то это никакая не архитектура. А вольная фантазия на тему.
Если нам не помогут, то мы тоже никого не пощадим.
