Инструменты меняются, а база вечна - почему мы учим не то?

Замечаю в последнее время опасный тренд среди коллег. Все бросились "дрюкать" синтаксис SQL, зазубривать принципы REST API, разбираться в конфигурациях RabbitMQ и Kafka. Безусловно, это полезные технологические навыки.

Но за этим фасадом модных инструментов часто скрывается полная стагнация в фундаментальных знаниях.

Когда открываешь архитектуру современных проектов, там часто творится полный "приехали родственники из дальнего севера". Система обвешана самыми трендовыми фреймворками, но при этом базовая модель данных трещит по швам.

Если вы хотите расти как инженеры, архитекторы, да и вообще как специалисты, а не просто закрывать тикеты, сместите фокус на базу, которая не устареет через три года: - ER-диаграммы и моделирование данных. Начните с проектирования. Если связь между сущностями изначально кривая, то никакой брокер сообщений не спасет систему от деградации производительности. Ошибки на этапе дизайна стоят дороже всего. - Принципы ACID. Поймите, как на самом деле работают транзакции, изоляция и надежность, прежде чем писать высоконагруженный бэкенд. - OLAP vs OLTP. Разберитесь в природе нагрузок. Это убережет от катастрофических архитектурных ошибок, когда аналитические тяжелые запросы пытаются гонять на транзакционных базах, намертво вешая прод. - Современная Data-архитектура. Если чувствуете силы - копайте глубже. Разберитесь, что такое партицирование в Apache Spark, как устроен GreenPlum, в чем концептуальная разница между Data Warehouse, Data Lake и LakeHouse.

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

Инструменты меняются, а база вечна - почему мы учим не то? | Сетка — социальная сеть от hh.ru Инструменты меняются, а база вечна - почему мы учим не то? | Сетка — социальная сеть от hh.ru