TypeScript: компилятор молчит, продакшн падает

interface User {
    id: number;
    name: string;
}
const user: User = JSON.parse('{"id": 42}');

TS компилируется
В рантайме user.name undefined
TypeScript проверку прошёл, код вроде корректный. Но в рантайме обнаруживается, что обещанного поля нет.

TypeScript работает только на этапе разработки. В рантайме это просто JavaScript, которому всё равно, что там было в интерфейсе. JSON.parse вернул объект без name, и TS это пропустил.

Валидация данных на входе (zod, io-ts) или гарды типов вручную. TS доверяет, но проверять всё равно надо.

А в этом кейсе — кто виноват? Голосуйте в опросе 👇

#ИграКвиззИф

Тестирование как инструмент устойчивости продукта

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

🔷«А что будет, если пользователь сделает наоборот?»
🔷«А если данные придут с ошибкой?»
🔷«А если этим начнут пользоваться не так, как мы планировали?»

Эти вопросы — не формальность, а часть повседневной работы тестировщиков.

Тестирование — это работа с неопределённостью. Не с тем, как система должна работать в идеале, а с тем, как она поведёт себя в реальной жизни — с её отклонениями, нестандартными сценариями и человеческим фактором.

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

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

#ОбъясняетИФ

График пополз вниз. Без видимых причин.

SELECT * FROM orders WHERE user_id = 101

Память есть. CPU отдыхает. Сеть моргает зелёным.

А запрос встал колом. Мистика? 😱

Кто распутал бы такое — жмём опрос🫳

#ИграКвиззИф

Предсказание на сегодня

Предлагаем поиграть и узнать, с каким настроем пройдёт этот день (предсказание сбудется в день, когда бросили кубик).

Бросайте кубик в комментариях 🎲
Он выпадет случайным числом от 1 до 6: найдите его на карточке и посмотрите своё предсказание
Интересно, сбудется ли 👇

Какие подходы к ИИ существуют, где они применяются и как не ошибиться с выбором?

Разбираем:
🔵почему нейросети — не единственный, а часто и не лучший вариант;
🔵что умеют экспертные системы, семантические сети и роевой интеллект;
🔵как выбрать правильную архитектуру под конкретную бизнес-задачу.

Читать: https://ifrigate.ru/blog/nejroseti-ne-panaceya-razbiraem-vidy-ii-i-kogda-oni-realno-nuzhny

Интернет-Фрегат в MAX

#ОбъясняетИФ

Почему Python не ругается

def greet(name: str) -> str:
    return f"Hello, {name}"

Аннотации есть. Типы указаны. IDE подчёркивает. Но код запускается и...

Что увидим в консоли? Призрака? Ошибку? Число 42 в гостях у строки?😑

Пруфы в рантайме — в опросе 👇

#ИграКвиззИф

Три вида сложности: почему проект буксует

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

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

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

🔵Третье: социальная сложность - структура команды и ее организация. Зависимости возникают не из оргструктуры, а из общих ресурсов — кода, компонентов, базы данных, тестов, — поэтому разделение команды не даст автономности, если изменения затрагивают одну и ту же систему.

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

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

Интернет-Фрегат в MAX

#ОбъясняетИФ