Юрий Белк – Full stack Developer (страница 23)
– Go строгий, но типовая система проще: меньше «выразительных конструкций», зато меньше сюрпризов.
5.4. Экосистема библиотек
Комментарий:
– Python выигрывает в data/ML и автоматизации.
– Java выигрывает в энтерпрайзе и интеграциях «как в банке».
– Go выигрывает в инфраструктуре и сетевых утилитах.
5.5. Наблюдаемость, диагностика, профилирование
Комментарий:
Java особенно сильна в эксплуатации больших систем: много стандартных инструментов, привычных практик. Go тоже очень неплох благодаря pprof и предсказуемому рантайму. Python требует более аккуратной инженерии (особенно при async).
5.6. Найм и доступность инженеров
Комментарий:
Python знают многие, но «Python для продакшена под нагрузкой» – уже не у всех. Java-инженеров много и часто с опытом больших систем. Go-инженеров меньше, но они часто приходят из high-load или инфраструктуры.
5.7. Риски и типовые «подводные камни»
Итог: как пользоваться этими главами
Если вы выбираете язык под сервис, задайте себе несколько честных вопросов:
1) Сколько лет будет жить система?
2) Насколько сложная доменная логика?
3) Какая нагрузка и какие требования к latency?
4) Насколько важны быстрые итерации и прототипы?
5) Какая у вас команда сейчас и кого реально нанять через 3–6 месяцев?
Дальше выбор обычно становится понятнее.
А если всё равно сложно – это нормально: иногда правильный ответ звучит так:
«Мы берём язык, который команда умеет эксплуатировать без героизма».
Итог: как пользоваться этими главами
Если вы выбираете язык под сервис, задайте себе несколько честных вопросов:
1) Сколько лет будет жить система?
2) Насколько сложная доменная логика?
3) Какая нагрузка и какие требования к latency?
4) Насколько важны быстрые итерации и прототипы?
5) Какая у вас команда сейчас и кого реально нанять через 3–6 месяцев?
Дальше выбор обычно становится понятнее.
А если всё равно сложно – это нормально: иногда правильный ответ звучит так:
«Мы берём язык, который команда умеет эксплуатировать без героизма».
Раздел II. Продукт и требования, единые для всех реализаций.
Ниже три главы одного раздела. Я буду писать так, чтобы это можно было взять как «техническое ТЗ для людей», а не как абстрактную теорию. Мы сначала договоримся что строим, затем – какие системные требования важны, и только потом – зафиксируем API-контракт до кода.
Глава 6. Домен TaskFlow: что строим
TaskFlow – это сервис управления задачами. Если очень коротко: “таски, проекты, комментарии, поиск, роли”. Если чуть длиннее – это маленькая копия того, что люди используют каждый день: Trello/Jira/Asana, но в более компактном виде и с понятным доменом, удобным для обучения.
Мы будем мыслить продуктом: не «сделать таблицы», а «помочь людям работать».
6.1. Главная идея продукта
У пользователя есть рабочие пространства (Workspace). Внутри них – проекты (Project). В проектах – задачи (Task), у задач – комментарии (Comment) и метки (Label).
Плюс обязательные вещи, без которых любой сервис задач быстро превращается в грустный список:
– регистрация и логин,
– права доступа,
– поиск и фильтрация,
– понятные ошибки в API,
– нормальная пагинация,
– аудит действий (кто что сделал).
Опционально (но мы предусмотрим место в дизайне):
– прикрепления файлов,
– уведомления (email/webhook).
> Важно: мы строим учебный, но реалистичный продукт. Поэтому всё, что “потом разберёмся”, мы хотя бы обозначим контрактами и моделями.
6.2. Сущности и их смысл
Ниже – не “таблицы базы данных”, а язык предметной области. Это сильно упрощает жизнь, когда вы будете писать код на любом языке.
6.2.1. User
User – это человек, который входит в систему.
Минимальные поля (логические):
– id – уникальный идентификатор
– email – логин (уникальный)
– password_hash – пароль в виде хеша (никогда не хранить “как есть”)
– name – отображаемое имя
– created_at, updated_at
Что важно сразу:
– email – уникальный.
– пароль не возвращаем через API никогда.
– имя может быть пустым или заполняться позже.