Comments 15
Если желание двигаться в архитектуру сохранилось, ищите не "титул" и не курс, а реальную ответственность на стыке систем — даже если для этого придётся выйти за привычные рамки или сменить контекст.
«Реальная ответственность на стыке систем» – звучит красиво, как будто пишет ИИ, а не живой человек. Да и «выйти за привычные рамки или сменить контекст» тоже «непонятно, но здорово!».
А можно я попробую перевести текст, сгенерированный ИИ на человеческий?
Первое отличие «кожаного мешка» от «Искусственного Идиота», это желание говорить не «вообще», а «конкретно».
Вот мой пример. Я написал обучающую программу для изучения иностранных языков (ссылки – в моих статьях здесь). Безотносительно нужности / ненужности программы либо её полезности / бесполезности, доведение приложения до рабочего состояния, мне чуть мозги не сломало. Тем не менее, бинарный код приложения и демо-данные к нему, на четырех языках, опубликованы. Так что, конкретное представление, о чём идет речь, получить можно.
Программа хотя и работает, но «первый блин – всегда комом!». Поэтому, когда решил начать публикацию её исходников, понял, что их, сначала, надо «причесать» и вообще «довести до ума», то бишь, сделать, более-менее, «приличными», чтобы «не стыдно было показать людям».
Для этого начал размышлять об архитектуре приложения и его модульности. Вопрос «на засыпку», вот если бы я был архитектором проекта и имел команду программистов человек, этак, несколько или, может быть, в два раза больше, :) , то как бы я организовал эту работу с нуля, так чтобы на выходе получить вторую версию имеющейся программы?
После некоторых размышлений пришел к выводу, что надо, на уровне архитектора проекта, сделать следующее:
Предоставить команде начальный прототип программы. В данном случае, это может быть проект, сгенерированный мастером WTL, в Visual Studio C++, и «слегка» обработанный «напильником», чтобы соответствовать моим, как архитектора, «представлениям о прекрасном».
Предоставить формальные прототипы всех необходимых модулей программы, показать места их подключения, создания, использования и, при необходимости, удаления созданных (например, оператором «new», объектов).
Распределить, между членами команды, данные прототипы модулей с целью замены их формального содержимого – реальным.
Каждый челн команды работает со своей собственной локальной копией первоначального прототипа, но разрабатывает (наполняет содержимым) только указанный ему модуль.
В итоге, все формальные модули в исходном прототипе программы заменяются реальными. Программа запускается и отлаживается (тестируется), независимо для каждого модуля.
Таким образом, архитектор указывает, что и как делать, а команда – исполняет.
Здесь следует объяснить, что понимается под модулем и формальной реализацией.
В моем понимании, модуль, на С++, это автономный класс, который может быть как легко подключен к проекту, так и легко отключен от него, без потери общей функциональности приложения.
А, формальная реализация модуля, это определение класса публичных функций, с пустым телом. Иначе говоря, каждая функция класса возвращает тип «void» и, как получает управление, так сразу и отдает его, т.е., содержит максимум, один-единственный оператор «return». При этом, входные параметры могут быть произвольными.
На уровне файлов, это h-заголовок и cpp-реализация данного класса. В формальном модуле содержаться только пустые публичные функции, которые ничего не возвращают, а в реальном модуле, все публичные функции имеют тот же самый прототип, но реальное тело (необходимые возвратные значения получаем через входные параметры). При этом программист, т.е., член команды, может добавлять приватные данные и функции в «свой» модуль, на своё усмотрение.
Для прототипов оконных обработчиков событий всё остается без изменений. Просто, они будут возвращать «нулевой» тип, вроде «LRESULT» со значением «0» либо «FALSE».
Понятно, что «весь Мир», сейчас программирует только для веба и мобилок. Но, там уже все уши прожужжали по переходу монолита к микросервисам и обратно. Поэтому, здесь речь не об этом.
В идеале, начальный прототип программы может содержать десятки и даже сотни пустых классов – заглушек. Работе первоначальному приложению они не мешают, но, если есть уже готовая база реальных модулей для замещения формальных классов «настоящими», то, можно подключая и отключая эти модули к конкретному приложению, быстро получать любую программу с заданными характеристиками (естественно, в определенных пределах).
Поэтому, чтобы «учиться» архитектуре в программировании, нужно просто взять готовый опенсорсный проект и пересоздать его (с улучшением), например, с учетом изложенных идей либо аналогичных.
Ну, или как вариант, учиться говорить «вообще» и «ни о чём», как, скажем, некоторые политики.
При этом важно принять, что не каждая организация может предоставить такую возможность.
А, зачем для этого нужна «организация»? Если востребовано «ехать», а не «шашечки», то освоиться в этом деле можно и самостоятельно.
P.S, А так, готовлю статью на тему архитектуры собственной программы.
Ваш комментарий не опровергает ни одного тезиса статьи и не вступает с ней в диалог: он отвечает на другой вопрос (как организовать написание кода) и в другой плоскости (ваши зависимости, ваши приоритеты и ваша ответственность). Это не масштабируется и едва ли является архитектурой – скорее, сталинско-ежовским подходом к дизайну приложений.
Ваш комментарий не опровергает ни одного тезиса статьи
А разве я опровергал, хоть какой-то ваш тезис? Формулировки в стиле «вообще» невозможно опровергнуть, в принципе. Я просто предлагаю давать больше конкретики в статьях, причем, не только в вашей.
Это не масштабируется
Почему? Главная идея у меня – это модульность в С++ проектах. Разве она не работает? Другое дело, что вариации на эту тему могу быть различными. Например, в виде плагинов (статических или динамических, у меня даже статья на эту тему есть, здесь) или тех же системных классов, реализуемых, как в самом языке, так и в его фреймворках, вроде, WTL, MFC, Win32++, DuiLib, wxWidgets, Qt и огромного множества других.
Тот же Qt – куда уж масштабней и «кросплаформее»?
Везде рулит иерархия классов. Просто, для моих пет-проектов, нет нужды «стрелять из пушки по воробьям». Но, понятие «архитектура» к ним применить можно. Хорошо, если вы не согласны, могу предложить вариант: «микро-архитектура». Меня не убудет, а вам будет приятно :) .
скорее, сталинско-ежовским подходом к дизайну приложений
Вы меня порадовали! Это, примерно, как в стиле зданий МИДа или МГУ, в Москве? Да и метро, там же, тоже сделано со «сталинско-ежовским подходом к дизайну». Вы это имели в виду? Т.е., спроектировано капитально, монументально, на века. Я вас правильно понимаю? Просто, не могу поверить, что напросился на такой комплимент! Ей Богу! Я его не заслужил :) . Но, всё равно, приятно. Спасибо!
Статья вообще не про это была. Архитектор ВЫШЕ всяких WTL и плагинов из 90х. Первый вопрос который бы он решил - выбор самой технологии (и кажется WTL с плюсами тут вообще мимо в 2026) но даже если нужно тянуть легаси на этом, его ответственность - координация команд, учёт ограничений и все в таком духе. Чтобы этот монстр не развалился хотя бы ))
Статья вообще не про это была. Архитектор ВЫШЕ всяких WTL и плагинов из 90х.
Верю! Стратег всегда выше тактика. Примерно, как в анекдоте: «Сова: Ёжики – станьте птицами! – Ура! А как? – Отстаньте, глупые! Я не тактик, я стратег!».
Только я говорил, не столько про WTL, сколько про пример организации модульной структуры в С++ проекте. Естественно, что конкретные примеры всегда специфичны. Но, еще в старых сказках учили видеть за деревьями – лес. Для потенциального архитектора, это, как бы, тоже полезно.
Мы, вообще, очень легки на подъём, в смысле, на обобщения. Никакой конкретной базы нет, зато, сходу – стратегические выводы, которые лепятся как горячие пирожки, благо, их трудно не только обосновать (в силу отсутствия конкретики), но и опровергнуть.
Первый вопрос который бы он решил - выбор самой технологии (и кажется WTL с плюсами тут вообще мимо в 2026)
Насколько я вижу по Хабру, «в 2026» рулит только веб-программирование, мобильные приложения и ИИ-шный вайбинг / промтинг. Я уже и забыл, когда видел здесь реальную разработку на приплюснутых проектах. Может быть, вам стоило бы сказать, что и сам С++, в чистом виде, «вообще мимо в 2026»? Хотя, примерно вы так и говорите, я просто уточняю. Питон, он, судя по рейтингам, на первом месте. Но здесь, скорее, увидишь его километровые листинги, чем реально решаемые задачи. Зато, не «мимо»!
С другой стороны, что мешает вам показать реальную работу архитектора на примере разработки, скажем, мобильного приложения, с демонстрацией, как именно работают описанные здесь принципы? Хотя, мне эта тема не интересна, но статью я бы почитал.
но даже если нужно тянуть легаси на этом, его ответственность - координация команд, учёт ограничений и все в таком духе.
Какой легаси? Это собственный пет-проект. Ему не нужны мегатонные фреймворки. Нужно, что-то очень лёгкое. Вопрос, скорее, в другом. Имеет ли право условный программист Вася Пупкин использовать в своих пет-проектах минималистские фрейворки, пусть и старые, но вполне работающие «лошадки»? Или он обязан следовать моде и применять только Qt и иже с ним?
Чтобы этот монстр не развалился хотя бы ))
Монстр – это Qt, на десятки и сотни мегабайт! WTL – это менее полутора мегабайт (!) в исходных текстах. Классы там организованы профессионально и капитально. За много лет работы, у меня ни разу не возникло желание сделать рефакторинг исходников. Да и необходимости в развитии их я не вижу, для своего класса задач – он идеален. А для других задач можно взять другие инструменты, кто против? Главное, не считать, что: «Есть только два мнения, моё и неправильное!».
Пример из жизни – «1С». «Семерка» («1С77») меня кормила двадцать лет. Всё было очень «дешево и сердито», особенно, если использовать её с умом (что многие просто не умеют). А вот дорогая и монстроуозная «восьмерка» («1С8х») не взлетела, именно из-за своей дороговизны и сложности работы (работать на ней должен был не только я, а и обычные тёти-бухгалтера, причем, на вполне себе обычном предприятии, где не любят сорить деньгами и работать на голом «энзазизьме»).
Или это, классическое, «другое»? Т.е., любители «вообще», просто, не любят любителей «конкретного».
C++ в 2026 никуда не делось и не денется, так как занимают нишу высокопроизводительных решений с максимальной утилизацией железа. Увы, UI на них остается нужен в узком ряду приложений: приборы, топовые игры, какие-то симуляции.
WTL - это просто обертка над WinAPI, главная проблема - все прибито к винде. И это бы архитектор и должен учесть? "Все развалится" - это буквально, ваша чудесная кодовая база на WTL, не заведется на "отечественной ОС" (я знаю про wine, да) и весь бизнес может накрыться.
p.s. Я сам фанат плюсов и десктопного софта, у меня в статьях есть описание UI либки, то же WTL, только не на 98х, а на 17/23х плюсах и кроссплатформенное еще )
WTL - это просто обертка над WinAPI, главная проблема - все прибито к винде.
Меня это, как автора пет-проекта, должно смущать? Кроссплатформенные приложения – это удел фирм, конкуренцию им я составлять не собираюсь.
Для моих целей – это идеальный вариант. Я, вот, не раз писал, что на работе использовал, нестандартным образом, «1С77» (DDE + движок VFP + внешние компоненты на C++ / WTL + собственный драйвер для собственной системы учета рабочего времени). Это решало все проблемы предприятия и мои личные двадцать лет (пока фирму не ликвидировали по политическим мотивам). Мой друг программист использовал в своей учетной системе MS Access-97 + MS SQL, в разных версиях, и стал вполне успешен в жизни. Ну, и зачем нам гнаться за понтами?
И это бы архитектор и должен учесть?
Что мешает «увидеть за деревьями лес»? Я лично просмотрел много опенсорса на С++ и нигде не увидел использования аналога микросервисной архитектуры, которую так любят в вебе. В «плюсах» это могла бы быть микромодульная архитектура для микромонолитов. Связь между ними либо через виртуальные интерфейсы (см. мою статью на эту тему в https://habr.com/ru/articles/566864/ ), либо, как я предлагаю, посредством формальных реализаций модулей, т.е. автономных классов без приватных секций, с пустыми телами и ничего не возвращающих (за исключением стандартных обработчиков событий, в теле которых только «return 0» либо «return FAlSE»).
Как показывают эксперименты, эта тема достаточно интересна сама по себе, без привязки к конкретному приложению. Просто, моя обучающая программа может служить хорошим «подопытным кроликом» для демонстрации микроархитектурного подхода в разработке и рефакторинге проектов на С++. Ибо в ней, я себе чуть мозги не сломал, пока не добился её, более-менее, рабочего состояния.
Народу может быть интересна, здесь, демонстрация идей, а мне – возможность получить её вторую версию.
А вы «предлагаете» мне всё бросить и заниматься проектами на Qt, так как они будут кроссплатформенными. По крайней мере, я вас так понял. Вы считаете, что ваши аргументы меня убедят?
"Все развалится" - это буквально, ваша чудесная кодовая база на WTL, не заведется на "отечественной ОС" (я знаю про wine, да) и весь бизнес может накрыться.
Нет никакого бизнеса, и вряд ли будет. Теоретически, я допускаю, что кто-то, прикола ради, скинет несколько рублей на донаты, но, естественно, это не может служить основным стимулом для саморазвития. Максимум, материальным аналогом «спасибо» («мне, что я есть у вас» :) ).
Откровенно говоря, с Линуксом я вообще не знаком. Мне надо было давать его в студенческие времена, когда я тянулся к консоли и командной строке. И искренне недоумевал, зачем идти на поводу у пользователей, далеких от программирования и давать им «глупую» графику вместо крутой командной строки?
Сейчас, время ушло. Как говориться, я уже в том возрасте, когда можно говорить, что я уже не в том возрасте. На оставшуюся жизнь мне вполне хватит «форточек» и любимого C++/WTL плюс Питон для обработки данных. И зачем мне Альт-Линкс и иже с ним? Если бы на моей любимой работе предложили им заниматься, я бы не отказался, но, на «вольных хлебах» – увольте!
Когда-то архитекторы именно этим и занимались. Это потом появились системы не из одного приложения с базой данных, а как минимум из двух (фронт и бэк), а то и десяти микросервисов. Плюс всякие интеграции и т.д. Тут конечно те же принципы пригождаются, просто надо понимать, что уровень абстракции повыше.
Согласен, что архитектура у локальных приложений и сетевых – разная. Та же «1С». Можно организовать работу по-разному:
– Простой локальный сетевой вариант, на базе файл сервера (не эффективен для больших база и нескольких клиентов).
– УРБД (чуть лучше, но сложнее в разработке и поддерживании).
– На базе веб-сервера (Итернет, интранет и мобильные версии. Очень неплохо, но хороших решений «из коробки» нет, «конфетку» нужно делать самому, с помощью «напильника»).
– Локальная сетевая версия на базе терминал-сервера (идеальный вариант для «малых и средних предприятий»).
Только, я не согласен, что у сетевых приложений «уровень абстракции повыше», чем у локальных. Он не выше, он просто «другой». Соответственно, рассматривать его нужно отдельно.
Главное здесь то, что хорошей практической (а не абстрактно-теоретической) организации проектов, на уровне архитектуры, нет ни для того, ни для другого варианта. Я собираюсь говорить о микро-архитекторе собственного локального пет-проекта. Мне, как бы, намекают: «Не надо, поскольку, это не сетевой фронтбэк.». Ну, прям, как в анекдоте: «Чукча приехал на экскурсию в Москву. Экскурсовод: – Вот, памятник Достоевскому! Чукча: – Это тот, кто «Муму» написал? – Нет, что вы! «Муму» написал Тургенев. … – Странно, написал Тургенев, а памятник – Достоевскому!».
Почему нельзя делать две работы сразу? Я говорю о «локалке», вы о «сетевухе». Или чем «чтобы не было богатых» лучше «чтобы не было бедных»?
Спасибо за статью, тема действительно актуальна. На мой взгляд, в начале не хватает одной важной вещи - определений: что понимается под "архитектурой" и, соответственно, под "архитектором". Судя по контексту, если я правильно понял, в статье речь либо про solution, либо про системного архитектора (а может это агрегированная роль, как часто бывает), и возможно, именно в этой области справедлив указанный подход с переходом из роли аналитика (вероятно в таком случае, системного), в архитекторы. Но видов архитекторов больше, если раскладывать предметные области по TOGАF, например: корпоративные, бизнес, данных, инфраструктуры, ИБ + в отечественных профстандартах встречаются и другие (архитектор ПО, например, и процессный архитектор). Рост специалистов из области аналитики до многих из этих ролей является логичным с учётом изменения уровня абстракции, инструментов, единой архитектурной среды (репозитория), уровня процесса управления требованиями и т.п.
ну это в общем как рост из разработчика в тимлида, вроде всё тоже самое, но теперь ответственность...
Главное, чтобы к этой ответственности, прилагались полномочия )) Как-то так получается что зачастую архитектор - это CTO...
Ну да, мало дать человеку должность и навесить обязанности, надо ещё полномочия.
На прошлом проекте было такое, что под нормально зафиксированные проработанные требования, СТО сначала дал разработчика, но задачу сформулировал по своему, а потом когда указали на необходимость изменения разработанного решения под изначально поставленную задачу, просто не дал разработчика.
На самом деле системный аналитик также работает со всякими нефункциональными требованиями (интеграции, ограничения, атрибуты качества). Просто когда ты на низовом уровне ответственности, часть этих требований тебе спускает архитектор. Когда нет архитектора, сам прорабатываешь. И да, часто в статьях про аналитиков, требования, методологии авторы забывают, что у каждого проекта разработки/внедрения есть такое серьезное ограничение, как бюджет. Как только мы это ограничение вносим в виде требования в сферу ответственности аналитика, он становится архитектором.
Архитектор — это не прокачанный аналитик: калибровка перед переходом