Анализ и проектирование систем *

TL;DR перевода статьи Boris Tane: SDLC is dead.

SDLC больше нет. AI-агенты не ускорили привычный жизненный цикл разработки, они его схлопнули.

- Agile-ритуалы мертвы. Планирование спринтов, оценки в story points, релизные поезда и многодневные ожидания аппрувов в PR — всё это пережитки прошлого.

- Все этапы слились воедино. Сбор требований, system design, написание кода и тестов происходят одновременно — в реальном времени и в диалоге с агентом.

- Code Review — это новый луддизм. Машина генерирует 500 PR в день, человек физически не может их проверить. Код должен лететь прямо в main под прикрытием автотестов, feature flags и хорошо настроенного observability.

Новый жизненный цикл — это узкая петля: Intent (Намерение) → Build (Создание) → Observe (Наблюдение).

Эта статья от разработчика Авторизы - SaaS-сервиса аутентификации и авторизации, но давайте отбросим скепсис. Я не для рекламы это пишу, а рассказать, с какими проблемами столкнулся и почему вообще затеял этот стартап. Можно сказать - история возникновения. А еще как через него я, может быть, смогу решить и ваши проблемы. Это не техническая статья, а тема для дискуссии

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

Привет, это команда Яндекс Практикума. Сегодня поговорим про то, как погружаться в профессии DE, ML, CV, NLP так, чтобы с одной стороны, получить основательный теоретический фундамент, а с другой — освоить навыки, которых ждут работодатели. Очевидный спойлер: нужно прокачивать теоретическую базу и параллельно много практиковаться — про практику отдельно расскажем на примере учебного проекта в онлайн-магистратуре НИЯУ МИФИ в партнёрстве с Яндекс Практикумом «Специалист по работе с данными и применению ИИ».

Приемная кампания в российских колледжах и вузах сопровождается публикацией обширных массивов данных на официальных сайтах. С одной стороны, это требование прозрачности процедуры зачисления. С другой стороны, существующий подход к обезличиванию информации содержит системную уязвимость, которая позволяет стороннему наблюдателю с высокой точностью сопоставить ФИО абитуриента с его номером СНИЛС.

Я провел анализ открытых источников 100 учебных заведений (вузы и колледжи) и выяснил, что 87 из них оставляют возможность такой деанонимизации. Причем данные за предыдущие годы остаются в открытом доступе, формируя устойчивый архив персональной информации.

Проблема публичного идентификатора

Подавляющее большинство учебных заведений размещает конкурсные списки в формате, где для идентификации абитуриента используется не случайный код, а его номер СНИЛС. Обоснование у разработчиков таких систем прагматичное: СНИЛС уникален, абитуриент знает его наизусть, поиск по списку упрощается.

Однако СНИЛС — это не просто номер. Это ключевой идентификатор гражданина в системе межведомственного взаимодействия. В связке с фамилией и инициалами он позволяет:

Сезон Heavy Digital длился на Хабре с 30 января по 15 марта. В нём приняли участие 48 материалов о цифре в промышленности, набравших в сумме сотни комментариев и более двухсот тысяч просмотров.

Такая реакция пользователей Хабра — знак, что эта тема живая и самостоятельная. Со своими героями, понятными сюжетами, спорами, болями и любимыми жанрами и со своей аудиторией — не случайной, а готовой читать, обсуждать и спорить. Сезон показал, что индастриал-тексты впитали в себя всё, за что любят хороший техконтент: сложные системы, цену ошибки, рабочую смекалку, тяжёлую инженерную фактуру и, конечно, личные истории. 

Что ж, пора подвести итоги сезона и посмотреть, что эти сорок с лишним текстов добавили к дискуссии о заводской цифре на Хабре.

Работа в Сибири – это суровый климат, гигантские расстояния и сложные промышленные объекты, которые требуют технологий, способных «видеть» и фиксировать реальность с ювелирной точностью. Для инженерного центра «СибИАЦ», более 20 лет обеспечивающего теплом и энергией населенные пункты региона, лазерное сканирование давно стало и глазами, и средством получения точной информации.

Введение санкций и уход с российского рынка западных компаний, занимающихся разработкой и поставкой специализированного программного обеспечения, сделали актуальным вопрос оперативного перехода на отечественное решение. Совместный с компанией «Макссофт-24» проект по внедрению программного решения nanoCAD Облака точек позволил не только бесшовно заместить ПО для обработки данных лазерного сканирования, но и выстроить более эффективный и технологичный рабочий процесс – от сканирования объекта SLAM-сканером до передачи готовой трассировки в BIM-модель.

Когда овчинка стоит выделки: сложности внедрения окупились многократно...

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

Напомним, что функциональные требования – это не 50% от общего объема всех требований к Системе, которые определяют 100+ % успеха разработки и реализации.

Итак, что точно не нужно делать.

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

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

Вот почему я решила вжиться в роль трейдера: пройти обучение, совершать сделки, фиксировать свои ощущения и страхи.

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

Мы поговорили с тремя специалистами по машинному обучению и data science (ML/DS) и попросили их рассказать о своём пути и проектах. А в конце собрали советы для тех, кто хочет начать свой путь в data science: какие навыки качать, где брать опыт и к чему готовиться на собеседованиях.

Я перепробовал несколько способов вести документацию по базе данных — и у каждого были свои проблемы: информации недостаточно, сложно поддерживать, непонятна команде. Хуже всего, что плохая документация по БД тянет за собой проблемы с требованиями к данным — а это не только таблицы, но и миграции, и данные в коде. В какой-то момент я понял, что пытался решить одним документом три разные задачи.

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

Неизменно было только одно – основную ценность представляет код. Код – это истина в последней инстанции. Требования, архитектура, тест-кейсы — не более чем черновики, наброски, которые могут быть уничтожены сразу после начала «настоящей работы» – написания кода.

Но что, если я скажу, что сейчас происходит тихая контрреволюция? Индустрия устала от неопределенности. Когда код — единственная истина, система превращается в «черный ящик». Понять, как она работает фактически, можно только прочитав тысячи строк кода.

Код идеально отвечает на вопрос «как?», но в нем нет ответа на вопросы «зачем?», «для кого?», «почему?».  Без знания ответов на эти вопросы, любая доработка —  это гадание на кофейной гуще.

В этой статье проследим эволюцию: от Водопада к Agile, от Agile к Гибридам и Everything as Code.

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

Linux пропитан магией. Тип файла определяется не по расширению, а библиотекой magic, которая смотрит на сигнатуру первых байтов. В системе живут демоны, процессы могут работать в режиме daemon, а исполняемые файлы хранятся в формате ELF и разбираются утилитой readelf. Это похоже на шутки старых разработчиков, но они появились не случайно.

Инженерные системы наполнены метафорами, потому что так проще думать о сложном, объяснять невидимое и работать с тем, что нельзя потрогать руками. Со временем мы привыкаем к этой «магии» и перестаём замечать, что вместе с ней перенимаем определённый способ мышления.

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

В данной статье рассматриваются примечательные ошибки при работе с Kafka, в том числе при использовании библиотеки KafkaJS, а также способы их устранения и методы увеличения производительности при публикации и обработки сообщений.

Предполагается, что читатель имеет базовое представление о Kafka (раздел "Общие термины" поможет освежить информацию) и функционале библиотеки KafkaJS.

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

Меня зовут Андрей Рыжик, я разработчик BI в компании «Белый код». В 2025 году мы столкнулись с частым запросом: бизнес хочет внедрить отечественную BI‑систему, при этом бюджет плюс‑минус 1,5 млн рублей. Мы решили изучить рынок и найти подходящее ПО, а заодно рассказать тем, кто тоже подбирает продукт, о результатах нашего исследования. В первом обзоре — PolyAnalyst. Подробно разбираю архитектуру, компоненты, источники данных, ETL‑пайплайны, визуализацию и так далее

Внутренний трекер задач — Яндекс Трекер — важная часть Яндекса. В нём хранятся почти все планы: от целей отделов, до тикетов поддержки. RPS на фронтенд измеряется сотнями, а количество хитов в месяц — десятками миллионов. При таком масштабе даже небольшие задержки могут становиться критичными, поэтому мы задались целью ускорить Трекер. Спойлер: всё получилось не совсем так, как мы ожидали. Но обо всём по порядку. 

Для измерения скорости сервисов в Яндексе используется метрика Velocity Index — это агрегация метрик Web Vitals (FCP, LCP, TBT, INP, CLS). Итоговое значение получается в диапазоне от 0 до 100 баллов. Хорошим результатом считается индекс больше 85.

Мы поставили себе амбициозную цель: увеличить Velocity Index до 85, а заодно подлечить очевидные «узкие места» в скорости и ускорить всё, до чего сможем дотянуться.

Но до заветных 85 баллов мы так и не добрались.

Массовое внедрение AI в работу менеджмента и экспертов формирует пузырь, который удивительно точно повторяет механику ипотечного кризиса 2008 года. Парадокс в том, что формируется он на самом видном месте. Эксперты, инвесторы, акционеры — все пристально смотрят в документацию компании (или института). Но качество документа не гарантируют качества экспертной информации, которая должна была отражаться конечным артефактом. Документ может быть "токсичным": логично выглядеть, но содержать ошибки, противоречия и «галлюцинации» AI.

“Документы не должны противоречить друг другу” как отдельного требования нет, но оно кажется очевидным из ISO 9001, ITIL и BPM.

Рефакторинг — это не уборка, это хирургия на живом коде. Большинство провалов здесь не технические: смешали рефакторинг с улучшениями, сделали один огромный коммит, затянули релиз — и три недели работы ушли в мусор. Собрал 10 ошибок из реальных проектов: с примерами кода, разбором механики и способами не наступить на те же грабли.

"Я лжеученый, товарищи. И даже начинаю этим гордиться."

---

Я задал себе вопрос, который звучит одновременно просто и убийственно: то, что я делаю — это передовое исследование или самописная отсебятина?

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

И тут возникает вопрос: а кто я такой, чтобы это делать? У меня нет учёной степени. Я не публиковался в Nature. Я просто человек с ноутбуком, который много интересовался и задавал нестандартные вопросы.

Значит ли это, что всё, что я пишу — отсебятина? Или есть способ отличить графоманию от концептуальной работы, даже если ты не вписан в академические круги?

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

Начну со второго. Оно оказалось важнее.

---

Я проанализировал актуальные исследования, конференции, дискуссии 2025–2026 годов. И вот какой расклад я увидел.

Начну с главного: то, что я называю «машинной этикой Дебаркадера», в академическом поле не представлено. Это не хорошо и не плохо — это факт. Этот подход не рассматривается, на него не опираются в рассуждених, его не выдвигают на конференциях. Я вне мейнстрима.