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