Вот я замечаю, что это как с любым новым инструментом - сначала прям надо потратить время на наработку навыка - в данном случае нужен навык промтинга. А еще потратить время и подобрать модель. Мои поиски и обучение, например, не кончаются. А ведь в этом месте работай ай какая неэффективная, если не сказать мееедленная. Но соглашусь, что когда хотя бы в одной рутинной задаче получается добиться результатов, то эффективность взлетает в разы.
Автор, спасибо за статью. Я бы добавила в основу любопытство (любознательность, способность увлекаться явлениями, темами и предметами, интерес к наблюдению и исследованию)
Расскажи плиз про версионирование, не совсем поняла, у вас были таблицы под версию, но не вытягивались данные?
Еще про разделение на части - я обычно делаю так: одну запись, проверка, десять, проверка, сто, проверка, а потом все остальное. Если есть возможность остальное разбить, разбиваю.
Очень сильно зависит от проекта. У нас вот системный аналитик - это почти архитектор. По доработкам продумывает решение, проектирует доработки БД, какие таблицы, констрейнты, связи, потом апи, где контракты поправить, где добавить. Описать логику. Еще требования фронта - макеты, сценарии, потом тестировщикам помочь с кейсами, в т.ч. нагрузочными, а потом еще и демо провести
Вот замечаю, что крупные компании и на собеседование на системного аналитика одним из этапом проводят System Design Interview. Если взглянуть как один из банков предлагает готовиться https://opensource.tbank.ru/general/career/-/blob/main/interview/sections/system-design-backend.md?ref_type=heads, то становится страшно, а это даже не на архитектора. Вот пара критериев оттуда
Как кандидат понял и прочертил границы системы — а именно что входит и не входит в границы задачи. Характерной чертой хорошо выстроенных границ является понимание основных сценариев работы системы и четко формализованного API.
Как кандидат проработал концептуальную схему. Концептуальная схема состоит из
— классов кубиков, из которых состоит система (или Architecture Building Blocks (ABB) из TOGAF)
— моделей данных, которые хранятся в этих кубиках и/или путешествуют между ними.
Как кандидат проработал реальную схему. По факту, это выбор для каждого кубика конкретного представителя (или Solution Building Block (SBB) из TOGAF).
А в статье кажется, что как будто и ничего особенного - "Очень красиво делать не надо" "никто не ждёт, что он отобразит весь контекст верно" - как-то не очень верится
Команде Apple можно этого парня с реддит себе в тестировщики взять)
Вот я замечаю, что это как с любым новым инструментом - сначала прям надо потратить время на наработку навыка - в данном случае нужен навык промтинга. А еще потратить время и подобрать модель. Мои поиски и обучение, например, не кончаются. А ведь в этом месте работай ай какая неэффективная, если не сказать мееедленная. Но соглашусь, что когда хотя бы в одной рутинной задаче получается добиться результатов, то эффективность взлетает в разы.
Спасибо автору. В копилочку для обучения джунов
чтобы не плодить некачественного, каждый должен взять на вооружение девиз «долго, дорого, охуенно»
этот девиз компании, в которой хочется работать)
Автор, спасибо за статью. Я бы добавила в основу любопытство (любознательность, способность увлекаться явлениями, темами и предметами, интерес к наблюдению и исследованию)
Эх, шишечки)
Расскажи плиз про версионирование, не совсем поняла, у вас были таблицы под версию, но не вытягивались данные?
Еще про разделение на части - я обычно делаю так: одну запись, проверка, десять, проверка, сто, проверка, а потом все остальное. Если есть возможность остальное разбить, разбиваю.
Понравилось "Как внедрить шаблон чего-либо". Хороший подход как работа с сопротивлением при внедрении непопулярных решений
Очень сильно зависит от проекта. У нас вот системный аналитик - это почти архитектор. По доработкам продумывает решение, проектирует доработки БД, какие таблицы, констрейнты, связи, потом апи, где контракты поправить, где добавить. Описать логику. Еще требования фронта - макеты, сценарии, потом тестировщикам помочь с кейсами, в т.ч. нагрузочными, а потом еще и демо провести
Ваш Василий архитектор, да?
Вот замечаю, что крупные компании и на собеседование на системного аналитика одним из этапом проводят System Design Interview. Если взглянуть как один из банков предлагает готовиться https://opensource.tbank.ru/general/career/-/blob/main/interview/sections/system-design-backend.md?ref_type=heads, то становится страшно, а это даже не на архитектора. Вот пара критериев оттуда
Как кандидат понял и прочертил границы системы — а именно что входит и не входит в границы задачи. Характерной чертой хорошо выстроенных границ является понимание основных сценариев работы системы и четко формализованного API.
Как кандидат проработал концептуальную схему. Концептуальная схема состоит из — классов кубиков, из которых состоит система (или Architecture Building Blocks (ABB) из TOGAF) — моделей данных, которые хранятся в этих кубиках и/или путешествуют между ними.
Как кандидат проработал реальную схему. По факту, это выбор для каждого кубика конкретного представителя (или Solution Building Block (SBB) из TOGAF).
А в статье кажется, что как будто и ничего особенного - "Очень красиво делать не надо" "никто не ждёт, что он отобразит весь контекст верно" - как-то не очень верится
По уровню докладов понравилась ufadevconf. Жаль, что пока отдельного направления для аналитиков в ней нет
Да, стажер иногда может загнать в тупик своим вопросом). Табличка полезная - такие мини-вопросы можно задавать на собесах.
Кто-нибудь участвовал? Как вам?