В 1985 году учёный Питер Нур будто зрил в будущее, написав свою работу под названием «Programming as Theory Building», которая сегодня стала весьма актуальной. Мы всё чаще видим, как начинающие разработчики бездумно принимают сгенерированный ИИ код, который толком не понимают, а кодовые базы разрастаются лишёнными теоретических основ реализациями. В свете всего этого чётко вырисовывается основная идея Нура: «программа – это не её исходный код».
При проектировании систем, обязательным этапом является расчет нагрузки и стоимости на вашу IT-Систему. Давайте разберемся что это за этап и почему он так важен. А также вместе посчитаем основные показатели нагрузки и договоримся о стоимости решения.
Приложение тормозит. Пользователи в ярости. Продакшн-сервер гудит кулерами, а дашборды показывают красные пики. Первый инстинкт — звонить админам, требовать больше памяти и процессоров. Но чаще всего проблема не в железе. Она сидит глубже. В самом сердце системы — в базе данных. Имя этой проблемы — индексы. Или, точнее, их кривое использование.
Индекс — это как указатель в толстенном справочнике. Без него, чтобы найти нужный термин, вы обречены листать страницу за страницей. С ним — вы мгновенно открываете нужный раздел. Но что, если указатель сам размером с полкниги? Или ведет не туда? Такой помощник только вредит. С индексами в БД всё то же самое. Грамотная стратегия индексирования — это полет. Ошибочная — это бег в мешках по болоту.
Собеседование по System Design — это не просто проверка технических знаний, а настоящее испытание вашего инженерного мышления. В отличие от алгоритмических задач, где есть чёткие правильные и неправильные ответы, здесь всё строится на умении анализировать, взвешивать компромиссы и предвидеть проблемы до их появления. Ирония в том, что даже опытные разработчики часто проваливают эти собеседования, потому что сосредотачиваются не на том. Они могут идеально знать, как работает Kafka или Cassandra, но если не умеют структурировать свои мысли и задавать правильные вопросы, их шансы резко падают.
Современные решения в области бизнес-аналитики (BI) и искусственного интеллекта (AI) позволяют агрокомпаниям перейти от формальной отчетности к управлению, основанному на данных. Привет, Хабр! Я - Галина Галкина, работаю в департаменте аналитических систем компании R-Style Softlab (группа компаний Россельхозбанка). В этой статье предлагаю рассмотрим, как цифровые инструменты помогают оптимизировать процессы в животноводстве и птицеводстве.
Привет, Хабр.
Меня зовут Станислав Нижник. Я ведущий системный аналитик в MedTech-компании СберЗдоровье.
В этой статье я расскажу, как мы запустили «Книжный клуб» для системных аналитиков внутри нашей компании, почему мы не читаем на нем книги, как он менялся со временем, какие сложности мы решали. Ну и о том, зачем вообще мы создали «Книжный клуб».
В System Design нет «правильных» решений — только компромиссы. Бюджет, сроки, команда и законы диктуют, какие технологии выбрать, как масштабироваться и когда идти на жертвы. Разберём, почему определение бизнес-ограничений это важный этап System Design и почему они диктуют Айтишникам как и с чем работать.
Эта статья написана для заказчиков разработки, в основном касается IT-продуктов на ранних стадиях. Цель статьи — дать понимание, что писать в ТЗ, как и главное, зачем.
ТЗ — это вообще интересный феномен, все знают о том, что писать надо, но никто не делает. Либо делает халтуру с GPT, то же самое, даже хуже.
Если на собеседовании по System Design не уделить внимание требованиям, это почти гарантированно приведёт к провалу — даже если ваше техническое решение идеально. Игнорирование требований — главная причина провала на собеседовании. Уделите этому 5-10 минут, и ваше решение сразу станет в разы сильнее. Расскажем, как собрать и зафиксировать требования чтобы повысить свои шансы при прохождении собеседования в IT-компанию.
Вытаскиваем максимум пользы из привычного проектного артефакта в условиях внедрения систем с высоким уровнем кастомизации.
В процессе создания программного обеспечения участвует множество ролей, каждая из которых имеет свою систему ценностей, приоритетов и целей. Эти различия часто приводят к противоречиям в требованиях. Для структурированного анализа таких конфликтов используется модель «Гексапараллакс», которая рассматривает шесть ключевых точек зрения:
Привет, коллеги! Меня зовут Юля, я системный аналитик в компании EvApps.
Сегодня поговорим о sequence-диаграммах (диаграммы последовательности) – одном из способов моделирования взаимодействий между объектами в системе. В этой статье мы рассмотрим преимущества использования sequence-диаграмм, типичные ошибки при их создании, а также пример их проектирования. Ключевая идея – показать мыслительный процесс, а не просто шаблонное описание. Статья будет полезна прежде всего системным аналитикам, а также тем, кто участвует в проектировании и разработке программного обеспечения.
Представьте: каждый день менеджеры вручную переносят данные из 1С в Excel, чтобы рассчитать маршруты водителей и их зарплату. Два часа на каждого водителя, риски ошибок, бесконечные перепроверки. Именно с этим столкнулась компания по оптовой продаже и доставке автозапчастей по Москве.
Расскажу про систему учета в 1С, которая автоматизировала расчеты зарплат водителей и уменьшила ручной документооборот.
Продолжая тему косяков, с которыми могут столкнуться представители различных профессий, давайте поговорим о тех проблемах, который бывают у бизнес-аналитиков.
Хотя роль бизнес‑аналитика имеет решающее значение в любой организации, она не лишена подводных камней. Даже самые опытные специалисты могут допускать ошибки, которые снижают их эффективность в этой быстро развивающейся области. Независимо от того, новичок вы в этой области или имеете за плечами многолетний опыт, важно выявить и исправить эти распространенные ошибки. Итак, приготовьтесь к тому, что мы рассмотрим 10 главных ошибок бизнес‑аналитиков, которые могут помешать вам достичь успеха! От игнорирования ключевых задач до чрезмерной зависимости от документации — мы разберем каждую ошибку и предложим практические решения, которые помогут вам избежать ее, как опытный профессионал. Давайте погрузимся в работу!
Apache Kafka в интеграционных задачах КРУПНОГО бизнеса: какие плюсы и слабые стороны у такого подхода? И какие дополнительные инструменты стоит подключить, чтобы избавиться от всех проблем в интеграциях?
Статья для тех, кто хочет выжать максимум из 1С с ограниченным бюджетом.
Вводная часть
«Как можно автоматизировать продажи, не вкладывая сотни тысяч рублей? У нас маленький штат и нет своей ИТ-команды».
Серия статей с очередным разбором MV* шаблонов, но с интересными деталями
Даже опытные разработчики смогут найти что-то новое для себя
Это третья статья из серии,
в которой подробно разбираем из чего состоит MVI
Статья 3: Из чего готовят MVI
- ⚓️ Парадигма Реактивное программирование (Reactive programming)
- 🌯 Как завернуть все в шаурму Intent?
- 🌽 Как собрать урожай состояние?
- 🚜 Зачем трактору нужен редуктор?
- 🏪 Как открыть магазин с перехватчиками?
- 👷🏼♀️ 5 менеджеров и 1 работник
Кажется, никому из читателей Хабра не нужно объяснять, насколько сложным процессом является разработка авиационной техники и комплектующих. Мы часто читаем об этом. Понятно что, длительность процессов разработки, высокие требования к безопасности, строгие формальные процедуры, сложность конструкции и многодисциплинарность научных подходов – вот причины, по которым средний цикл разработки воздушных судов (ВС) составляет 5-10 лет и не всегда заканчивается успешно.
Привет! Это команда курса «Аналитик данных» в Яндекс Практикуме. Собрали подборку полезных ресурсов для тех, кто только начинает осваивать визуализацию данных или хочет расширить арсенал инструментов и источников вдохновения. Здесь вы найдёте книги, статьи, онлайн-ресурсы и телеграм-каналы, которые помогут разобраться, как правильно, наглядно и красиво представлять данные.
Всем привет, меня зовут Миша, и я разрабатываю платформу Яндекс Еды. Первые компоненты были написаны почти 10 лет назад (когда Еда ещё была стартапом Foodfox), и у нас накопилось много кода, который просто хорошо работает, а иногда даже «работает — не трогай». Но в процессе развития и устоявшиеся части системы нужно трогать, про что мои коллеги уже писали — как мы повышали версию PHP, пилили монолит и снимали нагрузку с БД.
Наконец настал черёд рассказать про процессинг заказов доставки еды из кафе и ресторанов (а также продуктов из магазинов и многого другого). За годы эволюционного развития он значительно разросся, что стало заметно затруднять дальнейшее развитие — например, изменения, связанные с выходом на новые рынки, — а также влиять на надёжность.
Поэтому мы решили вынести процессинг заказа в отдельный специализированный сервис. Чтобы определить, что выносить, а что оставлять, нужно было составить исчерпывающий и актуальный список процессов, которые происходят с заказом. И здесь мы столкнулись с вызовом: это знание распределено по многим людям и документам, поскольку на протяжении долгого времени в процессинг заказов вносили изменения многие команды. И перед нами встал вопрос — как собрать нужную информацию о системе с заметной долей легаси быстро, да так, чтобы информация была актуальна?
