Инструменты меняются, а база вечна - почему мы учим не то?
Замечаю в последнее время опасный тренд среди коллег. Все бросились "дрюкать" синтаксис SQL, зазубривать принципы REST API, разбираться в конфигурациях RabbitMQ и Kafka. Безусловно, это полезные технологические навыки.
Но за этим фасадом модных инструментов часто скрывается полная стагнация в фундаментальных знаниях.
Когда открываешь архитектуру современных проектов, там часто творится полный "приехали родственники из дальнего севера". Система обвешана самыми трендовыми фреймворками, но при этом базовая модель данных трещит по швам.
Если вы хотите расти как инженеры, архитекторы, да и вообще как специалисты, а не просто закрывать тикеты, сместите фокус на базу, которая не устареет через три года: - ER-диаграммы и моделирование данных. Начните с проектирования. Если связь между сущностями изначально кривая, то никакой брокер сообщений не спасет систему от деградации производительности. Ошибки на этапе дизайна стоят дороже всего. - Принципы ACID. Поймите, как на самом деле работают транзакции, изоляция и надежность, прежде чем писать высоконагруженный бэкенд. - OLAP vs OLTP. Разберитесь в природе нагрузок. Это убережет от катастрофических архитектурных ошибок, когда аналитические тяжелые запросы пытаются гонять на транзакционных базах, намертво вешая прод. - Современная Data-архитектура. Если чувствуете силы - копайте глубже. Разберитесь, что такое партицирование в Apache Spark, как устроен GreenPlum, в чем концептуальная разница между Data Warehouse, Data Lake и LakeHouse.
Изучение синтаксиса конкретной библиотеки - это бег на месте. Понимание того, как данные живут, трансформируются и хранятся физически - это и есть настоящее развитие. Развивайтесь концептуально, а не стагнируйте в рамках одного фреймворка ибо нех*й.
· 28.07
Да, синтаксис можно добить за вечер, а вот умение понять границы системы - месяцами. В проде обычно важнее data flow, failure modes и ownership, чем знание очередного брокера. Вы специально проверяете это кейсами или надеетесь, что оно всплывёт само?
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 28.07
Если говорить с точки зрения проектирования инфраструктуры то границы выстаивате вы самостоятельно как архитектор/анатилик. Да в проде важно другое опять же в проектировании вам нужно сразу понимать где, как, будут храниться данные и предсказывать будущее разширение (или сжатие). Все сказаное в посте проверено лично.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён