Напомним, кто мы: компания SSP SOFT занимается заказной разработкой и IT-аутсорсингом. Наши спецы помогают внешним клиентам реализовывать задачи в e-commerce, финтехе, медтехе, управлении инфраструктурой и других отраслях.
Рабочие места в офисах в Москве (отличная локация в ЦАО) и в Томске, а также у нас много сотрудников, которые работают удаленно из разных регионов России. Формат «онлайн» или «оффлайн» обсуждаем.
📢 Кого мы сейчас приглашаем (это описание вакансий в hh, а ниже прямые контакты с нашим HR для быстрого отклика):
Мы ценим сотрудников — работа без лишней бюрократии — только задачи, которые приносят результат и удовлетворение от процесса, участие в реальных проектах, развитие профессиональных навыков.
🎁 Наши бонусы: ДМС со стоматологией, обучение за счет компании, бонусная программа.
👉 В SSP SOFT мы рассматриваем найм не как «закрытие вакансии», а как включение нового человека в команду — с вниманием к развитию и прицелом на долгосрочную совместную работу.
Пишите с резюме нашему HR в Telegram: @sspsoft Или присылайте резюме на почту: job@ssp-soft.com.
Как мы ускорили проверку документации с помощью AI-агента: от боли к решению
Привет, Хабр! Я — Мила Муромцева, системный аналитик в Альфа-Банке. Эту статью мы подготовили вместе с нашим разработчиком Мишей Буториным. Написали ее, чтобы поделиться нашим опытом и рассказать, как мы научили LLM проверять документацию для платформы Альфа-Онлайн — переписывали стандарт, боролись с токенами и немного с хаосом.
Самое ценное — детальное описание того, как команда поборола проблему потери данных при проверке огромных документов LLM. Вместо описания абстрактных алгоритмов кейс строится вокруг настоящей боли и решения, которые можно применить для своих корпоративных задач.
Статья «Как мы ускорили проверку документации с помощью AI-агента: от боли к решению» будет полезна тем, кто автоматизирует проверки, работает с большими данными и хочет, чтобы нейросети давали точные и надёжные ответы — даже при работе с очень громоздкой документацией. Внутри разбираем кейс командной интеграции LLM: от первых ошибок до финального формата отчета, который реально экономит токены и нервы!
🔥 Монолитный фронтенд тормозит ваш проект? Пора задуматься о микрофронтендах!
Если разработка кажется бесконечной, внедрение фич превращается в квест, а код стал клубком из зависимостей — вы не одни. Мы знаем эту боль не понаслышке!
Наш новый вебинар «Архитектурный перелом: что делать, когда фронтенд трещит по швам» — это честный разговор о реальном пути перехода от монолитного фронтенда к микрофронтендам. Никакой воды, только реальный опыт: когда сложность системы достигла критической точки, мы решились на глобальные перемены.
📅 Дата: 14.08.2025
⏰ Время: 17:00-18:00 (Мск)
👨🎓 Спикер: Акманова Елизавета — старший аналитик ГК «Юзтех», преподаватель школы системного анализа.
Что будет на эфире?
✔️ Разберем объективные причины, которые подтолкнули нас к смене архитектуры.
✔️ Реальные плюсы и минусы микрофронтендов.
✔️ Практические кейсы, неочевидные вызовы и решения.
✔️ Честные выводы и советы, чтобы ваш переход был максимально гладким.
Почему одиночкам тяжело расти? Как мы организовали сообщество системных аналитиков и что из этого вышло
В IT слишком часто «каждый варится в своём соку» — и специалисты теряют темп, а команда не получает новых идей.
Какие шаги помогли объединить экспертов из разных проектов, даже если зона ответственности не совпадает? Как совместные обсуждения, обмен опытом и единые подходы преобразили корпоративную культуру? Какие неожиданные инсайты и эффекты обнаружились уже через несколько месяцев — и почему это оказалось выгодно всем сторонам? Рассказываем в нашей статье «Как мы организовали сообщество системных аналитиков и что из этого вышло».
Только реальный опыт, этапы создания, сложности, примеры встреч, плюсы и подводные камни. Читайте статью, берите инструменты для своих команд и рассказывайте, помогает ли комьюнити решать задачи эффективнее у вас!
Говорим на языке событий: что даёт ивент-шторминг и как его правильно провести
Привет! Я Иван Чернов, системный архитектор, в этом посте расскажу про ивент-шторминг.
В Островке есть набор сервисов, который разбит на логические блоки так, чтобы в рамках блока можно было итерировать: Островок, Островок B2B и Островок Командировки. При этом запускать новые фичи, которые будут сквозь эти слои прорезаться.
Мы растём по количеству и продуктов, и людей, нанятых для их разработки. Недавно начали толкаться локтями: не понимали, как качественно контрибьютить в большие кодовые базы, как они должны эволюционировать. Поэтому пришли к ивент-штормингу.
Что это за практика? На встрече с одной стороны сажаем бизнес, с другой — разработку. Просим бизнес рассказать, что и как он делает в работе с клиентом.
Ивент-шторминг проводится с фокусом на цикличную реактивность: происходит событие, которое визуально меняет что-то для пользователя, тот принимает решение и отдаёт команду, команда приводит к новому событию.
На этих циклах фокусируемся на доске в Miro во время встречи.
В ивент-шторминге 3 этапа:
1. Сейлзы выстраивают по циклам цепочку событий: от «клиента у нас ещё нет» до «клиент нас окончательно покинул». Даже в простых цепочках 20–30 действий. В готовом таймлайне есть happy pass: клиент успешно прошёл весь путь. И альтернативные пути: что-то пошло не так.
2. Проходим по таймлайну с конца, ищем ошибки. Выделяем ключевые события, которые нельзя откатить: клиент зарегистрировался, совершил бронирование, провёл оплату. Здесь происходит стык сервисов. На стыках обогащаем цепочку. Пишем, кто и что делает: актор-клиент зарегистрировался, подключился сервис юзер-менеджмента.
3. Выявляем, какие агрегаты работают с событием. Мапим команды: клиент регистрируется, в работе участвует команда регистрации.
Цепочка готова, мы получили полезный контекст, все одинаково понимают процессы и видят, что нужно делать, чтобы их улучшить.
Во время встречи составляем словарик. Если сейлз говорит непонятное разработчикам слово — мы его добавляем в словарь, и оно просасывается в наш интерфейс и кодовую базу. Всё это учит разработчиков понимать, на какие рычажки они влияют своим кодом.
Поделюсь советами, как круто провести ивент-шторминг.
Онлайн-формат
● Для проведения онлайн достаточно доски в Miro.
● Разбивайте встречу на три части, каждая встреча — один этап.
● На последней встрече отпустите бизнес, выявите агрегаты и сервисы, задействованные в таймлайне с разработкой.
● Максимум людей для успешной фасилитации онлайн — 8–10 человек.
● Ищите представителей бизнеса в оргчате выбранного домена: спрашивайте у руководства, «кто тут самый инициативный».
● Вам нужны работники «с полей», которые лучше всего шарят в процессах, и тимлиды первого уровня.
● Берите людей из разных направлений домена.
● Бизнес-участники должны понимать: ивент-шторминг — процесс обучения, они эксперты, а разработка — ученики. Им нужно говорить на своём языке, а не подстраиваться под разработку.
● Дайте участникам базовый словарь. Четыре самых важных слова: актор, команда, событие, термин.
● Важны вводные по времени и цели: на сессию уйдёт суммарно 6–8 часов, она даст единое понимание процессов.
Фасилитация
● На старте не бойтесь повторить все вводные.
● Дайте сейлзсам 10 минут на то, чтобы каждый выстроил индивидуальный таймлайн, дальше начинайте мёржить таймлайны с общим обсуждением.
● Событие — факт в прошедшем времени, его не отмотать. Следите, чтобы так и записывали.
● Первым делом простройте happy pass, иначе у вас не выстроится цельное видение процесса. Альтернативные ветки обозначьте на первом этапе, а достраивайте на втором, проверяя таймлайн с конца.
● Если бизнес утверждает, что два события происходят одновременно, это важная точка обсуждения.
● Организуйте пост-процессинг: важно передать разработке результаты, объяснить, какие процессы у нас уже верно реализованы, а где нужно обновление и дополнительное внедрение.
Что такое архитектура ПО и почему она не про красивые диаграммы
Изображение сгенерировано при помощи DALL-E 3
🏗️ Архитектура программного обеспечения — это не просто модное слово для повышения ставки на собеседовании. Это фундамент, на котором строится вся система.
Что это такое на самом деле? Архитектура ПО — это структура компонентов системы, их взаимосвязи, взаимодействия с внешней средой и принципы разработки. Звучит скучно? А вот и нет! Это как план города: без него у вас получится не Москва, а какая-то деревня Гадюкино с кривыми улочками.
Зачем это нужно?
Снижает сложность системы через декомпозицию
Определяет рамки развития (чтобы не росло как раковая опухоль)
Помогает команде говорить на одном языке
Экономит нервы и деньги в долгосрочной перспективе
Под капотом архитектура отвечает за: ✅ Разбиение системы на модули (как LEGO, только для взрослых) ✅ Способы взаимодействия компонентов (REST, RPC, события) ✅ Распределение ответственности между модулями ✅ Выбор технологического стека
Простой пример: Представьте интернет-магазин. Без архитектуры у вас будет один гигантский файл на 50,000 строк, где корзина покупок живёт рядом с логикой оплаты, а пользовательские данные перемешаны с каталогом товаров. С архитектурой — отдельные модули: UserService, CatalogService, PaymentService, каждый со своей зоной ответственности.
🔧 Давайте разберём базовые понятия архитектуры, без которых никуда. Это как алфавит — скучно учить, но без него читать не получится.
Компонент — часть системы, выполняющая изолированную функцию. Думайте о нём как о сотруднике в компании: у каждого своя роль, свои обязанности, и если он заболел — его можно заменить.
Пример компонентов:
Authentication Service (следит, чтобы чужие не лезли)
Notification Service (шлёт уведомления)
Data Storage (хранит данные, очевидно)
Интерфейс — способ взаимодействия между компонентами. Это как протокол дипломатии: все знают правила игры, никто не лезет с кулаками.
Типы интерфейсов:
REST API (классика жанра)
Message Queue (асинхронные сообщения)
RPC (удалённые вызовы)
Database API (работа с данными)
Связи — физические или логические каналы передачи данных между компонентами. Это как дороги в городе: определяют, кто с кем может общаться и как.
Примеры связей:
HTTP-соединения (веб-траффик)
TCP/UDP сокеты (низкоуровневая связь)
Message Brokers (Apache Kafka, RabbitMQ)
Database connections (пул соединений с БД)
Модуль — логическая группировка компонентов по функциональности. Это как департаменты в компании: HR, IT, Бухгалтерия.
Примеры модулей:
User Management Module (всё что касается пользователей)
Payment Processing Module (платежи и транзакции)
Analytics Module (метрики и отчёты)
Сервис — автономная единица бизнес-логики с чётко определённой ответственностью. Это как мини-приложение внутри большого приложения.
Примеры сервисов:
Order Service (управление заказами)
Inventory Service (управление товарами)
Billing Service (выставление счетов)
Хранилище данных — компонент, отвечающий за персистентность информации. Это как склад или архив компании.
Типы хранилищ:
Реляционные БД (PostgreSQL, MySQL)
NoSQL (MongoDB, Redis)
Файловые системы (S3, локальные диски)
Кэши (Redis, Memcached)
SLA — характеристики работы сервиса. Это контракт: "обещаю работать 99.9% времени и отвечать за 200ms".
Зачем нужны SLA:
Понимание ожиданий от системы
Планирование мощностей
Определение критичности сервисов
Основа для мониторинга
Практический пример: Сервис авторизации должен:
Отвечать за 100ms в 95% случаев
Быть доступным 99.95% времени
Выдерживать 1000 RPS
Чеклист для правильного проектирования: ✅ Каждый компонент имеет чёткую ответственность ✅ Интерфейсы документированы ✅ Связи (способы взаимодействия) определены ✅ Деление на сервисы произведено ✅ Способ хранения данных определен ✅ SLA определены и измеряемы ✅ Зависимости между компонентами минимальны
Помните: хорошая архитектура начинается с понимания базовых элементов. Без этого ваша система превратится в спагетти-код корпоративного масштаба.
В SSP SOFT открыты новые вакансии в ИТ-команды: ищем мидлов, сеньоров и лидов
Мы в SSP SOFT — команда, которая занимается заказной разработкой и активно ведет проекты по модели ИТ-аутсорсинга. Наши специалисты помогают внешним клиентам реализовывать задачи в e-commerce, финтехе, медтехе, управлении инфраструктурой и других отраслях.
Во 2-м полугодии 2025 года мы усиливаем несколько ключевых направлений. Если вы уверенно чувствуете себя как профи, цените системный подход и хотите работать в зрелой команде — присоединяйтесь.
Аналитика и системный анализ • Аналитик DWH • Аналитик 1С (Регламентированный учет) • Бизнес-аналитик (Промтех) • Системный аналитик (ИБ)
Разработка • Lead Python Developer • Android-разработчик (Senior) • Fullstack-разработчик (C#, React) • Разработчик 1С (ЗУП) • Разработчик Angular • Разработчик MS SQL • Data Engineer
Тестирование и поддержка • Automation QA Engineer • Automation QA Engineer (Python) • Automation QA Engineer (Java) • ITSM-инженер
Как мы подходим к найму:
В SSP SOFT мы рассматриваем найм не как «закрытие вакансии», а как включение нового человека в команду — с вниманием к развитию и прицелом на долгосрочную совместную работу.
🧩 Наши специалисты нередко входят в состав аутсорс-команд, работающих с внешними клиентами. Поэтому важно не только владение инструментами, но и софтскиллы: умение выстраивать коммуникацию, брать ответственность за сроки и качество своей работы.
🧭 Как устроен процесс найма и адаптации:
1️⃣ Собеседование с HR и руководителем направления, 2️⃣ Техническое интервью с нашими экспертами, 3️⃣ Индивидуальный план онбординга — с учетом ваших сильных сторон, 4️⃣ Испытательный срок — с поддержкой наставника, 5️⃣ Подключение к серьезным задачам — когда вы полностью готовы.
Представьте, что архитектура — это проект моста. Без аналитика строители видят только берега, бетон и металл. А потом выясняется, что по мосту должен проехать тяжёлый поезд, а не пешеходы. Опоздали...
Системный аналитик в архитектуре — это тот, кто ещё до первой строчки кода выясняет:
кто по мосту пойдёт;
когда он должен быть готов;
какой ветер дует в регионе;
и почему заказчик хочет на въезде логотип в стиле ар-деко.
Что делает аналитик:
Формализует требования. Не «нужно быстро», а «время отклика — до 300 мс для 95% запросов».
Собирает и декомпозирует требования: и бизнесовые, и технические.
Описывает процессы и данные, чтобы разработчики понимали, с чем работают.
Создаёт модели: ERD, BPMN, DFD, UML — чтобы было понятно и на митинге, и через год.
Выявляет противоречия. Если в одном месте говорится «реестр должен быть публичным», а в другом — «данные должны быть защищены по ФЗ-152», аналитик не ждёт багов — он их предотвращает.
Фиксирует ограничения: на инфраструктуру, бюджет, регуляторику.
Согласует архитектурные решения: чтобы бизнес понимал, почему микросервисы, а не монолит, и что это не «модно», а целесообразно.
Без него:
Архитектор опирается на предположения.
Команда упускает сценарии использования.
Нефункциональные требования (безопасность, отказоустойчивость, масштабируемость) игнорируются.
В итоге — технический долг с первого релиза и недовольный бизнес
И да, аналитик — не просто передатчик между бизнесом и технарями. Он переводчик с «хочу, чтобы было удобно» на «нужна интеграция с LDAP, SLA по логину — до 1 секунды».
Проект без аналитика — это как строить дом по фотографиям других домов. Кажется, понятно. А потом — сюрприз: у вас 12 ванных и ни одной кухни.
Неделю назад OpenGroup анонсировали публикацию черновика стандарта Archimate версии 3.3 (официально номер не обозначен - это мое предположение) для ознакомления с ним более широкой аудитории.
Я тоже скачал, полистал... Замечательно, когда есть раздел с кратким описанием отличий. Так вот, что же нас ждет:
удалили связь композиции (composition) - теперь вместо него либо просто агрегация, либо специализация;
удалили элемент "взаимодействие" (interaction) на всех уровнях, а также ограничение (constraint), разрыв (gap), контракт и представление (representation);
элементы поведения на всех уровнях объединили в общие элементы "сервис", "процесс", "функция" и "событие";
"событие" ("event") на слое implementation также заменено на общий элемент "событие";
элемент "коллаборация" объединен для всех уровней (бизнес, приложения, технология);
бизнес-роль стала просто "ролью";
вместо представления фреймворка в виде аспектов и слоев теперь остался только шестиугольник Archimate;
термин "слой" заменили на "домен";
раздел по "Общей метамодели" заменили на главу 4, описывающую общие элементы (см. выше);
путь ("Path") теперь входит в общий домен;
вместо агрегации от пути к внутреннему активному структурному элементу теперь реализация от активного структурного элемента к пути;
появилось визуальное отражение мощности связей (для отображения ограничений)
В качестве подходов для трансформации моделей из спецификации 3.2 в 3.3 предлагается выполнить замену (в т.ч. с использованием специализации соответствующего концепта):
композицию - на агрегацию
ограничения - на требование (requirement)
контракт - на бизнес-объект
разрыв (gap) - на оценку (assessment) или результата (deliverable)
представление (representation) - на объект данных, артефакт или материал
взаимодействия - на процессы и функции
в целом элементы поведения с разных уровней - на универсальный аналог
отмененные виды связей между конкретными типами элементов - на связь ассоциации
Если сравнивать с предыдущими версиями - они были менее революционными, и в основном добавляли что-то новое, дополняли. Грядущая же версия обещает чистку и унификацию - в т.ч. за счет активного применения введенного в предыдущих версиях понятия специализации для любого элемента / связи. По заверениям представителей OpenGroup это должно увеличить ясность и согласованность моделей, а также улучшить взаимопонимание при межкомандном взаимодействии.
На мой взгляд такое активное использование специализаций элементов алфавита языка Archimate с одновременным сокращением самого состава алфавита, с одной стороны повысит гибкость в подходах к моделированию, а с другой, после выработки этих подходов - потребует детализации соглашения по моделированию для конкретной организации/проекта/команды (т.е. насчет "лучшего взаимопонимания команд" я бы еще поспорил).
И еще один момент - переход на специализации по факту переводит от визуально заданного различия между элементами (либо цветом, либо формой) к необходимости вывода текстового уточнения, что сразу снижает наглядность и читаемость диаграмм (крайний случай - полный отказ от визуальной разницы и переход на нотацию "квадратики и стрелочки" - после чего, обычно, начинается обратный процесс визуального разделения "стикеров" по цветам и стрелочек по типам линий и окончаний, а потом и придумывание специальных графических обозначений).
P.S.: в Acknowledgements изменений нет - моя фамилия единственная русская :-)
Привет Хабр! Когда ИТ-рынок охлаждается, мы продолжаем нанимать. Предлагаем реальные задачи, прокачку скиллов и бенефиты «в рынке». Никакой бюрократии и скуки — мы нацелены на то, чтобы ты получал удовлетворение от работы.
✔️ Гарантируем интересные задачи ✔️Для каждого нового сотрудника есть наставник ✔️ Центр компетенций помогает прокачивать навыки ✔️ С нами ты можешь работать из любой точки мира ✔️ Для экстравертов у нас есть уютные офисы в Москве и Томске ✔️ Оптимальный Work Life Balance
🎁 Наши плюшки: ДМС со стоматологией, обучение от компании и бонусная программа.
В работе с данными важна системность — от понимания основ до практического применения инструментов. Мы подготовили подборку из ресурсов, которая поможет новичкам освоить необходимые навыки и развить понимание аналитики в разных аспектах.
Если хочется продолжить изучать основы и сделать шаги к практике — посмотрите на бесплатные курсы и вводные темы на курсах Практикума. Вы можете порешать математические задачки или изучить основы статистики.
Сегодня решил сравнить размерчики OS X 10.8 и macOS 15.
Вот что увидел:
OS X 10.8: du -sh ~/Library -> 33M
macOS Sequoia: du -sh ~/Library -> 8.2G
OS X 10.8: du -sh /Library -> 842M
macOS Sequoia: du -sh /Library -> 3.8G
OS X 10.8: du -sh /System/Library -> 3.2G
macOS Sequoia: du -sh /System/Library -> (куча permission denied даже для read, спасибо SIP) -> но то что удалось считать 139G
Конечно последнее значение выглядит как фальшивое, но на остальные сквозь пальцы посмотреть нельзя. А тем временем предлагаю оценить сколько новых фишек добавилось в новой macOS за 13 лет и оценить здравость такого роста:
Рост никак не оправдан, новых и полезных фишек почти 0
Новых функций прибавилось много, но увеличение веса системы не соразмерно
Вес вполне оправдан, так и должно быть при такой массе нововведений!
Лично я склоняюсь к варианту 2. Свои ответы можете написать в комментариях!
Пошаговые инструкции сборки — больше не ад для техписов
Изначально система автоматической генерации документов требует значительных затрат. Если конфигураций оборудования всего несколько, то раздельные инструкции проще и быстрее написать вручную, чем создавать под них систему.
В нашем случае разработка самой системы динамической документации и подготовка контента для первых четырех продуктов в ней заняли в сумме около 1300 человеко-часов. Этот самый тяжелый и затратный этап включал изменение логики, наполнение и отладку системы и согласование изменений с технологами.
На данный момент мы собрали из исходников документы для 647 конфигураций серверов. Даже при таком сравнительно небольшом количестве инструкций мы простым делением получаем затраты на один документ в размере 2 человеко-часов. Это в 12,5 раз дешевле, чем писать отдельные инструкции вручную — выше мы оценивали затраты такого подхода. В итоге с документацией справляются шесть человек — а если бы мы делали инструкции вручную, потребовалось бы не меньше 13 сотрудников. После внедрения конструктора мы оценили дальнейшие трудозатраты, продолжили работу с динамической документацией, и уже через несколько месяцев система начала окупаться.
Глеб Свистунов, руководитель отдела производственной документации YADRO, в своей статье рассказал о подходе динамической документации. С ним составлять пошаговые инструкции сборки оборудования для огромного количества конфигураций гораздо эффективней, чем вручную.
Откровения евангелистов БЯМ (LLM) для целей софтостроения генерируются публикуются с высокой скоростью. Не только на хабре, LinkedIn заполнен ими "под завязку". Прочитывать всё невозможно, да и не нужно, но некоторый тренд в изложении присутствует.
К сожалению, авторы много пишут о процессе, забывая собственно цели. Упоминание о функциональной сложности программы, как правило, отсутствует. Длина описаний процесса может создать ложное впечатление о развесистой функциональности, хотя большинство примеров находятся на уровне "записная книжка". В этом нет ничего плохого, просто не забываем, что 30 лет назад RAD типа Delphi умели создавать такие же "книжки" без написания кода вообще: достаточно было "накидать" компонентов на форму, настроить, связать их, и нажать "Run".
Накидали, и что дальше?
За словами "писать на близком к естественному языку", скрывается постепенное создание быстро растущего "промпта" - детальной спецификации, местами - псевдокода. Как следствие, необходимо иметь версии таких "исходников", как и раньше для кода (об этом практически не пишут). Для сторонних пакетов, API служб и прочих зависимостей не забываем указывать версии. По сравнению с таким "псевдокодом" техзадание может показаться увлекательной беллетристикой. Речь идет по сути о конечных спецификациях, ведь программирование - не столько кодирование (от силы 20% времени), сколько детальное проектирование и стабилизация.
Размер спецификаций псевдокода вкупе с описаниями контекста среды могут превзойти собственно размеры генерируемого кода, написанного программистом на формальном ЯВУ. Спецификации придется так же хранить в Git, и нервно просматривать, что же изменилось в сценариях, почему, ***, вместо слова "опять" кто-то написал "снова".
Для детерминированности процесса желательно, чтобы моделька была в том же состоянии, что и на предыдущем этапе генерации, но для внешних БЯМ-сервисов это недостижимо. Напомню, что компиляторы и классические генераторы кода (CASE, MDD) - детерминированные.
На первый план выходят тесты, их нужно писать "больше и лучше", потому что под капотом теперь только "черный ящик", "белого" больше нет. Тесты нужно постоянно обновлять в зависимости от объема изменений. Если ваши новые спецификации меняют 20% существующей кодовой базы, то тестов придется менять вдвое больше, принимая 2:1 за стандартное соотношение тестов к коду. Для языков без статической типизации тестирование еще более усложняется.
В реальных проектах написание сотен строк в день - это режим стартапа, причем на "нулевом цикле". Достаточно быстро программист приходит к естественной норме десятков строк в день, остальное время занимает понимание текущего потока проблем, поиск ошибок, интеграция и стабилизация. Хороший программист минимизирует объем порождаемого кода. Нужно ли включать БЯМ для написания 50 строк в день - вопрос.
В процессе не предусмотрена роль юниоров. Перспектива - "уйти со сцены", не воспитав смены, достаточно сомнительная для бизнеса и весьма печальная в личном плане.
Напоследок накину немного философского. Евангелисты любят упоминать, что человеческий мозг и БЯМы работают на одних и тех же принципах. Часто выясняется, что курса "Аналоговые ЭВМ" на их потоке уже не было, что несколько удручает. Еще более простой вопрос на примере несуществующей (пока?) телепортации: "Человек на входе телепортера и на выходе - это одна и та же личность?"
Пройдите наш тест и узнайте правду: вы — гуру бизнес-анализа или просто мастер красивых диаграмм?
Что вас ждёт:
✔️ 10 вопросов о работе с требованиями, декомпозиции задач, анализе данных и коммуникации с заказчиками и командой.
✔️ Честный вердикт на каком уровне находитесь: Junior, Middle или Senior.
✔️ Полезный бонус — бесплатный чек-лист лист «Как разбить работу бизнес-аналитика на задачи», который поможет структурировать проекты и избежать ошибок в планировании.
Готовы проверить себя?Переходите по ссылке и узнайте, какие области стоит прокачать для профессионального роста.
P.S. Чек-лист работает, даже если тест выявил, что ваша суперсила — это крепкий кофе и удалёнка.
Клиент: Сколько страниц будет входить в аудит? Я: Неизвестно. Почему неизвестно? Потому что у меня нет цели написать определённый объём правок и замечаний. Сколько их увижу — столько и зафиксирую. Если бы я проаудировал систему и не нашёл в ней ни одной проблемы — размер документа не превышал бы одной страницы.
Тут сразу пара моментов, которые хотел бы подсветить.
Я раньше, когда работал над документацией, считал, что «чем объёмнее — тем лучше». Это ещё со школы и универа. Реферат должен быть на пять листов. Эссе на семь. Доклад на три.
Акцент был на форме, а не на содержании. И это ужасно. В начале двухтысячных, когда работал в компании Webmaster.Spb проектировщиком, клиентам нравились толстые ТЗ. Точнее, представителям клиентов. Менеджерам. Сами-то клиенты эти ТЗ не читали, насколько мне известно.
Из строительной тематики тоже была клёвая байка, которую мне рассказал один из клиентов: «Я однажды сдаю своему шефу пачку документации высотой в два сантиметра. А он смотрит на неё и пальцами показывает три сантиметра. Вот столько, говорит, надо. Возвращайся, когда будет пачка высотой в три сантиметра».
Это первый момент. А второй — если во главе стоит форма, а не содержание, то это сродни проектированию главной страницы сайта, когда всё остальное ещё не готово. Спроектировал главную за час, а потом пятьдесят часов подгоняешь остальные сто страниц под неё. Вместо того, чтобы сделать всё без ограничений, а главную рисовать уже в самом конце, когда весь проект будет понятен. В виде вишенки на торте.
Иногда ещё, знаете, решишь написать статью. И придумываешь ей заголовок «пять ошибок начинающих проектировщиков». И вот четыре ошибки легко расписал, а пятую никак придумать не можешь. И сидишь, мучаешься, тратишь время. А мог сначала статью написать, ограничившись четырьмя ошибками, а затем уже заголовок придумывать.
Прикиньте, кто-то сначала бы придумал тематику: пять начал (законов) термодинамики. И после четвёртого сидел бы и страдал.
Возвращаясь к моим аудитам: у меня нет задачи найти конкретное количество косяков. Задача — проверить, достигают ли пользователи интерфейса своих целей. Если достигают — и отлично! Радоваться надо, что в моём документе будет одна строчка текста («Всё идеально, красавчики»). Это как на чек-ап пойти ко врачу и переживать, что ничего не нашли.
К сожалению, на практике такого ещё ни разу не было. Всегда что-то нахожу.
П.С. Представляете, я бы сказал, например: «Четыре страницы». Сделал бы аудит и нашёл бы ошибок на две страницы. И что бы делал? То же, что в школе и универе? (здесь должна быть какая-нибудь эмодзи с льющейся бессмысленной водой)
Хочу поделиться с вами видением хорошей архитектуры Go проекта, к которой я пришёл на данный момент и также интересно послушать ваши варианты и мнения по данному поводу.
Моё видение:
У нас ядро приложения это сервисный слой (юзкейсы), именно ядро самая основная часть приложения, которая взаимодействует с какой‑то логикой.
Если логика основана на внешних компонентах, то для связи ядра с компонентом(адаптер) и обратно используются абстракции в виде интерфейса(порт). При этом неважно какая связь (от ядра к компоненту или наоборот), внешние компоненты реализуют интерфейсы ядра и не содержат бизнес‑логики, они лишь преобразуют данные к форматам, понятным ядру (интерфейсы также основаны на моделях ядра).
Так как мы не хотим, чтобы логика из ядра уходила во внешние компоненты (по моему мнению, это повлечет переплетение зависимостей и нарушение принципов разделения ответственности), то вся логика должна выполняться на уровне ядра (например, вместо default значений полей в базе, мы создаём модель на уровне ядра, а база служит лишь в качестве хранилища, не выполняя какой‑либо бизнес логики). То есть бизнес‑валидация (инварианты агрегатов) остаётся в ядре, а адаптеры проводят schema‑валидацию (обязательные поля и форматы) до передачи в юзкейсы, тем самым мы избегаем лишних вызовов ядра (при некорректных данных), и не засоряя само ядро валидацией (отличным примером служит то, когда HTTP адаптер валидирует модель до передачи её в юзкейсы).
При этом всё, самое лучше место для интерфейсов (портов) будет отдельный пакет в ядре, к которому могут иметь доступ адаптеры, чтобы проверить реализации контракта (при это адаптеры будут "знать" лишь интерфейсы, а не весь сервисный слой, если бы порты хранились бы в месте использования), а также сами сервисы могут спокойно ссылаться на данные интерфейсы, не подтягивая их с адаптеров (в том случае, если бы мы хранили интерфейсы по месту имплементации).
То есть я считаю идеальной архитектурой для большинства Go проектов, работающих на основании адаптеров (к примеру, REST или gRPC сервис) гексагональную архитектуру с включением подхода DDD.
У меня остались также холиварные вопросы к вам. Как считаете:
Передавать в юзкейсы структуру или поля по отдельности?
Должно ли хранилище, в виде БД например, иметь валидацию данных? Операции по крону? Дефолтные значения полей?
Транзакции: где их начинать/заканчивать?
Когда и где вводить versioning: в HTTP‑уровне, в домене (разные агрегаты) или в репозиториях (Multi‑tenant)?
Должны ли доменные ошибки возвращать rich‑error (с кодом/контекстом) или достаточно обычных error с текстом?
Если у вас в приоритете — опыт работы над масштабным продуктом и строчка в резюме, с ходу впечатляющая HR-ов… Другими словами, если в ваши карьерные планы входит работа в крупной технологической компании — значит, мы придумали этот тест для вас.
Он поможет сориентироваться: проверить хард- и софтскилы и понять, какие навыки уже на высоком уровне — а что стоит прокачать, чтобы повысить шансы оказаться в бигтехе.
Тест вам подходит, если:
Ваша специальность — разработчик, DevOps-инженер, аналитик данных или ручной тестировщик.
Ваш грейд — джун+ и выше. Нужна теоретическая база, коммерческий опыт или опыт решения учебных проектов на реальных кейсах.
Чтобы давать релевантные задачи, мы консультировались с нанимающими менеджерами Яндекса — они знают, чего ждут от соискателей в больших технологических компаниях.
