Так продумывать смотря для чего нужно) Или нужно на каждый микросервис, который из кафки в базу сохраняет (условно), особую архитектуру мозговым штурмом прорабатывать?
Да мне кажется вряд ли, бывает в нейронку вбиваешь, сделай мне такой-то метод, какой-то метод, а получаешь кучу нерабочего кода. А вот глобальные вопросы по архитектуре, он найдет скопирует главу из книги какой-нибудь, а ты это пойди реализуй.
Да я имел ввиду, что больше уметь коммуницировать, а план подразумевает, что ответить, что-то внятное. Если просят что-то нереалистичное, сказать так нельзя и почему и сказать, что можно в теории сделать и придти к результату. А не просто ответить ну так нельзя все пока.
А может еще поднять инфраструктуру поднять, сервера настроить, фронт накидать, бек реализовать протестировать, провести аналитику. А заодно еще можно в офисе приехать пол помыть...
В целом если в компании один вы и вам сказали разработать, что-то большое вероятно - это просто пустая трата денег, ибо ничего не выйдет. А если компания в которой присутствуют аналитики, тестировщики и т.д, то разработчик не должен делать их работу
В целом я не говорил, что работа легкая, я говорил порог ниже и после курсов реально проще найти работу в поддержку, чем по направлению, которому обучался
Тут тоже зависит от человека, много людей из техподдержки идут дальше и становятся разработчиками, тестировщиками, просто если ты в данный момент не обладаешь минимальными навыками для другой работы, то начать стоит с меньшего.
Смотря какое решение мы собираешься реализовывать.
В данном случае как тестовое задание не вижу смысле прям в отдельный сервис выносить.
А по хорошему на микросервисы разбивают по разным причинам, если нет потребности и имеется, только домен с которым мы работаем, как например небольшой магазин книг, не вижу смысла делать отдельно.
Не вижу связи между шаблоном построения конкретного сервиса с точки зрения организации кода и интерфейсов и потоков данных. При наличии первого, автоматически не отменяется второе.
А про модульный монолит тоже странно, если просто микросервисы деплоятся из одного репозитория, то это не модульный монолит, а если вы имеете ввиду, что хранить все в одном проекте, то это странная идея и несет большое количество проблем, ведь микросервисов в компании может быть много
В целом - это и хотел донести) Надо было с более четкими примерами поработать)
Имеется ввиду, что не менялся ключ ошибки, а так там может быть хоть слова песни, хоть ссылка
Так продумывать смотря для чего нужно) Или нужно на каждый микросервис, который из кафки в базу сохраняет (условно), особую архитектуру мозговым штурмом прорабатывать?
Да мне кажется вряд ли, бывает в нейронку вбиваешь, сделай мне такой-то метод, какой-то метод, а получаешь кучу нерабочего кода. А вот глобальные вопросы по архитектуре, он найдет скопирует главу из книги какой-нибудь, а ты это пойди реализуй.
Да я имел ввиду, что больше уметь коммуницировать, а план подразумевает, что ответить, что-то внятное. Если просят что-то нереалистичное, сказать так нельзя и почему и сказать, что можно в теории сделать и придти к результату. А не просто ответить ну так нельзя все пока.
выглядит больше, как реклама для компании, чем вакансия)
Еще подтяжки, чтобы штаны не спадывали)
В крупных компаниях, как раз в этом и беда, уже все базово реализовано, только пили микросервисы по шаблону)
где-то в 2015-2016 годах)
Сейчас конечно с инфляцией и сквозь время, прям сложно поверить в эти цифры) А ведь когда-то проезд на транспорте стоил по 3 рубля)
Так к этому привыкнуть легко) Если раньше хотя-бы нужно было списать и попытаться подправить и объяснить лабу, то-есть просто отправить один запрос.
Задание то в целом не сложные, скорее больше с информатики школьной) Но видимо компьютер для них сейчас не важная часть.
Тут конечно я немного драмы нагнал) В целом понятно были, но найти было гораздо сложнее)
А что не так?
А может еще поднять инфраструктуру поднять, сервера настроить, фронт накидать, бек реализовать протестировать, провести аналитику. А заодно еще можно в офисе приехать пол помыть...
В целом если в компании один вы и вам сказали разработать, что-то большое вероятно - это просто пустая трата денег, ибо ничего не выйдет. А если компания в которой присутствуют аналитики, тестировщики и т.д, то разработчик не должен делать их работу
В целом я не говорил, что работа легкая, я говорил порог ниже и после курсов реально проще найти работу в поддержку, чем по направлению, которому обучался
В целом для работы в техподдержке ничего такого, туда в целом и без опыта берут, потому-что всему можно научиться на месте, главное желание
Тут тоже зависит от человека, много людей из техподдержки идут дальше и становятся разработчиками, тестировщиками, просто если ты в данный момент не обладаешь минимальными навыками для другой работы, то начать стоит с меньшего.
Смотря какое решение мы собираешься реализовывать.
В данном случае как тестовое задание не вижу смысле прям в отдельный сервис выносить.
А по хорошему на микросервисы разбивают по разным причинам, если нет потребности и имеется, только домен с которым мы работаем, как например небольшой магазин книг, не вижу смысла делать отдельно.
Не вижу связи между шаблоном построения конкретного сервиса с точки зрения организации кода и интерфейсов и потоков данных. При наличии первого, автоматически не отменяется второе.
А про модульный монолит тоже странно, если просто микросервисы деплоятся из одного репозитория, то это не модульный монолит, а если вы имеете ввиду, что хранить все в одном проекте, то это странная идея и несет большое количество проблем, ведь микросервисов в компании может быть много