Engineering notes | Артур Илькаев

Hacking System Design Interview v.2

Заканчиваю серию постов – я сделал форк самого известного фреймворка по прохождению секции проектирования систем. Кстати, предыдущие посты можно прочитать здесь: проектирование приложения, проектирование Firebase SDK.

Зачем? Мне не нравится некоторые куски оригинального репозитория, а именно его конечный результат — спроектированные диаграммы. Я считаю их некачественными. Неясно, зачем вводятся те или иные компоненты и как они связаны. Кроме того, некоторые компоненты излишни или вообще не нужны (например, DI Graph, Coordinator).

Доклад с мобиуса “Как пройти архитектурную секцию собеседования” рассматривает лишь проектирование конкретного модуля конкретной фичи с заранее предлагаемый MV* паттерном: почему так? Как устроены остальные фичи? Как устроена связь между фичами? Как устроена многомодульность? Как пройти секцию, если тебя просят спроектировать библиотеку?

📌 Я перевел оригинальный фреймворк и дополнил его фича-модульной и чистой архитектурой, а также своими мыслями, как пройти данную секцию. В планах — перевести примеры с проектированием библиотек и дополнить их.

Крайне приветствуется:
1. Поставить звездочку;)
2. Контрибьютить и дополнять репозиторий.
https://github.com/iartr/mobile-system-design

GitHub

GitHub - iartr/mobile-system-design: Фреймворк для прохождения System Design интервью

Фреймворк для прохождения System Design интервью. Contribute to iartr/mobile-system-design development by creating an account on GitHub.

www.group-telegram.com/us/artrblog.com/23

2.4K viewsedited  Jan 7, 2024 at 09:02

Hacking System Design Interview v.2

Заканчиваю серию постов – я сделал форк самого известного фреймворка по прохождению секции проектирования систем. Кстати, предыдущие посты можно прочитать здесь: проектирование приложения, проектирование Firebase SDK.

Зачем? Мне не нравится некоторые куски оригинального репозитория, а именно его конечный результат — спроектированные диаграммы. Я считаю их некачественными. Неясно, зачем вводятся те или иные компоненты и как они связаны. Кроме того, некоторые компоненты излишни или вообще не нужны (например, DI Graph, Coordinator).

Доклад с мобиуса “Как пройти архитектурную секцию собеседования” рассматривает лишь проектирование конкретного модуля конкретной фичи с заранее предлагаемый MV* паттерном: почему так? Как устроены остальные фичи? Как устроена связь между фичами? Как устроена многомодульность? Как пройти секцию, если тебя просят спроектировать библиотеку?

📌 Я перевел оригинальный фреймворк и дополнил его фича-модульной и чистой архитектурой, а также своими мыслями, как пройти данную секцию. В планах — перевести примеры с проектированием библиотек и дополнить их.

Крайне приветствуется:
1. Поставить звездочку;)
2. Контрибьютить и дополнять репозиторий.
https://github.com/iartr/mobile-system-design

BY Engineering notes | Артур Илькаев