Ты точно знаешь, что такое архитектура? 🤔
Недавно был на собесе и получил вопрос:
В комментарии выложу картинку, как выглядело моё лицо в тот момент 🙂.
Обычно такие вопросы задают с одной из двух целей.
1. Проверить самообладание.
Бизнес порой задаёт простые или странные вопросы, и важно уметь спокойно на них отвечать.
Помню, как на собесе кандидату задали простой вопрос, а он выдал: «РРЯЯЯЯЯЯЯ ВЫ ЧЕ ТУПЫЕ, НУ КТО ТАКОЕ СПРАШИВАЕТ, НУ ВЫ И КРИНЖ»
2. Проверить логику и базовые знания.
Именно на простых вопросах многие неожиданно сыплются.
Кажется, что это очевидно. Но попробуйте объяснить прямо сейчас не подглядывая 👀
Что такое архитектура? 🧱
Если совсем по-простому, то это чертёж системы.
Как в строительстве: прежде чем строить дом, архитектор рисует план — где стены, где двери, как всё соединяется, из каких материалов.
В IT всё то же самое: архитектура описывает из каких компонентов состоит система, как они взаимодействуют и почему именно так.
Зачем это знать аналитику?🤔
Ну, во-первых, чтобы меньше платить и не брать полноценного архитектора .
Если серьёзно, то как ты будешь проводить системный анализ в отрыве от самой системы? Любое решение проектируется внутри какой-то архитектуры, и не понимать как она устроена ну вообще никак.
Не понимаешь архитектуру → не понимаешь ограничения → пишешь требования, которые невозможно реализовать. Или реализовать можно, но потом всё ломается.
Самые популярные виды:
➡️ Монолит Вся система это один большой кусок. Логика, база и интерфейс лежат в одном месте.
На старте это просто и удобно, особенно если приложение небольшое. Но чем больше система растёт, тем тяжелее её масштабировать и менять.
➡️Микросервисы Система разбита на маленькие независимые сервисы, каждый отвечает за свою задачу. Главный плюс, если один сервис упал, остальные продолжают работать. Гибко и устойчиво.
Но есть нюансы: сервисов много, значит много интеграций, много мест где может что-то пойти не так, и отлаживать, деплоить и мониторить всё это заметно сложнее чем монолит.
Дальше уже идут архитектурные паттерны, в рамках которых можно реализовать ту или иную систему.
Что будет, если накосячить? 💀
Архитектурные ошибки самые дорогие.
Условный баг в коде исправишь за час. Неправильно выбранная архитектура может вскрыться через год и переделывать тогда дорого по времени и деньгам.
Именно поэтому архитектурные решения принимаются в самом начале и согласовываются со всеми заинтересованными сторонами.
А вам на собесах задавали базовые вопросы, от которых хотелось сказать «подержи моё пиво, ща тебе расскажу»? Делитесь в комментариях 👇
IT АНАЛитика | Подписаться
Недавно был на собесе и получил вопрос:
«А что такое архитектура? Зачем она вообще нужна?»
А почему солнце светит?
В комментарии выложу картинку, как выглядело моё лицо в тот момент 🙂.
Обычно такие вопросы задают с одной из двух целей.
1. Проверить самообладание.
Бизнес порой задаёт простые или странные вопросы, и важно уметь спокойно на них отвечать.
Помню, как на собесе кандидату задали простой вопрос, а он выдал: «РРЯЯЯЯЯЯЯ ВЫ ЧЕ ТУПЫЕ, НУ КТО ТАКОЕ СПРАШИВАЕТ, НУ ВЫ И КРИНЖ»
2. Проверить логику и базовые знания.
Именно на простых вопросах многие неожиданно сыплются.
Кажется, что это очевидно. Но попробуйте объяснить прямо сейчас не подглядывая 👀
Что такое архитектура? 🧱
Если совсем по-простому, то это чертёж системы.
Как в строительстве: прежде чем строить дом, архитектор рисует план — где стены, где двери, как всё соединяется, из каких материалов.
В IT всё то же самое: архитектура описывает из каких компонентов состоит система, как они взаимодействуют и почему именно так.
Зачем это знать аналитику?🤔
Ну, во-первых, чтобы меньше платить и не брать полноценного архитектора .
Если серьёзно, то как ты будешь проводить системный анализ в отрыве от самой системы? Любое решение проектируется внутри какой-то архитектуры, и не понимать как она устроена ну вообще никак.
Не понимаешь архитектуру → не понимаешь ограничения → пишешь требования, которые невозможно реализовать. Или реализовать можно, но потом всё ломается.
Самые популярные виды:
➡️ Монолит Вся система это один большой кусок. Логика, база и интерфейс лежат в одном месте.
На старте это просто и удобно, особенно если приложение небольшое. Но чем больше система растёт, тем тяжелее её масштабировать и менять.
➡️Микросервисы Система разбита на маленькие независимые сервисы, каждый отвечает за свою задачу. Главный плюс, если один сервис упал, остальные продолжают работать. Гибко и устойчиво.
Но есть нюансы: сервисов много, значит много интеграций, много мест где может что-то пойти не так, и отлаживать, деплоить и мониторить всё это заметно сложнее чем монолит.
Дальше уже идут архитектурные паттерны, в рамках которых можно реализовать ту или иную систему.
Что будет, если накосячить? 💀
Архитектурные ошибки самые дорогие.
Условный баг в коде исправишь за час. Неправильно выбранная архитектура может вскрыться через год и переделывать тогда дорого по времени и деньгам.
Именно поэтому архитектурные решения принимаются в самом начале и согласовываются со всеми заинтересованными сторонами.
А вам на собесах задавали базовые вопросы, от которых хотелось сказать «подержи моё пиво, ща тебе расскажу»? Делитесь в комментариях 👇
IT АНАЛитика | Подписаться