Мне было интересно узнать мнение профессионального сообщества по данному вопросу. Поэтому я провёл исследование на тему: «Насколько системный аналитик уровня Senior должен разбираться в программном коде?».

Опрос проводился среди целевой аудитории - системных аналитиков, чтобы выяснить, как они сами оценивают требования к своим знаниям в области программирования. Участие в опросе приняли представители как открытых Telegram-каналов, посвящённых системному анализу, так и закрытых групп аналитиков нескольких крупных российских финтех-компаний.

В общей сложности проголосовало 196 человек. Ниже приведены агрегированные результаты всех опросов.

---

Насколько системный аналитик уровня Senior должен разбираться в программном коде?

В опросе приняли участие 196 человек. Разрешалось выбирать несколько вариантов ответа.

Рассмотрим каждый вариант ответа и проанализируем, что он говорит об отрасли, как влияет на практику системных аналитиков и какие выводы можно сделать для их подготовки.

---

1. Навык работы с кодом не является стандартным требованием для профессии системного аналитика

Примерно половина системных аналитиков не считают, что обязаны разбираться в исходном коде. Многие в комментариях отмечали, что не хватает вариантов вроде "читаю со словарём" или "понимаю с помощью ChatGPT".

После общения с коллегами стало ясно. Дело не в том, что они категорически против просматривать код и пытаться его понять. Скорее, голосуя за этот пункт, они имели в виду, что не обязаны читать любой код. Если требуется анализ конкретного фрагмента, они готовы это делать, но при условии, что в поддержку будет выделен программист, и они разберутся вместе.

Фактически, каждый второй системный аналитик считает, что умение читать код - это скорее бонус, чем стандарт профессии. Такой навык воспринимается как overkill: хорошо бы уметь, но это необязательное требование.

Важно отметить, что это мнение самих представителей профессии о своей работе. И любопытно, что эта доля составляет не 80%, а лишь немного меньше 50%. Это говорит о том, что оставшаяся часть респондентов, т.е. почти половина считает иначе. А именно, что Senior-системный аналитик должен глубже разбираться в программировании, чтобы эффективнее поддерживать разработку и качественно документировать процессы.

---

2. Должен понимать суть кода на любом языке, даже при не интуитивных названиях методов и атрибутов

При формулировке этого варианта ответа я специально постарался уточнить, что речь идёт именно о понимании программного кода, а не английского языка. В разговоре с системными аналитиками, которые утверждали, что "читают код", я заметил интересную особенность. Под этим часто подразумевается чтение англоязычных ключевых слов и попытка угадать общий смысл на их основе.

Однако при столкновении с неочевидными конструкциями языка программирования, нестандартными названиями классов, методов или переменных, понимание резко падает. То есть знание английского языка ≠ понимание кода, несмотря на то, что большинство синтаксических элементов действительно написаны на английском.

Пообщавшись с коллегами, выбравшими данный вариант в опросе, я понял, что, возможно, сформулировал его недостаточно чётко. Многие из коллег имели в виду, что могут открыть код, пробежаться по нему и примерно уловить суть, но не вдаются в детали. Когда они сталкиваются с непонятными моментами, то, как правило, обращаются за помощью к разработчикам, смотрят документацию или используют инструменты ИИ, такие как ChatGPT.

Что можно извлечь из этих ответов? Senior-позиция системного аналитика предполагает не только владение теорией и методологией анализа, но и готовность глубже погружаться в технические детали, включая чтение и понимание кода. Это не означает, что аналитик должен быть профессиональным разработчиком, но базовое понимание логики работы программных компонентов становится важным для эффективной коммуникации с командой и повышения качества аналитической документации.

Возможно, именно этот пункт и определяет тот самый порог, который отделяет Middle+ аналитика от грейда Senior. Middle - это уже специалист с прокачанными hard- и soft-скиллами, которому, казалось бы, осталось совсем немного практики, чтобы перейти на следующий уровень. Но зачастую у таких специалистов уже есть достаточный практический опыт. Они участвовали в проектировании систем, описывали сервисы, составляли документацию. Тогда возникает вопрос - какой практики им не хватает?

Не могу утверждать наверняка, но, возможно, умение читать и понимать код - это как раз та недостающая "капля", которая и делает аналитика Senior-уровня. Если аналитик спокойно открывает код и понимает, что происходит под капотом, - это может стать важным аргументом в его пользу при оценке зрелости.

А как считаете вы? Коллеги-аналитики, если вы голосовали - напишите в комментариях, что вы имели в виду, выбирая (или не выбирая) этот вариант ответа. Коллеги-разработчики, как вы относитесь к умению системного аналитика понимать код? Это must-have или, на ваш взгляд, без опыта разработки это всё равно почти невозможно?

---

3. Уметь полноценно использовать IDE для изучения логики работы кода

Современная разработка кода значительно упрощается благодаря использованию IDE (Integrated Development Environment - интегрированная среда разработки). Такие программы позволяют разработчикам редактировать, компилировать и интерпретировать код, отлаживать его, автоматизировать сборку проекта, а также управлять структурой проекта (файлами, папками, GIT-репозиториями) в едином интерфейсе.

Должен ли системный аналитик уметь пользоваться IDE? Почти каждый четвёртый аналитик считает, что да. Это довольно любопытный результат, особенно если сопоставить его с предыдущим ответом про необходимость умения читать код. См. график выше в данном разделе.

Использование IDE становится актуальным, когда необходимо работать с полноценным исходным кодом: скачивать проект, быстро ориентироваться в структуре, искать фрагменты кода, переходить к определениям методов и отслеживать места их вызова. То есть - выполнять глубокий анализ кода, а не просто просматривать его в веб-интерфейсе репозитория.

Если каждый второй аналитик считает, что системному аналитику нужно уметь читать код, а каждый четвёртый - что нужно уметь пользоваться IDE, это позволяет сделать важный вывод: часть аналитиков ограничивается базовым ознакомлением с кодом (например, прямо в GitLab, GitHub или Bitbucket), а другая часть погружается значительно глубже, вплоть до полноценного анализа в IDE.

Выходит, что половина тех, кто умеет читать код, делает это на уровне разработчика - в среде разработки. Это серьёзная цифра: 27% от всех участников опроса.

Возможно, компаниям стоит учитывать это при планировании инфраструктурных затрат и предусматривать лицензии на IDE не только для разработчиков, но и для системных аналитиков.

А самим аналитикам, особенно если в компании практикуется подход First Code, стоит уделить время изучению особенностей IDE, соответствующих языкам программирования, с которыми они работают.

---

4. Уверенно владеть GIT, включая коммиты, ветвление, слияние и разрешение конфликтов

Этот пункт логично вытекает из предыдущего. Если у системного аналитика на компьютере установлены IDE и исходный код проекта, возникает вопрос - как он получает этот код? Да, его можно скачать архивом и распаковать вручную, но правильный и профессиональный подход - это использование GIT, который позволяет загружать различные ветки, отслеживать изменения и синхронизироваться с актуальной версией проекта.

Использование GIT - стандартная практика для разработчиков. Это навык, о котором их регулярно спрашивают на собеседованиях, и с которым они работают каждый день. Однако среди системных аналитиков знание GIT встречается заметно реже. Тем не менее, 22% аналитиков в опросе указали, что, по их мнению, владение этим инструментом необходимо.

Всё зависит от контекста проекта. Если команда больше ориентирована на бизнес-задачи и не использует CI/CD, то, как правило, хватает классических инструментов документации, например Confluence. Но когда документация тесно связана с кодовой базой и инженерными практиками, становится актуален комбинированный подход. В таких случаях документация в Git выигрывает в управляемости, версиируемости и возможностях автоматизации. В то время как Confluence используется как более гибкий инструмент для создания высокоуровневой, "живой" документации, ориентированной на бизнес-пользователей.

Связать два этих мира (Confluence и Git) можно, например, следующим образом: в Confluence создать раздел "Системная документация (Git)" со ссылками на опубликованные версии документов из Git-репозитория, а в Git-документации, например в README-файлах, разместить ссылки на соответствующие разделы в Confluence.

Дополнительно, при необходимости, можно использовать Confluence API или специальные плагины для автоматического импорта информации из репозитория и актуализации содержимого в Confluence.

Что это говорит нам о профессии системного аналитика? Более чем каждый пятый системный аналитик считает, что необходимо владеть GIT. И речь идёт не просто о базовых командах вроде git pull и git push. Подразумевается умение работать с ветками, делать коммиты, выполнять слияние (merge), разрешать конфликты (resolve conflicts), а в некоторых случаях - даже использовать более продвинутые функции, такие как stash, rebase и другие.

Например, в нашей программе подготовки аналитиков от вендора GIT вообще не входит в учебный план. Аналитики с опытом в разработке обычно обладают этими навыками, но остальные, как правило, оказываются к такому вызову не готовы.

Поэтому, возможно, стоит задуматься о том, чтобы ввести обучение работе с GIT в подготовку аналитиков уровня Middle и Senior, чтобы повысить их соответствие требованиям современного рынка и уровня взаимодействия с техническими командами.

---

5. Глубоко понимать принципы ООП, включая особенности наследования и его ограничения

Этот вариант ответа возник из реальной ситуации. В одной крупной российской финтех-организации сложилась практика, при которой доменную модель разрабатывают системные аналитики.

Что такое доменная модель? Это описание ключевых сущностей (объектов), их свойств и взаимосвязей. Обычно она оформляется в виде классов или представляется в виде UML-диаграммы классов. Задача системного аналитика при создании доменной модели - описать "что есть и как это связано", а не "как будет работать код".

Для качественного построения такой модели необходимо глубокое понимание принципов объектно-ориентированного программирования (ООП) - таких как абстракция, инкапсуляция, наследование. Причём важно знать их не поверхностно, а понимать, например, нюансы множественного наследования и другие особенности ООП, которые могут повлиять на логику и архитектуру системы.

Проблема множественного наследования возникает тогда, когда класс наследуется от двух или более базовых классов, и эти базовые классы содержат одинаковые методы или атрибуты. Это может привести к конфликтам, неоднозначности в поведении и сложности в определении, какая именно реализация должна быть использована. Такая ситуация требует особого внимания при проектировании.

В разных языках программирования эта проблема решается по-разному:

• Java и C# полностью запрещают множественное наследование классов. Вместо этого они позволяют реализовывать множественные интерфейсы, что устраняет потенциальные конфликты, поскольку интерфейсы не содержат реализаций (до появления default-методов в Java 8, но и они проектируются с оглядкой на эту проблему).

• В Go нет наследования как такового - ни одиночного, ни множественного. Вместо этого язык делает ставку на композицию и интерфейсы, что позволяет создавать гибкие и безопасные архитектуры без использования наследования.

• В PHP прямое множественное наследование также запрещено. Нельзя унаследоваться от нескольких классов, однако язык предлагает альтернативы - через интерфейсы и трейты (traits).

• В C++ множественное наследование поддерживается, но требует очень осторожного проектирования. Для управления конфликтами и устранения проблемы так называемого «алмаза смерти» (Diamond Problem) используется ключевое слово virtual. Эта проблема возникает, когда класс наследуется от двух классов, которые, в свою очередь, наследуются от одного общего предка. Без правильной структуры это может привести к дублированию, конфликту версий методов или непредсказуемому поведению.

• В React (на JavaScript или TypeScript) множественное наследование не используется. Архитектура React изначально ориентирована на композицию, а не наследование. Повторное использование логики достигается через хуки (hooks) и композицию компонентов, что делает структуру гибкой и хорошо масштабируемой.

20,9% системных аналитиков проголосовали за то, что специалист уровня Senior должен разбираться в ООП, а значит - понимать принципы работы с классами, объектами, интерфейсами, наследованием, модификаторами доступа и другими ключевыми концепциями объектно-ориентированного программирования.

Что я наблюдал на практике? В одной из компаний, где описание доменной модели стало стандартом де-факто, значительно повысился порог входа в профессию. Это привело к высокой текучке среди системных аналитиков - люди приходили и уходили, зачастую не задерживаясь даже на две недели.

Из-за нехватки специалистов начались сбои в процессе документирования. Постепенно команда перешла к подходу First Code, когда документации перестали доверять, считая её потенциально устаревшей, и всю информацию приходилось перепроверять по коду. У тех аналитиков, кто справлялся с работой, из-за нехватки "коллег по цеху" просто не оставалось времени на полноценное описание систем. В итоге отказались от документирования таблиц баз данных, перестали строить ER-диаграммы, так как "всё равно проще зайти в БД и посмотреть".

Информация о том, как работает система, стала передаваться устно - буквально из уст в уста, как легенды или сказания, - вместо того чтобы оформляться в виде понятной, актуальной документации.

Это была любопытная ситуация, и мне стало интересно, как такое вообще могло произойти. Мне рассказали, что однажды на проекте сложилась обратная картина: команда аналитиков была сильной, а разработчики - менее опытными. В результате аналитики начали описывать дополнительно и доменную модель, чтобы облегчить разработке понимание предметной области. Со временем этот подход прижился и стал "стандартом", поскольку оказался удобным для программистов, но гораздо более сложным для новых аналитиков.

У любого подхода есть свои плюсы и минусы. В рассматриваемом случае, помимо высокой текучки кадров и повышенного порога входа для новых аналитиков, возникла ещё одна серьёзная проблема - практически полностью перестали документироваться данные и структура их хранения.

Хотя в базе данных можно увидеть таблицы и колонки, а также их типы, из-за пробелов в документации непонятно назначение этих колонок. Особенно серьёзно обстоят дела с индексами - эта часть, находящаяся в зоне ответственности системного аналитика, зачастую вовсе игнорируется. На мой взгляд, доменная модель - это полезный инструмент, если он действительно необходим, но он должен дополнять документацию, а не заменять собой описание структуры базы данных.

Если почти каждый пятый системный аналитик считает, что специалист уровня Senior должен полноценно разбираться в ООП, то, возможно, стоит уделить этому отдельное внимание в программах подготовки аналитиков. А также - включить соответствующие вопросы в процесс собеседований, по аналогии с тем, как это делается при оценке разработчиков.

Насколько это реализуемо - отдельный вопрос. У нас, например, как у вендора, проходит большое количество собеседований. Меня приглашают только на этапы, где оцениваются кандидаты на позиции Senior системных аналитиков, чтобы понять глубину их технических знаний. На практике оказалось, что даже базовые принципы ООП известны далеко не всем. Скорее всего, те аналитики, которые проголосовали за необходимость знания ООП, изучали его самостоятельно.

Коллеги, если вы были среди тех, кто выбрал этот вариант в опросе - расскажите, пожалуйста, каким был ваш путь в изучении ООП и насколько активно вы применяете его в своей работе?

---

6. Разбираться в уровнях изоляции транзакций, включая грязное, неповторяющееся и фантомное чтение

Это действительно интересная тема, особенно учитывая, что разработчиков на собеседованиях часто "гоняют" по ней довольно жёстко.

Транзакция - это набор операций, которые либо все выполняются успешно, либо не выполняются вовсе, если возникает ошибка. Например, при переводе денег с одной карты на другую: средства сначала списываются с одного счёта, а затем зачисляются на счёт получателя. Если первая операция прошла успешно, а вторая - нет, деньги могут "исчезнуть". Чтобы этого не произошло, обе операции должны быть объединены в одну транзакцию - тогда система обеспечит их совместное выполнение или полный откат в случае сбоя.

Транзакции подчиняются так называемым ACID-принципам:

• Атомарность - либо выполняются все операции, либо ни одна;

• Согласованность - данные остаются в корректном, допустимом состоянии;

• Изолированность - параллельные транзакции не влияют друг на друга;

• Надёжность (устойчивость, durability) - если транзакция завершилась успешно, изменения сохраняются навсегда, даже при сбоях.

И это лишь основа. У транзакций есть также уровни изоляции, которые определяют, насколько одна транзакция может "видеть" изменения, производимые другой, пока они ещё не завершены. Эти уровни влияют на поведение системы при параллельной работе с одними и теми же данными и играют критическую роль в обеспечении целостности и предсказуемости операций.

Системные аналитики, как правило, не изучают подробно уровни изоляции, особенно если не сталкиваются с ними в проектной практике.

Но зачем тогда вообще знать об этом аналитику?

Дело в том, что уровень изоляции - это всегда компромисс между надёжностью и производительностью. И если аналитик участвует в проектировании критически важных бизнес-процессов, знание этих основ помогает принимать более осознанные архитектурные решения.

Рассмотрим простой пример. Вы проектируете интернет-магазин и "по привычке" применяете уровень изоляции Serializable для всех операций - чтения товаров, заказов, корзин. В этом случае пользователи начинают ждать друг друга, потому что операции выполняются строго последовательно. Это приводит к задержкам, блокировкам и падению производительности.

Но если для бизнеса допустима ситуация, когда пользователь может видеть список товаров, даже если они редактируются кем-то другим (но не видеть неподтверждённые изменения), то логично использовать уровень изоляции Read Committed вместо Serializable. Это позволит ускорить работу системы, не жертвуя консистентностью данных с точки зрения бизнес-логики.

Но и это далеко не всё, что стоит знать о транзакциях. Например, существует такая конструкция, как SELECT FOR UPDATE, которая позволяет явно заблокировать строки на чтение с последующим изменением, предотвращая гонки при параллельных операциях.

В целом, уровни изоляции - это гибкий инструмент контроля параллельного доступа к данным, который позволяет балансировать между производительностью и надёжностью.

Интересно, что 16,8% участников опроса считают, что системному аналитику важно понимать, как параллельность может повлиять на корректность бизнес-логики. Это знание позволяет формулировать требования более точно, снижает вероятность появления скрытых ошибок и помогает выстраивать согласованную работу с архитекторами и администраторами баз данных (DBA).

---

7. Уметь распознавать паттерны программирования: Singleton, Factory, Strategy, Repository, MVC и др.

Системные аналитики уровня Senior, как правило, изучают паттерны микросервисной архитектуры - такие как API Gateway, Strangler, Saga, BFF, CQRS, Event-Driven Architecture (EDA) и другие. Эти устоявшиеся архитектурные практики помогают им лучше понимать технические решения команды, корректно описывать бизнес-процессы в условиях распределённых систем, а также учитывать ограничения, связанные с отказоустойчивостью, консистентностью и временем отклика.

Однако то, чему системных аналитиков чаще всего не учат, - это паттерны программирования. Между тем, более чем каждый десятый участник опроса считает, что аналитик уровня Senior должен разбираться и в них.

Если, например, тимлид разработки говорит, что между доменной моделью и базой данных используется паттерн Repository, системный аналитик должен понимать, о чём речь, зачем этот паттерн применяется и как он влияет на архитектуру системы.

Таким образом, системный аналитик не обязан уметь программировать, но должен говорить с разработчиками на одном языке, особенно при обсуждении архитектурных решений. Важно не путать понятия, такие как Service и Repository, Entity и DTO, Controller и Handler.

Кроме того, для грамотного проектирования систем аналитик должен понимать границы ответственности в архитектуре: где проходит граница между UI, бизнес-логикой и слоем хранения данных.

Похоже, современные команды - особенно в продуктовой разработке, финтехе и e-commerce - всё чаще ожидают от системных аналитиков технической грамотности. В вакансиях всё чаще встречаются требования вроде: «понимание архитектурных паттернов», «опыт с DDD», «знание REST, MVC и слоистой архитектуры».

Цифра в 12,8% голосов - это, конечно, пока не отраслевой стандарт и не "обязательный минимум". Но это сигнал: знание паттернов становится способом выделиться среди коллег. Это даёт конкурентное преимущество на рынке труда.

Junior-аналитику ещё допустимо "плавать" в этих темах, но от Senior-специалиста всё чаще ожидается ориентированность в архитектурных решениях и способность обсуждать технические аспекты на равных с разработкой.

---

8. Чётко понимать роли контроллеров, middleware, моделей, view, репозиториев, DI и др. компонентов

18,9% системных аналитиков проголосовали за то, что при системном анализе необходимо чётко понимать роли контроллеров, middleware, моделей, представлений (view), репозиториев, внедрения зависимостей (DI) и других компонентов.

Сегодня от системного аналитика всё чаще ожидают не только понимания бизнес-процессов, но и уверенной ориентации в технической стороне разработки. Особенно это актуально в проектах, где применяется современная архитектура с контроллерами, слоями моделей, репозиториями и механизмами внедрения зависимостей. Это не означает, что аналитик должен уметь программировать. Но он должен понимать, какую роль выполняет каждый компонент и как данные проходят через систему.

Такие знания помогают не просто "собирать требования", а говорить с разработчиками на одном языке. Когда аналитик понимает, где заканчивается view и начинается бизнес-логика, где хранится состояние и как взаимодействуют сервисы, это ускоряет работу всей команды. Задачи формулируются точнее, возникает меньше недопонимания, и новые фичи появляются быстрее.

Пока всё это не зафиксировано в профессиональных стандартах системных аналитиков. Но, как видно по результатам голосования, многие уже считают эти знания важными. Работодатели тоже всё чаще включают техническую компетентность в требования к аналитикам, особенно на уровнях middle и senior.

Если системный аналитик хочет развиваться, быть полезным команде и участвовать в архитектурных обсуждениях, без базовых технических знаний может быть сложно. Придётся тратить больше времени на уточнение задач, задавать архитекторам вопросы по основам и дольше разбираться в причинах багов. Поэтому разбираться в устройстве приложения изнутри - это не про "умничание", а про профессиональную эффективность.

---

9. Понимать особенности ORM, миграций, seed-данных и их взаимодействия с базой данных

Object-Relational Mapping (ORM) - это способ работы с базой данных через объекты, а не напрямую с помощью SQL-запросов. Такой подход ускоряет разработку, но также накладывает определённые ограничения.

Миграции - это механизм изменения структуры базы данных: например, добавления колонок, создания новых таблиц и других операций.

Сид-данные - это заранее подготовленные значения, которые автоматически заполняют базу по умолчанию. Чаще всего это справочники, роли, тестовые пользователи и другие предопределённые элементы.

16,8% аналитиков уже считают, что понимание этих процессов - важно. Это не означает, что системный аналитик должен самостоятельно писать миграции. Но важно представлять, как устроен процесс: любое изменение структуры базы - это не просто "добавить поле в ТЗ", а полноценная техническая операция, связанная с кодом, временем, тестированием и возможными откатами.

Если, например, вы предлагаете новое обязательное поле, но не продумываете, как его заполнить в уже существующих данных, разработка может остановиться. На практике знание таких нюансов экономит время, повышает точность требований и укрепляет доверие между аналитиком и командой разработки.

Если же не понимать, как работает база "изнутри", велика вероятность предложить нереализуемую бизнес-логику, забыть про ключи или нарушить целостность данных при миграции.

Сегодня системный аналитик, который понимает, как устроена база данных и как с ней работает код, - это уже не редкость, а реальная ценность для команды.

---

10. Должен задавать для программиста имена классам, методам, атрибутам и описывать реализацию кода

Это был последний пункт опроса, и он также возник из реального кейса.

В одной крупной корпорации возникла ситуация: команда разработки настаивала, чтобы системный аналитик, при работе с Camunda в рамках бизнес-процессинга, указывал в паспорте процесса имена классов, методов и переменных. Причём аналитик не просто документировал эти названия, а сам их задавал ещё на этапе подготовки технического задания.

В качестве аргумента разработчики привели в пример ТЗ коллег из другой команды. Анализ ситуации показал, что один из системных аналитиков раньше был Java-разработчиком. Именно он однажды составил паспорт процесса "по привычке" - сразу с конкретными именами сущностей. Это понравилось разработчикам, и когда один из них перешёл в другую команду, он начал продвигать такой формат как "эталонный". При этом в компании не существовало утверждённого шаблона документа для описания бизнес-процессов, и подход был стихийным.

После опроса других системных аналитиков стало ясно, что большинство ограничиваются описанием бизнес-логики, а конкретные имена переменных, методов или классов указывают только в случаях, когда это необходимо, либо по просьбе разработчиков - например, чтобы зафиксировать важные элементы интерфейса для "будущих поколений".

Это, тем не менее, отражает интересную тенденцию.

13,3% системных аналитиков считают, что им следует в явном виде указывать имена классов, методов и переменных в своих документах. На первый взгляд может показаться, что это - зона ответственности разработчиков. И действительно, в классических подходах именно они определяют названия в коде. Но практика показывает, что в современных проектах всё не так однозначно.

Особенно в условиях быстрой итеративной разработки и микросервисной архитектуры, чёткие и согласованные наименования становятся важным фактором взаимопонимания между аналитиком и разработкой. Если аналитик заранее прописывает понятные имена (например, User, createOrder(), order_id), это помогает разработчикам быстрее реализовать логику, минимизировать расхождения между документацией и кодом, и в целом - ускоряет процесс с меньшим количеством ошибок.

Однако, если аналитик берёт на себя такую роль, важно не просто придумывать "какие-то" названия, а знать и применять принятые соглашения по наименованию. Это критично для поддерживаемости и читаемости кода. Например:

• camelCase используется для переменных и методов
  (userName, getOrderStatus());

• PascalCase - для классов, интерфейсов и компонентов
  (User, OrderService, ProductDTO);

• snake_case - для SQL, конфигурационных файлов и API-параметров
  (user_id, created_at);

• SCREAMING_SNAKE_CASE - для констант
  (MAX_RETRIES, DEFAULT_TIMEOUT).

Также важно соблюдать принципы хорошего нейминга: метод должен звучать как действие (calculatePrice, sendEmail), переменная - как понятное существительное (orderList, emailTemplate), а имя класса - как сущность или роль (Invoice, PaymentProcessor).

На практике это означает, что аналитики с техническим уклоном, которые способны мыслить на уровне кода и архитектурных решений, становятся особенно ценными. Это не является обязанностью для всех, но всё чаще - это конкурентное преимущество: в зарплате, влиянии в команде и качестве продукта.

---

Похоже, что рынок меняется

Опрос показывает любопытную картину: почти половина системных аналитиков (48%) по-прежнему считает, что умение работать с кодом - необязательное требование к профессии.

Однако почти столько же (47,4%) уверены в обратном - что аналитик должен уметь понимать код, даже с "грязными" названиями и написанный на любом языке. Это говорит о том, что профессия находится на пороге трансформации: техническая компетентность перестаёт быть просто "дополнением" и становится всё более востребованным и ожидаемым навыком.

При этом каждый пятый аналитик отметил важность понимания архитектурных компонентов, транзакций, ORM и шаблонов проектирования. Это уже явный сигнал рынку: аналитик нового поколения - это не просто человек, который пишет техническое задание, а полноценный участник архитектурной команды. Он способен участвовать в проектировании, оптимизации и развитии продукта на всех уровнях.

И даже если такими навыками пока владеют не все - это лишь подчёркивает ценность тех специалистов, кто уже вышел за рамки классического подхода к системному анализу.

---

Я веду канал "Системный Архитектор ?‍? Аналитик", где делюсь опытом из реальных проектов, включая зарубежные. Архитектура, системная аналитика, реальные кейсы, факапы, полезные инструменты и рабочие инсайты. Без воды и заумных терминов, а только то, что пригодится на практике. :-)

На Хабре также вышла мои новые статьи. Буду рад, если заглянете!

• "Кто выполняет функции системного аналитика в США?"

• "10 советов, как стать системным архитектором"

---

Выражаю благодарность

Хочу поблагодарить коллег за участие в опросе и помощь в его распространении в профессиональных сообществах и организациях:

• Московская Биржа - https://www.moex.com/

• Банк МКБ - https://mkb.ru/

• Вендор Comm-IT - https://commit.tech/

• Аналитическое сообщество - ссылка на Telegram-пост

• Федерация Аналитиков - ссылка на Telegram-пост