Путь в IT #3 Как выжать максимум из проекта, который вы делаете?
Мы уже немного разбирали, как выбирать технологии для проекта. Сегодня хочу продолжить тему практики.
Когда вы пишете проект для своего обучения или уже работаете на коммерческом продукте, вполне логично изучать сам стек: как работает фреймворк, как подключить базу, как сделать интерфейс, почитать теорию по технологиям.
Но параллельно я советую прорабатывать архитектуру и дизайн системы.
Почему?
Я точно знаю, что вопросы про одновременные запросы, нагрузку, транзакции и сбои реально задают на технических и system design интервью. В том числе и в компаниях типа Revolut. Поэтому если вы хотите выжимать максимум из найма и выходить на крутые компании – эти темы нужно обязательно изучать и понимать.
Пусть слова “архитектура” и “system design” вас не пугают.
Это может звучать как что-то мегасложное. На деле в основе лежат вполне понятные вопросы. От позиции и компании зависит глубина обсуждения, но начинать можно с обычного учебного проекта.
Допустим, вы делаете сервис бронирования.
Человек зашёл, выбрал время, нажал кнопку. Всё отработало штатно.
А теперь задаём себе 10 вопросов 👇
1. Что будет, если два человека одновременно забронируют одно время?
Могут ли оба получить подтверждение? Где вы гарантируете, что одно место не достанется двум людям?
2. Что будет, если придёт сто человек? А тысяча?
Они просто смотрят страницы или одновременно создают брони? Где система начнёт тормозить и как вы это проверите?
3. Что будет, если пользователь не получил ответ и нажал кнопку ещё раз?
Первая операция могла уже выполниться. Как повторить запрос и не создать дубликат?
4. Что будет, если приложение сломается посередине операции?
Время уже помечено занятым, а бронь ещё не сохранилась. Как не оставить данные в таком состоянии?
5. Что будет, если внешний сервис перестанет отвечать?
Например, отправка писем. Должна ли из-за этого перестать работать запись? Сколько ждать ответа и что повторять после сбоя?
6. Что будет, когда данных станет в тысячу раз больше?
На десяти записях поиск быстрый. А на ста тысячах? Как найти медленный запрос и проверить, что ваши изменения действительно помогли?
7. Что будет, если данные в кеше устарели?
Вы показываете время как свободное, но его уже заняли. Где допустима задержка обновления, а где обязательно проверить актуальные данные?
8. Что будет, если запустить вторую копию приложения?
Продолжит ли работать защита от повторных операций? Что хранится только в памяти первой копии и потеряется при её перезапуске?
9. Что будет, если пользователь попробует отменить чужую бронь?
Не через интерфейс, а прямым запросом. Сервер действительно проверяет права или вы просто спрятали лишнюю кнопку?
10. Как вы узнаете, что что-то сломалось?
Какие показатели отслеживать? Когда должно прийти уведомление? Сможете ли по логам понять, почему конкретный пользователь не смог записаться?
Не нужно садиться и решать все десять пунктов за один вечер.
Возьмите один вопрос. Почитайте, какие есть варианты решения. Выберите подходящий для своего проекта и воспроизведите ситуацию в тестовом окружении.
Потом разберитесь: почему выбрали именно этот вариант, как проверили результат и какие ограничения остались.
Постепенно такие вопросы перестают казаться сложными и абстрактными. Вы уже понимаете, о чём речь, потому что сами с этим разбирались.
И на собеседовании у вас появляется конкретный разговор: вот проблема, вот моё решение, вот почему я сделал так и как убедился, что оно работает. 👌
