Post #688

ByteByteGo в рассылке подогнал роадмэп развития архитектора ПО. Посмотрим, какие есть пересечения с системными аналитиками. 1. Языки. Выучить парочку языков программирования для бэкенда. Java, Python, Go, JS. Ну, тут мимо. 2. Инструменты. GitHub, Jenkins, Jira, ELK, Sonar. Аналитик из этого знает обычно Jira и может быть GitHub. GitHub — это хранение исходников и версий (тут, думаю, в первую очередь имеется в виду сама идея работы с git: все эти пуллы, пуши, коммиты, ветки и PR. Кстати, если хотите разобраться и потренироваться — есть вот такой клёвый симулятор: https://learngitbranching.js.org/). Jenkins — это конструктор пайплана CI/CD, Sonar (видимо, всё же SonarQube) — анализатор качества кода. ELK — это типовое решение для сбора и анализа логов, состоящее из трех open source решений: Elasticsearch, Logstash и Kibana. Logstash собирает и парсит логи и складывает их в БД Elasticsearch, а Kibana строит визуализации. Elasticsearch — NoSQL база данных и поисковый движок. Если у вас есть интеграции, скорее всего, у вас уже развернут ELK. Что интересно, аналитик практически никогда не пишет требования к сбору логов. Оно само как-то. 3. Принципы проектирования: ООП и паттерны ООП (называются GoF — Gang of Four, Банда Четырех, по четырем авторам); TDD — разработка через тестирование; Clean Code; это всё про программирование и конструкции внутри программы, аналитикам наверное не особо нужно. А вот о чем аналитик должен иметь представление: DDD, ACID, MVC, CAP-теорема. Если вы работаете с интеграциями — вам важнее ACID и CAP (а может и PACELC), если с вебом — MVC хотя бы на уровне концепции. Ну а DDD в любом случае. 4. Архитектурные паттерны: слоистая архитектура, микросервисы, публикация/подписка, клиент-сервер, EDA (событийно-ориентированная), гексагональная архитектура. Тут лучше всё изучить, особенно если вы занимаетесь интеграциями. Кроме, разве что, гексагональной архитектуры. Почему вообще гексагональная и MVC в разные разделы попали, я не очень понимаю. И куда дели Clean Architecture. Кажется, в 3 разделе больше про внутреннюю архитектуру, а тут больше про распределенные. Ну да ладно. Про разные виды архитектур в Systems.Education вот даже книгу перевели: https://systems.education/software-architecture-patterns 5. Платформенные знания. Контейнеры, оркестрация, облака, бессерверная архитектура, CDN, шлюзы, распределенные системы, CI/CD. Хотя бы понимать на уровне названий — что это такое, когда и для чего используется. API-шлюзы и оркестрация — это практически про интеграцию, CDN — про веб. 6. Данные и аналитика. Это тоже очень часто попадает в задачи аналитика. SQL, NoSQL, Kafkа — это всё знакомые слова. Data Streaming, OLAP, Object Storage, Data Migration — менее знакомые, но про миграции я регулярно слышу доклады, кажется это тоже попадает к аналитику. 7. Сети и безопасность. Уровень ниже, чем обычно смотрит аналитик, но, опять же, базовые понятия нужно знать, если вы работаете с интеграциями — например, разные виды обеспечения безопасности и аутентификации. А если вам критичная скорость, то можно и в TCP/IP занырнуть. 8. Дополнительные навыки: технологии, принятие решений, управление стейкхолдерами, коммуникация, оценки, лидерство. Тут, кажется, больше половины про аналитика, а то и все. В целом получается, что системный аналитик — это как будто уже наполовину архитектор. Без знания программирования, без заглядывания в код и без конкретных инфраструктурных инструментов. Сакраментальный вопрос: можно ли всё-таки дорасти до архитектора без опыта промышленного программирования? (Совсем без заглядывания в код и понимания, из чего он состоит, видимо, нет)