Здравствуйте, 0x7be, Вы писали:
0>Что-то не уловил сначала
0>Ладно, а что не является архитектурой, и в чем критерий, отделяющий архитектуру от не-архитектуры?
Я похоже тоже сначала не уловил вопрос. Меня запутала фраза "не-архитектуры", это может быть всем чем угодно. Но если выбирать только между тем, что влияет на структуру и поведение системы, то можно сказать, что в ахритектуру "попадает" только самое важное для системы с точки зрения ее структуры, использования и развития. А вот что важно, а что не очень, для каждой системы нужно определять каждый раз отдельно. Это не противоречит моему предыдущему ответу.
Здравствуйте, ZevS, Вы писали:
G>>Кстати, в нашем случае ZS>>> Архитектура — выкокоуровневая структура, дизайн — процесс специфицирования структуры ну или сама спецификация. G>>это даже не интересно.
ZS>Ровно тоже самое написано в стандарте IEEE 1471 и заменившем его ISO/IEC 42010, и моему пониманию такое определение ближе, чем, скажем, определение Фаулера — "architecture is the set of design decisions that must be made early in a project". Про википедию, это был легкий троллинг))
Начнем с того, что разных определений одной и той же штуки может быть много. Например, в математическом анализе есть множество способов, как ввести действительные числа. Разные определения могут быть эквивалентны, и тогда никакое из них не ближе. Это в математике.
А когда мы говорим о сложных и непонятных штуках, встречающихся в реальной жизни, например — о физике, разные определения одного и того же могут быть не просто не эквивалентны, но противоречить друг другу. Опираясь, при этом, на разные аспекты одного и того же явления. Взять например, свет. В физике, он может определяться как поток частиц, или как волна.
Какое определение верное? Оба неверны. Ни одно из этих двух определений света не описывает свет исчерпывающим образом. И они оба верны, так как в совокупности описывают одно и то же явление.
“Чем богаче подлежащий определению предмет, то есть чем больше различных сторон он предоставляет рассмотрению, тем более различными оказываются даваемые ему дефиниции. Так, например, существует масса дефиниций жизни, государства и т. д. Геометрии, напротив, легко давать дефиниции, так как ее предмет, пространство, очень абстрактен”.
Гегель
Но мы отвлеклись. Теперь об "архитектуре". Проблема с этим, с позволения сказать, термином, в том, что его все употребляют, но никто толком не знает, что это такое. Определений невероятное количество. Их десятки. Многие из них верны. Но большинство бесполезно. Особенно те, которые присутствуют в комитетских стандартах. "Комитетские" определения сложных и противоречивых вещей (как и википедия) особенно плохи из-за тенденции группы людей при обсуждении фиксироваться на common knowledge, в то время, как в таких случаях самое интересное как правило лежит за его границами.
Взять определение Фаулера. "architecture is the set of design decisions that must be made early in a project" — это, да? Оно верно, но бесполезно чуть менее, чем полностью. Потому, что нас интересует осмысленный ответ на вопрос, какие решения должны быть приняты осознанно, и рано. Нам надо уметь их как-то отличать от тех других. Фаулер, между нами, вообще весь такой.
Другой философ, Диоген, ощипал цыпленка и бросил его к ногам Платона со словами: “Вот твой человек”. После этого Платон уточнил свое определение: человек — это двуногое бесперое существо с широкими ногтями.
Классическое определение, про "структуры", характерно тем, что оно понятно исключительно интуитивно. И больше никак. А как до дела доходит, оно также бесполезно, потому, что а-приори этот высокий или низкий уровень структуры на практике не различим. Какие-либо внятные критерии его различия отсутствует. Масштаб — относителен, и критерием быть не может, это пустышка, а не определение, так же, как и у фаулера. Ничего полезного для действия из этого определения не выводится.
Еще один философ охарактеризовал человека как существо с мягкой мочкой уха. По какому-то капризу природы оказалось, что из всех живых существ только у человека мягкая мочка уха.
Перечисленное выше приводит к тому, что слово "архитектура" на деле техническим термином не является, ничего определенного и понятного для собеседников не значит, и его полезнее попросту запретить к употреблению.
Помимо отграничения определяемых предметов, к определению обычно предъявляется также требование раскрывать сущность этих предметов.
Более внятный термин, чтобы описать явление и проблемы, о которых смутно бредят люди, произнося слово "архитектура" — это Common Design Principles. Вот есть Design. А есть — его Common Principles.
Наиболее практически полезное определение — про правила. У него, конечно, есть недостатки. Ну, например, его автор не Фаулер. И оно не написано в комитетском стандарте. Зато оно проводит наиболее точную и понятную границу с дизайном, описывает все известные эффекты, как пример с юнит-тестами, приведенный товарищем выше (отличный пример, структурные определения его не описывают), и включает в себя социальные аспекты архитектуры. Потому, что правила выполняются людьми. И, что более важно, люди склонны забывать на правила большой болт.
Это важно потому, что определение дает понимание, а понимание требуется для действия.
Но так как мы уже выяснили, что одного единственно верного определения для сложных явлений не бывает — каждый волен пользоваться своим любимым.
Здравствуйте, Gaperton, Вы писали:
G>Более внятный термин, чтобы описать явление и проблемы, о которых смутно бредят люди, произнося слово "архитектура" — это Common Design Principles. Вот есть Design. А есть — его Common Principles. G>Наиболее практически полезное определение — про правила. У него, конечно, есть недостатки. Ну, например, его автор не Фаулер. И оно не написано в комитетском стандарте. Зато оно проводит наиболее точную и понятную границу с дизайном, описывает все известные эффекты, как пример с юнит-тестами, приведенный товарищем выше (отличный пример, структурные определения его не описывают), и включает в себя социальные аспекты архитектуры. Потому, что правила выполняются людьми.
Если внимательно почитать, то в комитетском определении учтены "известные эффекты, как пример с юнит-тестами". Другое дело, что стандарт не про архитектуру, а про описание архитекруты, ее спецификацию. Про собственно архитектуру там, по-сути, только определение.
G>Но так как мы уже выяснили, что одного единственно верного определения для сложных явлений не бывает — каждый волен пользоваться своим любимым.
Сложное явление является ровно тем, что говорит определение, на то оно и определение. А отсутствие единства в том, что такое архитектура ПО просто показывает незрелость отрасли.
Здравствуйте, ZevS, Вы писали:
G>>Но так как мы уже выяснили, что одного единственно верного определения для сложных явлений не бывает — каждый волен пользоваться своим любимым. ZS>Сложное явление является ровно тем, что говорит определение, на то оно и определение.
Только в математике определение определяет то, чем является объект или явление.
В жизни и пророде все не так — сложное явление является само, и плевать хотелo на все наши определения. Особенно — на откровенно неудачные.
ZS>А отсутствие единства в том, что такое архитектура ПО просто показывает незрелость отрасли.
Странное дело, все-таки. В "отрасли" уже несколько поколений сменилось, а она все незрелее и незрелее
Здравствуйте, Gaperton, Вы писали:
G>Только в математике определение определяет то, чем является объект или явление. G>В жизни и пророде все не так — сложное явление является само, и плевать хотелo на все наши определения. Особенно — на откровенно неудачные.
Архитектура это не явление, а абстрактное поняние. А понятие без определения не существует.
ZS>>А отсутствие единства в том, что такое архитектура ПО просто показывает незрелость отрасли. G>Странное дело, все-таки. В "отрасли" уже несколько поколений сменилось, а она все незрелее и незрелее
Тут нужно дать определение зрелости отрасли
Прочитал по диагонали, но сам думаю так:
Архитектура — части системы, из которых создается программное окружение, архитектурный компонент можно выкинуть или заменить, внести значительные изменения маловероятно. Дизай это программная реализация модели реального мира в выбранном программном окружении.
Приведу граничные условия для ясности:
Например в проекте используется open source библиотека или билиотека другой команды — это архитектурный компонент, т.к. он не является реализацией нашей программной модели, а реализует свою модель реального мира и адаптировать его под себя сложно или невозможно, т.к. требования могут быть взаимо исключающими.
Считаю, что в архитектуре изначально следует предположить от чего необходимо асбтрагироваться( например транспорт), а к чему можно быть прибитым намертво (например Ось, БД).
Здравствуйте, 0x7be, Вы писали:
0>Что такое архитектура ПО?
Это набор практик организации кода, позволяющих продукту эволюционировать с сохранением его maintainability. Хорошую архитектуру, как и хорошего сисадмина, должно быть незаметно (UPD: в том смысле, что она не должна вставлять палки в колёса разработчикам).
Здравствуйте, ZevS, Вы писали:
ZS>Здравствуйте, Gaperton, Вы писали:
G>>Только в математике определение определяет то, чем является объект или явление. G>>В жизни и пророде все не так — сложное явление является само, и плевать хотелo на все наши определения. Особенно — на откровенно неудачные. ZS>Архитектура это не явление, а абстрактное поняние. А понятие без определения не существует.
"понятие без определения не существует"
Цитирую:
Понятие множества обычно принимается за одно из исходных (аксиоматических) понятий, то есть несводимое к другим понятиям, а значит, и не имеющее определения;
Итого, с учетом сказаного тобой, "множеств не существует"
Здравствуйте, mrTwister, Вы писали:
T>То есть наличие black-box тестов стало архитектурно-значимым фактором (архитектурой), который стал влиять на реализуемость тех или иных продуктовых фич. И это при том, что тесты практически не влияли на код самого продукта, так как они эмулировали действия конечного пользователя. В результате получили такую вот неожиданную архитектуру.
Наоборот, они именно влияли на код самого продукта — фичи не появились благодаря этим тестам, они препятствовали появлению в коде каких то фич.
В этом плане твои тесты являются тем самым архитектурным решением — они определяют принятие дальнейших решений, т.к. вводят неявные требования, ограничения и тд.
Здравствуйте, 0x7be, Вы писали:
0>В связи с этим хочу провести тут опрос на эту тему. Пожалуйста, дайте ответы на следующие вопросы:
0>Что такое архитектура ПО? 0>Где проходит граница между архитектурой и не-архитектурой? И, главное, почему, какой критерий отличия? 0>Зачем нужно (и нужно ли) прорабатывать архитектуру ПО?
Нужно брать готовые, понятные термины, лучше всего из военного дела. Например — стратегия и тактика. Стратегические и тактические решения.
Если принимаем решение "играть в постоянной атаке, аргессивно, подвижно, гибко" то ясно, что тактика создания мощных крепостей, долговременных укреплений, рытьё окопов и тд есть отстой. А если принято решение "играем от защиты", то ровно те же тактические решения становятся очень правильными. Примерно так же можно говорить о глобальном, локальном и тд решении.
При этом, как часто бывает, начинается всё без какого либо плана. Если какой то умник решил, условно, оборонительные вооружения применить "просто так, потому что они крутые", то фактически тем самым определил большую часть будущих проблем.
На софт всё это переносится один к одному. Архитектура(стратегия) есть явно и неявно принятые требования, ограничения и правила дизайна, которые учитывают достижение цели, решение проблемы и тд, в глобальном масштабе. Дизайн(тактика) — это определение и достижение локальных целей согласно стратегическим решениям.
