Comments 28
Не приведено ни проблем ни личного опыта. Ну, архитектура должна быть бизнес ориентированной. Хорошо...
Некий mindmap, набор абстрактных рекомендаций
Повторю еще раз мысль которую продвигаю по поводу и без. :-) Архитектура - это учет сейчас ограничений, которые не описаны, неизвестны, и может быть даже еще не существуют. Проектирование с учетом нефункциональных требований которые уже записаны - это простая (на самом деле НЕ простая, но все же инженерная!) задача. А еще архитектура - это искусство компромиссов. Потому что бесплатных улучшений не бывает. Если вы заложите гибкость там где она не нужна - это лишние затраты. Если вы не заложите гибкость там где она потом понадобится - это переделки и еще большие затраты. Задача архитектора - провести продукт по струнке между "over-engineered" сейчас и "better discard and develop from scratch" послезавтра.
Для этого, архитектор должен во-первых, понимать предметную область и куда она движется. Во-вторых, обладать кругозором и опытом - чтобы знать как оно у других людей делается. Например - если мы проектируем машину, но сейчас по требованиям нам не нужна коробка передач - инженер имеет право просто присоединить колеса к двигателю. А архитектор, подумав - оставит под нее место, но пока коробки нет - поставит соединительный вал. И когда выяснится что надо ехать быстрее/медленнее/с другим двигателем - он вал вытащит, и окажется что не надо с нуля всю повозку перепроектировать. А в другом случае, плохой архитектор может решить что в легковую машину вы должны мочь поставить все, включая дизель V12. И бедная машина будет ездить с длинным клювом - доставляя водителям много печали, притом что больше чем 1.8turbo там никто никогда так и не поставит.
Интересно , а инженеры проектирующие мосты, самолеты , заводы , электростанции работают по таким же принципам выбора архитектуры при эскизном проектировании ?
А бывает так, что инженер, выполнивший задачу "спроектировать самолёт малой авиации (кукурузник хД)" следующей задачей получает: "модифицировать его до дальнемагистрального, без прекращения эксплуатации и простоев"?
В этом и состоит вопрос вопросов - почему IT-инженерия считается отдельной отраслью инженерии?
Вспоминается классическое - "Если бы программисты строили дом".
Одно скажу точно, если бы строители строили так как современные разрабы делают современные информационные системы , жить было страшно , хотя и не долго ...
Так я уже ответил на эту вашу "заковырку".
1. Есть "задача-проект". Построить типовой дом \ типовой сайт (с прицелом чтобы его удобно было эксплуатировать).
2. Есть "задача-процесс". Создать МКС, написать "сайт" facebook.
Прикол в том, что большинство "настоящих инженеров в физическом мире" - работают над задачами типа "1" - типовой дом по проекту ХХ.YY.NNNN, только на 2 метра длиннее.
Для IT - очередной сайт, но с другим хэдером и футером и обоями - инженерной работой не считается и относится к формошлёпству. И вся инженерия существенным образом смещена в задачи, которые мало кто до этого делал (хотя бы в таком виде). Потому, как если это много кто делал - то уже есть конструктор "сделать клёво и нужными обоями".
То есть суть работы "типового физического инженера" и "типового IT-инженера" довольно существенно отличается.
суть работы "типового физического инженера" и "типового IT-инженера" довольно существенно отличается.
Да, всё именно так . тут соглашусь, и вряд ли ситуацию можно как то изменить
https://rutube.ru/video/899db0d951e205bda942a1dba77e44de/?r=a
Неплохо. Хоть ктото догадался что архитектуру (систему) надо проектировать в разных разрезах. Но отсутствует связь между вот таким ТЗ и собственно кодом - какие паттерны применять и почему
Следуем общему принципу каскадности — решения более низкого уровня основываются на том, что стоит на более высоком уровне.
Новые, прорывные, пионерские продукты имеют перевёрнутую пирамиду чем у вас. Всё начинает с кода. - (Facebook, YouTube, Google) , а дальше куда вывезет!
Если вы оттолкнетесь от принципов, перечисленных в статье, ваша архитектура перестанет быть произвольной, переусложненной, недостаточной.
Вы сможете создать архитектуру на том уровне, который будет целесообразен вашему проекту и его текущей фазе (если у вас достаточно времени и навыков, конечно).
Это касается "типового программостроения". Оно довольно однообразно строится и также без сожаления сносится потом.
Прорывные продукты делает 0 01% программистов.
Возможно и меньше 0.01% - но тем удивительнее их появление, которое переворачивает пирамиду!
1) Исключения есть всегда и везде и, как известно, они лишь подтверждают правило.
2) Эти прорывные продукты и придуманы программистами, то есть, они и есть заказчики продукта. И они думали о нем КУЧУ времени, делали много исследований перед тем, как начать реально писать продукт. Так что не такая она и перевернутая, много частей этой пирамиды у них в голове.
1) Исключения есть всегда и везде и, как известно, они лишь подтверждают правило.
Это так, но это неверно. - Более строго "исключение подверждает наличие правила, а вовсе не верность этого правила."
2) Эти прорывные продукты и придуманы программистами, то есть, они и есть заказчики продукта.
Эти прорывные продукты конечно были кем то придуманы, но основаны они были на коде, который не был изначально предназначен для них вовсе.
В пирамиде же в этой статье вначале появляется идея некого продукта, а потом уже на вершине пирамиды код, как символ реализации этой идеи.
А перечисленные выше прорывные продукты были основаны на коде, который изначально был создан на основании совершенно иных идей. - пирамида переворачивается.
Кстати, сегодня в одной рассылке пришёл мне такой текст. Почему сегодня?- я не знаю. Но так произошло:
«Нам нужно понимать, какую проблему мы решаем», — эту фразу я слышал на бесчисленных совещаниях по стратегии продукта — в Medium и в каждой компании, в которой я работал.
Это особенно верно в разработке программного обеспечения, где, как правило, вы работаете в обратном направлении от проблемы к потенциальным решениям. Управление продуктом, как описывает Уджвал Триведи , является дисциплиной определения этих проблем , что часто означает поиск скрытых проблем, скрытых под теми, которые вы назвали.
Обычно процесс выглядит примерно так:
1. Глубоко поймите проблему.
2. Определите точное решение.
3. Создайте осознанный и предсказуемый опыт.
4. Поставьте готовый продукт, который ведет себя именно так, как и ожидалось.
Но, как замечает Патрик Морган, ставший дизайнером и писателем, некоторые из лучших вещей на Земле были изобретены не так. Большинство по-настоящему монументальных изобретений начинались не с проблемы, а с наблюдения.
Александр Флеминг не собирался открывать антибиотики ; он просто заметил странную белую плесень, растущую в его чашке Петри (привет, пенициллин).
Заметки на стикерах были неудачным экспериментом с клеем .
Даже LLM, отмечает Морган, вероятностны, а не детерминированы — они сопротивляются полному пониманию, и их результаты всегда немного неожиданны (по замыслу). Проблемы, которые они решают, все еще остаются в некотором роде TBD .
История Моргана сосредоточена на разработке опыта ИИ, но, я думаю, что суть в том, что каждый может принять близко к сердцу: иногда лучшие решения приходят, когда вы просто следуете своим инстинктам, делаете то, что вам интересно, и выясняете, где вы можете использовать это позже. «Решения в поисках проблем» не всегда являются пустой тратой времени.
Имея это в виду, Морган меняет свой процесс проектирования. Вместо того, чтобы начинать с проблемы, он начинает с намерения.
1. Имейте намерение — представление о том, чего вы пытаетесь достичь.
2. Экспериментируйте, повторяйте и двигайтесь вперед, не имея особой ясности.
3. Откройте для себя неожиданный прорыв — он работает, но не так, как вы думали.
4. Вы изучаете прорыв, совершенствуете его, а затем выясняете, почему он работает.
(Харрис Соккель)
Не согласен с вами насчет Facebook, Google, YouTube: все эти продукты хоть и были созданы программистами, но их архитектура и то, как они создавались - было основано на довольно понятных целях чего хотели авторы. Авторы YouTube делали сервис знакомств с видео - от этого им надо было решить как это видео хранить и показывать.
Думаю есть продукты инновационные продукты, которые рождались от того кто-то что-то внезапно изобрел - слышал что есть ученые, которые изучают и проектируют алгоритмы распредленных БД или делают какие-то эксперименты в области машинного обучения - но кажется чаще все куда прагматичнее.
И я не стал бы делить продукты на 100% инновационные и 100% типовые. Да, большинство не пишет БД и языки программирования, не создает сверхнагруженные софт для Гугл, и не обучает новые нейронки, но задач достаточно сложных хватает.
Не согласен с вами насчет Facebook, Google, YouTube: все эти продукты хоть и были созданы программистами, но их архитектура и то, как они создавались - было основано на довольно понятных целях чего хотели авторы. Авторы YouTube делали сервис знакомств с видео - от этого им надо было решить как это видео хранить и показывать.
Вот вы сами написали, что они делали, - сервис знакомств с видео (YouTube), сервис для обсуждения студенток универа (Facebook), и алгоритм ранжирования страниц (BackRub - он же потом Google) - и вот вопрос- этот их код породил потом тех гигантов что они стали сейчас или что?
Или Java - язык созданный для идеи "виртуальной машины" для запуска в устройствах типа управления телевизором и прочих микросистем. - никто не думал что Java "полезет" на сервера (ну зачем на сервере запускать в те времена ещё и некую виртуальную машины? - это никому тогда и в голову не приходило вовсе.)
И о пирамиде в статье. Ок, можно уменьшить эту пирамиду до пирамидки и добавить ещё большую, но уже перевёрнутую пирамиду, которая своей острой вершиной стоит на вершине маленькой не перевёрнутой пирамидки (вид как у "песочных часов").
То есть можно переиначить известное "Когда б вы знали, из какого сора. Растут стихи, не ведая стыда" в " Когда б вы знали, из какого кода растут системы, покоряя мир".
решения более низкого уровня основываются на том, что стоит на более высоком уровне
И прям сразу за этим рисунок, где всё наоборот. Ну как же так)
Хаха, я только сейчас заметил... Пирамидку хотелось на основание поставить.
Забавно наблюдать, как люди в комментариях, даже у статей, где суть описана в названии, продолжают сетовать на отсутствие "волшебной таблетки" в тексте. В том или ином виде.
Автору - спасибо)
6 принципов архитектуры ПО для старта проекта