🧬 System Design: Ресурсный инженер

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

Следующий месяц я буду копать в сторону систем дизайна. Попробуем углубиться и улучшить текущие знания. Начнем разбирать бессмертные принципы, а не отвлекаться на тренды.

В книге "Mobile System Design" Тьёрд ин ’т Веен разбирает важную модель идеального кандидата. Он, также как и все, акцентируется на критериях оценки и что не бывает идеальных решений. Всё зависит от условий и контекстов.

В идеальном интервью систем дизайна никто не должен оценивать как ты выдаешь идеально заученный шаблон. Хорошее интервью оценивает процесс поиска решений * результат. И если, из двух переменных, у тебя 0, то результат умноженный на 0 будет 0.

Что подразумевается под “ресурсным инженером”?

🧬Находчивость и гибкость.
Инженер должен уметь находить решение в условиях неопределенности. Если кандидат уверенно начинает свой рассказ, то старайте давать ему все более необычные условия. Чтобы оценить как он адаптируется к изменяющимся требованиям и ситуациям.

🧬Глубокое понимание задачи.
Кандидат должен не просто реализовать фичу, а разобраться в деталях, предусмотреть крайние случаи и потенциальные проблемы. Задавать вопросы, чтобы выявить скрытые требования.

Если он молча или сразу без обсуждений выдает результат, то это плохой кандидат.

🧬Рациональность в разработке.
Нужно оценивать, что инженер создаст простой, но гибкий код без чрезмерного усложнения. Избегание over-engineering'а.

🧬Работа в команде.
Оценивайте как инженер взаимодействует с дизайнерами, менеджерами и другими инженерами для достижения общего результата. Как он понимает влияния собственных решений на всю систему.

“Ресурсный инженер” (Resourceful Engineering) — это специалист, который не просто решает задачи, а делает это с умом, гибкостью и вниманием к деталям, обеспечивая устойчивость и масштабируемость системы. Интервьюеры ценят не заученные ответы, а умение задавать правильные вопросы. Например, если вам дают задание — уточняйте детали, это покажет вашу глубину мышления.

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

System Design: Почему эта тема важна

Теперь просто делать кнопку для айфона — уже недостаточно для повышения. Осидеться SUI-кнопкокрасом не получится. Чтобы расти как инженер, нужно уметь выпускать фичу сразу на всех платформах, договариваться с командой, искать компромиссы, предлагать разные варианты решений, учитывать бэкенд и соседние платформы.

Бизнес теперь платит за результат. Чем больше инструментов, платформ и навыков ты освоишь для его достижения, тем выше твои шансы на рост.

Вокруг мобильного системного дизайна много заблуждений. Теперь каждый ментор или инженер без опыта пытается объяснять его по-своему, искажая суть:
- Думают, что выбор между MVC/MVP и другими паттернами — это уже системный дизайн.
- Уверены, что это просто пересказ SOLID, DRY и Clean Code.
- Спорят о правильной реализации DI, как будто это главное.
- Считают, что System Design нужен только бэкенд-разработчикам.
- Зубрят один готовый шаблон решения только для прохождения собеса.

Но все это только маленькие детали большой картины.

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

Тема сис.диза — максимально похожа на реальную задачу. Ты должен собрать множество требований и согласовать максимально рабочую, простую систему.

Вот несколько причин, почему System Design важен для мобильных разработчиков:

🟣 Масштабируемость – приложения могут быстро набирать миллионы пользователей, и система должна выдерживать нагрузку.
🟣 Производительность – важно учитывать скорость загрузки и оптимизацию запросов, так как ресурсы мобильных устройств ограничены.
🟣 Сеть – приложения работают в условиях слабого или нестабильного интернета, поэтому нужно продумывать офлайн-режим, кэширование и минимизацию запросов.
🟣 Безопасность – данные пользователей должны быть защищены, API – безопасными, а система – устойчивой к атакам.
🟣 Синхронизация – приложения часто используют облачные сервисы, поэтому важно правильно организовать обмен данными между клиентом и сервером.
🟣 Тестирование – хорошая архитектура упрощает проверку системы и снижает вероятность багов.

Мобильным разрабам важно шарить в сисдизе, чтобы делать быстрые, стабильные и удобные приложения, работающие без проблем даже с ограничениями мобильных устройств.

Подборка мок-интервью по mobile system design

Иногда, между книгами и задачами, очень полезно посмотреть чужие видео. Так ты структурируешь свои идеи, которые отложились фрагментами. А где-то можешь и вдохновиться новыми.

Сделал подборку интересных мок-интервью:

🟣Design Story Viewer. Сторисы почти незаменимая деталь любого приложения. Поэтому вероятность, что вы когда-нибудь будете их делать — высокая.

🟣Chat App. Чат — любимая задача на интервью. В ней правда есть многое, что поможет оценить насмотренность и глубину.

🟣Design the Facebook feed. Лента встречается почти в 99%. Очень полезно посмотреть как ее проектируют сеньоры из FAANG'а

🟣Мок-дизайн приложения. Наш друг Саша Сычев из Яндекса поделился форматом интервью и какие оценки кандидата в этой секции есть в СНГ.

Ну и напомню, что у нас в закрытой базе есть несколько уникальных интервью, а также материалы из марафона проектирования.

Получить это можно по скидке 💰 тут или ⭐️ тут

Цикл про System Design: Как определять требования к системе

Самый важный этап, который недооценивают многие. Что на работе, что на интервью.

В этом цикле мы начнем углубляться в систем дизайн/архитектуры/проектирования. Эта тема очень актуальная, тк рынок ИИ сильно двигает инженеров в сторону понимания системы целиком.

Так и систем дизайн это максимально похожая на практику дисциплина. Инженеры перестали быть узкими спецами и становятся дирижерами оркестра или тимлидами аи-инструментов.

В первом блоке разберем что такое систем дизайн и почему этап сбора требований очень важный:
🟣мы поймем в чем отличие продуктовых, функциональных и нефункциональных требований
🟣лучшие практики для сбора требований
🟣почему этот этап влияет на конечный результат и сроки
🟣как важно качество наших вопросов
🟣почему не стоит шаблонно отвечать
🟣какие ментальные модели помогут инженеру делать хорошие системы

Статьи полезны тем, кто хочет изучить или улучшить свои навыки сбора требований.

🧬 Получить материалы вы можете 💰 тут или ⭐️ тут

System Design: Методики сбора требований

Нашу компетенцию чаще оценивают только по срокам.

Говоря, что сбор требований является важнейшей частью разработки, я не шутил. Много раз замечаю как у меня и других разрабов в больших компаниях это главная причина срыва сроков. А где-то причина, почему они не могут получить повышения или даже увольнения.

Коммерческая разработка — это не творчество. Здесь мы помогаем строить бизнес-процессы и зарабатывать/экономить деньги и время. Инженеру нужно с головой выбирать решения, которые найдут компромисс между качеством, скоростью и стоимостью.

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

Хорошего инженера от плохого отличает точность оценки сроков. Джуны обычно многое недооценивают и погружаясь в задачу упускают множество деталей. Чаще это из-за отсутствия опыта. У мидлов же это потому, что невнимательно относятся к процессу проработки требований. Не уточняют у продукта вводные или у соседних платформ их особенности, скидывая это на лидов, аналитиков и тп. Плохой же сеньор может обладать крутой экспертизой, но совсем не учитывать потребности бизнеса или не иметь навыки коммуникации. Но все это ответственность хорошего разраба.

Чуть подробнее мы говорили об этом в посте про ресурсного инженера.

Вот несколько методик для качественных ресерчей:

🟣Интервью с заказчиками и пользователями
Не бегите сразу клепать экран. Если вы услышали мяуканье, то это не значит, что перед вами кошка. Возможно это тигр, что разорвет вам жопу. Разработка занимает чаще лишь 20-30%, а остальное время проработка требований и краевых условий.

Уточники у заказчиков чего они хотят. Как будет вести себя программа без данных или условий.

🟣Методика “5 Почему” (5 Whys)
Чаще всего многие вопросы вскрываются в процессе разработки. Но лучше бОльшую часть попытаться заранее предусмотреть. Качественный ресерч от плохого зависит насколько много инженер задал вопросов перед разработкой.

В отмеченной статье кратко объясняется как техника отлично помогает это сделать.

🟣User Story
Отличная практика ставить себя на место пользователя и видеть его сценарии. Перебирать в голове разные пути на реакции системы. Например, что будет если не оказалось интернета? Если произошла ошибка с сервера? Как онлайн получить или синхронизовать информацию?

Качественный и понятный команде ресерч — это черта хорошего инженера.

Делитесь своими методиками.

Изучаем как собирать нефункциональные требования для разработки мобильных приложений

В комментариях прошлого поста написали "почему разработчик должен задумываться о требованиях, если есть лид или аналитик?". Это очень популярное заблуждение, ему придерживался и я сам.

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

Во-вторых, никто, кроме инженера, не сможет учесть множество особенностей своей платформы. На то он и эксперт, что взяв под ключ фичу, продумывает и подсвечивает все риски. Суть систем дизайна не сделать программу по готовой схеме от аналитиков и тимлидов. А собрать требования и подсветить их самому.

Здесь одни из требований — это нефункциональные требования.

Помимо функционала, важны характеристики, определяющие качество приложения — производительность, безопасность, масштабируемость, удобство использования и т.д.

Эти требования не говорят ЧТО нужно сделать, а скорее КАК. Такие требования помогают сделать нашу фичу стабильной и понятной в использовании. Автор делится ключевыми требованиями для мобильных инженеров:

🟣Performance. Как сделать приложение более плавным, быстрым.
🟣Security. Сделать приложение более безопасным. Использовать ли HTTPS, Keychain, криптошифрование и тп
🟣Совместимость. Обсуждение на каких версиях будет использоваться приложение.
🟣Надежность. Нужен ли хэндлинг ошибок и их мониторинг.
🟣Поддерживаемость. Вопрос понятности и читаемости кода, модуляризации и CI/CD.

Интересно также почитать про лучшие практики.