15708
Присоединяйтесь к нашему каналу и погрузитесь в мир Backend-разработки Связь: @devmangx РКН: https://clck.ru/3FobxK
Нашёл сегодня несколько совершенно безумных открытых репозиториев для Kubernetes.
Они автоматически генерируют архитектурные диаграммы:
1. KubeDiagrams
Строит диаграммы из манифестов, Helm, Kustomize или текущего состояния кластера.
[https://github.com/philippemerle/KubeDiagrams]
2. k8sviz
Читает текущее состояние namespace и генерирует диаграмму через Graphviz.
[https://github.com/mkimuram/k8sviz]
3. k8s-diagrams
Написан на Go и получает данные напрямую через Kubernetes API.
[https://github.com/trois-six/k8s-diagrams]
4. GruCloud
Генерирует код и диаграммы для AWS, Azure, GCP и Kubernetes.
[https://github.com/grucloud/grucloud]
5. k8s-to-diagram
Превращает аннотации в манифестах в диаграмму взаимодействия сервисов.
[https://github.com/kocierik/k8s-to-diagram]
👉 @BackendPortal
Чтобы хорошо разобраться в Kubernetes, свой кластер не обязателен.
Нашёл репозиторий с 50 практическими лабораторными по Kubernetes, которые можно запускать прямо в браузере.
→ работа с kubectl вместо простого чтения документации
→ Pods, Deployments, StatefulSets, DaemonSets
→ HPA, scheduling, taints и tolerations
→ RBAC, Secrets, namespaces и quotas
→ Services, Ingress и реальные сценарии отладки
В браузере поднимается настоящее Kubernetes-окружение, а задания построены вокруг практической работы.
Просто открываете лабораторную и начинаете ломать вещи.
Репозиторий:
https://github.com/labex-labs/kubernetes-practice-labs
👉 @BackendPortal
Если достаточно долго работать с базами данных, рано или поздно столкнёшься с проблемами подключений или параллелизма.
В такой ситуации не стоит просто повышать лимиты в конфигурации. Лучше разобраться в архитектуре, чтобы понимать, почему это происходит и как исправить проблему оптимальным способом.
Эта статья от гениального человека — отличный разбор управления подключениями в Postgres и возможных решений.
Легко свести всё к особенностям Postgres с отдельным процессом на каждое соединение, но похожие проблемы могут возникать и в других базах данных, включая MySQL.
Часто ответ кроется в пуле подключений, но и он добавляет свою сложность, которую тоже важно понимать.
Статье уже 8 лет, но для Postgres она остаётся актуальной и в 2026 году.
Ссылка ниже.
https://brandur.org/postgres-connections
👉 @BackendPortal
Algorithms Джеффа Эриксона — одна из лучших книг по алгоритмам.
Иллюстрации в ней просто отличные. Очень рекомендую.
https://jeffe.cs.illinois.edu/teaching/algorithms/
👉 @BackendPortal
Криптография — одна из недооценённых сильных сторон Go.
Стандартная библиотека включает множество криптографических алгоритмов. Все они хорошо написаны, подробно документированы, достаточно компактны и тщательно проверены.
Некоторые из них ещё и очень быстрые.
Например, для одного из этапов SHA-256 Go использует платформенно-зависимый ассемблер.
Моя реализация на Solod даже с Arm-интринсиками SHA-2 работает примерно на 10% медленнее. А если использовать только чистый Solod-код, то есть обычный C, она медленнее примерно в 7 раз.
Криптография в Go сделана исключительно хорошо.
👉 @BackendPortal
Т-Банк собирает бэкенд-комьюнити на JVM Day
Бэкендеры, 29 августа в Москве пройдет конференция, где соберутся Java-, Scala- и Kotlin-разработчики, архитекторы и тимлиды.
На конференции разберут:
- Актуальные тренды JVM — Loom, конкурентность, автоматизацию миграций и связанные ограничения
- Реальные кейсы внедрения с разбором ошибок, которые мешают довести прототип до production‑уровня
- Подходы к конкурентности в Java после Loom
- То, как новые возможности JVM влияют на архитектуру бэкенд‑систем
Будет зона с решениями разных компаний, где участники смогут обсудить опыт использования продуктов напрямую с разработкой.
А вечером во дворе штаб-квартиры Т-Банка все соберутся за большим столом, будут игры на Sega, xxxl-кикер и открытый микрофон с историями ошибок.
Успевай зарегистрироваться
Одна строка в неправильном месте вызывает большинство багов в DFS.
Отмечайте узел как посещённый в момент входа в него:
- Рекурсивный DFS → первая строка функции
- Итеративный DFS → когда добавляете узел в стек, а не когда достаёте его
Нарушите это правило — и цикл превратится в бесконечную рекурсию: один и тот же узел окажется в стеке несколько раз.
👉 @BackendPortal
😲 Серьёзно? Отправлять уведомления на телефон или компьютер можно обычным HTTP-запросом.ntfy — бесплатный open source-сервис, который позволяет мгновенно отправлять push-уведомления из скриптов, серверов, приложений, cron-задач или ИИ-агентов всего одним HTTP-запросом.
Подойдёт для:
* долгих скриптов;
* завершения задач ИИ-агентов;
* CI/CD-пайплайнов;
* мониторинга серверов;
* деплоев и резервного копирования;
* автоматизаций и многого другого.
Если часто что-то автоматизируете, стоит обратить внимание.
GitHub: github.com/binwiederhier/ntfy
👉 @BackendPortal
По умолчанию Postgres считает столбцы, которые вместе используются в WHERE, независимыми друг от друга.
Например, для такого SQL-запроса:
SELECT *
FROM world
WHERE country = 'Japan'
AND continent = 'Asia';
country = 'Japan' равна 0,02, а continent = 'Asia' — 0,4. Тогда общую селективность планировщик оценит как 0,008.country = 'Japan'.CREATE STATISTICS для них вместе, а затем запустить ANALYZE.CREATE STATISTICS планировщик спрогнозировал 1983 строки — гораздо ближе к реальному результату.
Кэшировать или не кэшировать?
Это вопрос, с которым бэкендер сталкивается каждый день.
Большинство инженеров кэшируют слишком много.
Это ленивая инженерия.
Вот небольшой фреймворк, чтобы принимать решение правильно:
I. Данные часто запрашиваются?
II. Их дорого получать?
III. Они изменчивые?
IV. Объём данных большой?
V. Влияет ли это на воспринимаемую пользователем задержку?
VI. Безопасно ли кэшировать?
VII. Есть ли механизм протухания или инвалидации кэша?
👉 @BackendPortal
Добро пожаловать в мир разработки
Проект «TERMINAL» стал крупнейшей библиотекой бесплатного образования. В одном канале собраны курсы, книги, полезные инструменты и практические тренажёры для всех разработчиков
🎓 Практические курсы и задания
🪽 Книги и статьи известных авторов
😮💨 Полезные инструменты и ресурсы
🌟 IT-новости и инсайды
Обучение по всем направлениям: SQL, Python, ML, Frontend, PHP, C++, Go, GIT, Linux, QA, Java, Vibe-coding, Infosec и др.
Ценишь знания, подпишись: Terminal_tg
Покрывающий индекс содержит все столбцы, которые нужны запросу.
Сюда входят как поля для фильтрации и сортировки (ключ индекса), так и дополнительные поля, которые нужны в SELECT. Их можно добавить через INCLUDE.
Ищите в плане выполнения строку:Heap Fetches: 0
Это означает, что PostgreSQL смог выполнить запрос полностью из индекса и не обращался к основной таблице (heap).
👉 @BackendPortal
Лучшие инженеры не изучают распределённые системы по поверхностным пересказам. Они сразу обращаются к фундаментальным научным статьям. Чтение таких работ помогает понять, почему системы спроектированы именно так, а не просто научиться ими пользоваться.
Вот пять классических статей всех времён, которые должен прочитать каждый разработчик.
1. The Google File System (2003)
Почему стоит прочитать: статья изменила подход всей индустрии, предложив считать отказ компонентов нормой, а не исключением. В ней описано, как построить масштабную отказоустойчивую распределённую систему хранения данных на базе недорогого массового оборудования, оптимизировав её под интенсивную последовательную дозапись вместо произвольной записи.
Ссылка: https://static.googleusercontent.com/media/research.google.com/en//archive/gfs-sosp2003.pdf
2. Dynamo: Amazon’s Highly Available Key-Value Store (2007)
Почему стоит прочитать: исчерпывающий разбор того, как пожертвовать согласованностью ради высокой доступности — AP в теореме CAP. В статье изложены ключевые паттерны, лежащие в основе масштабируемых NoSQL-хранилищ: консистентное хеширование, векторные часы, gossip-протоколы и настраиваемый кворум для операций чтения и записи.
Ссылка: https://allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf
3. In Search of an Understandable Consensus Algorithm (Raft) (2014)
Почему стоит прочитать: Paxos печально известен тем, насколько сложно его понять и корректно реализовать, тогда как Raft делает концепцию реплицируемых конечных автоматов более доступной. Алгоритм разбивает задачу консенсуса на отдельные подзадачи, которые легко анализировать: выбор лидера, репликацию журнала и обеспечение безопасности.
Ссылка: https://raft.github.io/raft.pdf
4. Spanner: Google’s Globally-Distributed Database (2012)
Почему стоит прочитать: статья показывает, как добиться строгой сериализуемости и внешней согласованности между дата-центрами по всему миру. Секрет — API Google TrueTime, ограничивающий неопределённость времени с помощью синхронизированных GPS-приёмников и атомных часов.
Ссылка: https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf
5. Time, Clocks, and the Ordering of Events in a Distributed System
Почему стоит прочитать: на физическое время нельзя полагаться при работе с независимыми узлами. Лэмпорт вводит логические часы и фундаментальное отношение «произошло до» (happened-before), лежащее в основе упорядочивания событий в современных распределённых сетях.
Ссылка: https://amturing.acm.org/p558-lamport.pdf
👉 @BackendPortal
Fleetbase — опенсорсная модульная ОС для логистики и управления цепочками поставок.
Можно собирать свои решения для логистики, управлять доставками, оптимизировать маршруты и отслеживать заказы через API.
В общем, self-hosted логистика для тех, кому обычного CRUD уже недостаточно.
https://github.com/fleetbase/fleetbase
👉 @BackendPortal
Задержки это смерть от тысячи мелких порезов.
Так что чините. Начните с базы: один плохой запрос легко добавляет полсекунды, а на тысячах запросов это превращается в катастрофу. Не используйте SELECT *, добавляйте индексы, убивайте N+1 и всегда проверяйте запросы через EXPLAIN.
Дальше посмотрите на сетевые прыжки. Каждый переход через цепочку сервисов добавляет задержку, поэтому мелкие сервисы иногда лучше объединить. Хорошая идея — использовать BFF.
Кэш тоже обязателен. Если данные не меняются, нет смысла тянуть их заново. Сессии, каталоги, конфиги — держите их горячими. Протухший кэш плохо, но отсутствие кэша почти всегда хуже.
Не отправляйте десятки мелких запросов последовательно. Объединяйте их в батчи или гоните параллельно, так результат приходит быстрее.
И не таскайте лишние данные. Убирайте ненужные поля, сжимайте ответы, делайте пагинацию и оптимизируйте картинки.
Скорость это не дополнительная фича, а фундамент нормального UX.
👉 @BackendPortal
Яндекс анонсировал deep tech night — конференцию о вызовах, с которыми IT-индустрия сталкивается в эпоху AI.
В программе — разговор о разработке, ML, инфраструктуре и данных на примере реальных инженерных задач.
Приглашенный спикер Мо Гавдат, ex-Chief Business Officer Google X, расскажет, как генеративные нейросети меняют будущее разработки, процессы и роли в командах. Алексей Гусаков, CTO Бизнес-группы Поисковых сервисов и ИИ в Яндексе, разберёт переход от классического ML к генеративным моделям в рекомендательных системах. А Сергей Мельник, руководитель сервиса автономного транспорта и роботов Яндекса, объяснит, как устроен физический ИИ — системы, которые принимают решения не в чате, а в реальном мире.
В онлайне будет доступен Hard-трек: трансляция технических докладов, Q&A-сессии с экспертами и запись после конференции будут бесплатны для зарегистрированных участников. Присоединяемся.
Узнать подробности про офлайн и зарегистрироваться на трансляцию можно на сайте.
Мгновенно клонируйте любую базу данных Postgres для быстрой разработки, тестирования и CI-пайплайнов.
https://github.com/postgres-ai/database-lab-engine
👉 @BackendPortal
Один из моих любимых инженерных блогов — DoltHub.
Их материал про prolly trees очень хорошо объясняет, как можно встроить контроль версий прямо в движок хранения: контентно-адресуемые узлы, структурное разделение данных, деревья, не зависящие от истории изменений, и diff, который пропускает неизменившиеся поддеревья вместо полного сканирования базы.
Особенно интересно сейчас следить за DoltLite — SQLite с нативным контролем версий.
Это не SQLite, к которому просто прикрутили таблицу с коммитами. DoltLite форкает SQLite на уровне btree.h: парсер, планировщик, VDBE и значительная часть привычного API sqlite3_* остаются, а нижележащий страничный B-tree заменяется на контентно-адресуемое prolly tree.
В результате коммиты, ветки, diff, построчный merge, clone, fetch, push и pull становятся операциями самой базы данных, а не логикой приложения.
Мне особенно нравится эта модель для локальной памяти ИИ-агентов.
Агент может создать ветку памяти перед экспериментом, посмотреть, что именно изменилось, слить полезное состояние и откатить всё остальное. Память превращается из очередного изменяемого blob в явное, проверяемое и воспроизводимое состояние.
DoltHub применяет ту же идею хранения сразу к нескольким интерфейсам баз данных:
Dolt — совместим с MySQL - https://github.com/dolthub/dolt
Doltgres — вариант под PostgreSQL - https://github.com/dolthub/doltgresql
DumboDB — совместим с MongoDB - https://github.com/dolthub/dumbodb
Разные интерфейсы и реализации, но одна идея: контроль версий должен находиться на уровне хранения данных.
Именно работа DoltHub во многом подтолкнула автора к созданию crabbuild/prolly — MIT-библиотеки prolly trees на Rust с асинхронным API, неизменяемыми упорядоченными картами, контентно-адресуемыми узлами, структурным разделением, снапшотами, быстрыми diff и merge, синхронизацией и подключаемыми хранилищами.
https://github.com/crabbuild/prolly
Есть биндинги для Python, Go, Java/Kotlin, Node, Ruby, Swift и WASM, а также адаптеры для SQLite, PostgreSQL, MySQL, Redis, DynamoDB, RocksDB, Turso, Spanner и других систем.
Идея здесь не в создании ещё одной базы данных.
Цель — сделать саму примитивную структуру переиспользуемой, чтобы на её основе можно было строить версионируемую память агентов, графы кода, воспроизводимые RAG-снапшоты, local-first состояние или собственные системы контроля версий.
В этом и сила prolly trees: они превращают «контроль версий для X» из функции приложения в свойство самой структуры данных.
👉 @BackendPortal
Уже очевидно, что ВАЙБКОДИНГ — главный навык ближайших лет
Посмотрите сами. ИИ уже забирает на себя работу целых команд: пишет код, закрывает задачи джунов и позволяет стартапам запускать продукты в 2–3 раза меньшим составом. То, на что раньше нужны были несколько разработчиков, сегодня всё чаще делает один человек с ИИ-агентами.
И это только начало. Те, кто освоит вайбкодинг сейчас, смогут быстрее запускать проекты, автоматизировать огромный объём работы, увереннее конкурировать на рынке и зарабатывать больше тех, кто продолжает делать всё вручную.
Начать с нуля поможет канал Вайб-кодинг. Там ребята круглосуточно мониторят более 320 российских и зарубежных источников и публикуют только главное: релизы, инструменты, гайды, курсы и практические кейсы.
Подписывайтесь, нас уже 50 тысяч: @vibecoding_tg
5 советов по Docker, которые сэкономили бы мне полгода на борьбу с раздутыми образами.
1. Используйте slim-образыpython:3.11-slim вместо python:3.11.
Размер образа может сократиться примерно с 1 ГБ до 150 МБ.
2. Правильно располагайте инструкции в Dockerfile
То, что меняется редко, размещайте в начале.
Код приложения — ближе к концу.
Так кэш Docker используется эффективнее, а сборка проходит быстрее.
3. `.dockerignore` — это не опция
Добавьте туда node_modules, .git, тестовые файлы и всё лишнее.
Никогда не копируйте их в образ.
4. Используйте многоэтапные сборки
Собирайте приложение на одном этапе, а в финальный образ копируйте только готовый результат.
Инструменты сборки не должны попадать в продакшен.
5. Проверяйте образ перед публикацией
trivy image myapp:latest
MIT 6.824 (распределённые системы) — один из лучших бесплатных инженерных курсов в интернете.
Вместо чистой теории весь курс построен вокруг чтения и разбора фундаментальных работ из реальных систем:
GFS (Google File System) — архитектура с одним главным узлом, распределение чанков и работа с eventual consistency при больших нагрузках на добавление данных.
Raft — выбор лидера, репликация журнала и инварианты безопасности. Алгоритм разбирается намного доступнее, чем Paxos.
ZooKeeper — координация без блокировок, системы с преобладанием чтения, линейно согласованные записи и eventual consistency для чтений через watches.
Spanner — глобально распределённые транзакции, двухфазный commit поверх Paxos и использование TrueTime (атомные часы + GPS) для обеспечения внешней согласованности.
Также в курсе разбираются MapReduce, Spark, Frangipani, Memcached от Facebook и другие системы.
Если хотите выйти за пределы поверхностного system design и понять, как внутри устроены реальные распределённые хранилища и системы консенсуса, этот курс — настоящий клад.
Плейлист: https://youtube.com/playlist?list=PLrw6a1wE39_tb2fErI4-WkMbsvGQk9_UB
👉 @BackendPortal
PostgreSQL 19 ускоряет INSERT до 2 раз
В PG 19 появился быстрый путь (fast path), который может напрямую проверять связанный уникальный индекс, избегая более тяжёлого пути через SPI-запросы.
Результат:
→ Более быстрая проверка внешних ключей
→ Меньше накладных расходов на каждую вставленную строку
→ До 2× выше производительность INSERT при использовании внешних ключей
→ Более заметный прирост при массовой загрузке данных
Схема базы остаётся прежней.
Ограничения целостности сохраняются.
База данных просто выполняет меньше работы.
Тот же INSERT. Та же целостность данных. Почти в два раза выше скорость.
👉 @BackendPortal
Если в PostgreSQL у вас до сих пор используется SERIAL PRIMARY KEY, стоит проверить, насколько вы близки к пределу последовательности.SERIAL — это сокращение для автоинкрементного INT, который заканчивается на 2 147 483 647. После достижения этого значения новые вставки завершатся ошибкой:
ERROR: nextval: reached maximum value of sequence "orders_id_seq" (2147483647)
ALTER SEQUENCE orders_id_seq
NO MINVALUE
START WITH -1
INCREMENT -1
RESTART;
BIGINT.ALTER COLUMN ... TYPE bigint, поскольку он переписывает всю таблицу под тяжёлой блокировкой. Вместо этого рекомендуется выполнить поэтапную миграцию с атомарной заменой: заранее создать новый столбец и индекс, перенести данные и внешние ключи, а затем в короткой DDL-транзакции переключить первичный ключ.
id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY
INT, а GENERATED ALWAYS оставляет управление последовательностью за PostgreSQL.
Большинство воспринимает Spring Boot просто как фреймворк для создания REST API.
Но за ним скрывается гораздо более крупная экосистема 👇
• Spring Core и внедрение зависимостей
• Spring MVC и WebFlux
• JPA, Hibernate и базы данных
• Безопасность с JWT и OAuth 2.0
• Kafka и RabbitMQ
• Redis и распределённое кэширование
• Docker, Kubernetes и облачные платформы
• Мониторинг с Actuator, Prometheus и Grafana
Spring Boot упрощает настройку проекта, а понимание всех стоящих за ним уровней помогает стать сильнее как бэкенд-разработчик.
Фреймворк позволяет быстро начать работу.
Экосистема помогает создавать приложения для продакшена.
#SpringBoot #Java #Backend #SoftwareEngineering #Microservices #DevOps
👉 @BackendPortal
Большинство проблем с производительностью упираются в то, как вы работаете с памятью.
И эта статья до сих пор остаётся одним из лучших материалов по теме:
• Как на самом деле работает оперативная память
• Кеши процессора и почему от них так сильно зависит производительность
• Практические методы оптимизации
• Инструменты для измерения того, что реально происходит в системе
Автор — Ульрих Дреппер из Red Hat.
Материалу почти 20 лет, но он до сих пор актуален.
Доступно бесплатно:
https://people.freebsd.org/~lstewart/articles/cpumemory.pdf
👉 @BackendPortal
GoProxy — это высокопроизводительный прокси-сервер с поддержкой HTTP, HTTPS, SOCKS5 и SS-протоколов.
Он умеет делать балансировку нагрузки между прокси, пробрасывать TCP/UDP-порты и создавать SSH-туннели.
Также его можно использовать как reverse proxy, чтобы открывать доступ к локальным сервисам, которые находятся за NAT или файрволом.
https://github.com/snail007/goproxy
👉 @BackendPortal
Автор pgrust — PostgreSQL, переписанного на Rust, — рассказал о четырёх распространённых причинах сбоев PostgreSQL:
1. VACUUM и переполнение счётчика идентификаторов транзакций
2. Лимиты подключений и модель «один процесс на подключение»
3. Неудачные планы выполнения запросов — интересно, насколько здесь помогут новые хинты для запросов в PostgreSQL 19
4. Статистика для JSON
Я потратил некоторое время на изучение первых двух проблем, но с двумя последними знаком хуже.
Раздел о JSON оказался интересным. Любопытно, устраняют ли расширения PostgreSQL вроде DocumentDB некоторые из этих ограничений.
Стоит прочитать, если вы работаете с PostgreSQL.
https://malisper.me/the-four-horsemen-behind-thousands-of-postgres-outages/
👉 @BackendPortal
Несколько алгоритмов, которые я периодически заставляю себя повторять, чтобы не забыть, как они работают:
• Kadane’s → максимальная сумма подмассива
• Rabin–Karp → поиск подстроки с помощью хеширования
• Topological Sort → топологическая сортировка DAG
• Prim’s → минимальное остовное дерево
• Kruskal’s → MST с Union-Find
• Dijkstra’s → кратчайший путь без отрицательных весов
• Bellman–Ford → кратчайший путь с отрицательными весами
• Tarjan’s → компоненты сильной связности
• Backtracking → решение Sudoku
К этим алгоритмам я продолжаю возвращаться даже спустя годы.
А какие алгоритмы вы до сих пор периодически повторяете?
👉 @BackendPortal
• Друзья, пришло время провести очередной конкурс. На этот раз мы разыгрываем бумажную версию книги "The Ultimate Kali Linux Book" - это новое издание книги по изучению Kali Linux, которое перевели на русский язык.
• К слову, книга содержит более 800 страниц информации и будет полезна как новичкам, так и опытным специалистам.
• Итоги подведём 8 августа в 10:00, при помощи бота, который рандомно выберет 8 победителей. Доставка для победителей бесплатная в зоне действия СДЭК. Удачи ❤
Для участия нужно:
1. Быть подписанным на наш канал: Infosec.
2. Подписаться на канал наших друзей: Мир Linux.
3. Нажать на кнопку «Участвовать»;
4. Ждать результат.
Бот может немного подвиснуть — не переживайте! В таком случае просто нажмите еще раз на кнопку «Участвовать».
#Конкурс
Facebook настолько не устраивал Git, что в итоге компания создала ему сразу три замены.
Начиналось всё как у многих: один огромный monorepo, в котором лежал код всех команд.
По мере роста кодовой базы Git начал сдавать. Обычный git fetch мог занимать до 30 минут. Инженеры тратили больше времени на ожидание Git, чем на написание кода.
Facebook обратился к мейнтейнерам Git с вопросом, как масштабировать такую систему.
Ответ был простой: разбить репозиторий на несколько поменьше.
Для Facebook это не подходило. Весь смысл был именно в monorepo.
Тогда инженеры обратили внимание на менее популярный Mercurial. Его было проще расширять, а сообщество охотнее принимало изменения. Facebook перенёс туда всю кодовую базу и помог превратить Mercurial в один из лучших вариантов для огромных monorepo.
Но со временем и Mercurial упёрся в ограничения.
Тогда Facebook написал собственную систему контроля версий с нуля — Sapling.
А когда кодовая база выросла настолько, что один инженер уже физически не мог скачать её целиком на ноутбук, появился EdenFS — виртуальная файловая система, которая подгружает файл только в тот момент, когда разработчик реально его открывает.
Три замены. Одна компания. И всё потому, что кодовая база росла быстрее, чем успевали масштабироваться существующие системы контроля версий.
Большинство компаний подстраивают рабочие процессы под доступные инструменты.
Facebook просто создаёт новые инструменты, когда старые перестают справляться.
👉 @BackendPortal