Для того чтобы получить работу сейчас приходится проходить через десятки интервью, поэтому никто не ждёт от вас что вы знаете хоть что-то о компании которая вас пригласила. Наоборот, они сами все расскажут.
Второе - важно не валить в кучу стратегию для джунов и войтишников со стратегией для опытных специалистов. Всякого рода стратегии привлечения внимания нужны для первой категории. Вторую категорию рекрутеры находят сами и изучают резюме долго и внимательно. Проблема не быть замеченным а оказаться лучшим из лучших на интервью.
Отчасти да. Слишком много принудительной социальности (типа ежедневных митингов с переливанием из пустого в порожнее) и прочих методик имбецильно-позитивного менеджмента. Которые по факту давят на склонность человека сравнивать себя с другими, из-за чего многие впадают в ступор и апатию.
Вот это боюсь что в самую точку. Только что сбежал от этой принудительной социализации (...привет, расскажи о себе! В свободное время я люблю сноуборд и кота, ага) а так же "имбецильно позитивного" менеджмента:, когда на первом и втором месте софтскилы, которыми считается показной позитивчик, полная неспособность что-либо обсуждать, детская обидчивость на любое противоречие, пафосная некометентность (главное побольше анлийских слов в руссой речи), снобическая вера во вбитые догмы и полная индефферентность к результатам труда. Буквально за год начал ненавидеть свою профессию. Понятное дело, кто сможет в таких условиях кодить по 8 часов, непонятно. И главное зачем.
Но (постучал по дереву) похоже пока не везде так, даже на галерах. Надеюсь, не ошибся.
Так я бы с радостью, но так не получается. Сначала тебе 38 и ты решил войти в профессиональное IT из более распространненного и тупикового в те давние времена госа. Как думаете, сколько времени в день пришлось работать, чтобы это сработало? Дальше проект мечты - амбициозная задача которую всю жизнь готовился решать. Как думаете, получилось бы что-то если работать без самоотдачи? Потом на тебе, иммиграция и все с нуля во время кризиса в IT. Опять, как думаете, сколько меня выдержит работодатель если я буду работать не торопясь при условии что на рынке есть 10 очень молодых умных и горячих на мое место? И как я прокормлю толпу подростков дома, которые сами работать начнут еще только лет через 5?
Покой иллюзия, по-моему он доступен только тем кому сразу повезло найти путь на котором можно позволить себе ничего не менять.
Конечно же я не имею ввиду что прямо конкретно код появляется каждую минуту все 8 чавов. По ходу можно думать, писать комментарии как это будет, удаляя их позже и так далее.
Хм... Давайте попробуем разобраться. Я программирую с института, в сумме больше 30 лет. Конечто же когда мне было лет 20, я мог писать код месяцами отходя только поспать, но это было такое время, когда программировать было как играть - очень ново и очень увлекательно.
Поэтому лучше говорить о сегодняшних днях. Пример моей работы - 4 года в маленькой фирме. Мы создавали с нуля несколько не сильно больших продуктов для автоматизации (но и не сильно простых - и сграфическими редакторами и с компьютерным зрением, и фронтом, моноо с чем), сначала я был один, к концу нас стало около трех.
Фирма работала на внутрениий рынок, и это всегда была работа на выживание. Т.е. нет никаких совещаний, чаепитий, походов в курилку, ты просто крутишься как заведенный целый день в кругу текущих задач, которые в прямо или косвенно кодинг. 8 часов, это минимум, в основном было больше. Все коллеги работали на той же скорости и никто вроде не жаловался что ему это не по силам. Ни малейших признаков выгорания ни у кого не было, наоборот, все буквально горели.
Следующая работа - там лично на мне кодинга было меньше, и когда его было меньше я сильно уставал. Наоборот, когда сам писал какой-нибудь большой модуль для моделирования-оптимизации и прочее, писал по 10 часов и не уставал.
Сегодня - галеры. Если надо 8 часов кодить, это счастливый день в конце которого я бодр. Обычно вечером еще тогда пишу пет проект. Если разгребать чужие баги или организационные вопросы, тогда устаю больше.
У меня версия, что современная организация труда что-то сломала в людях и в мотивации. Отсюда мнение про невозможность кодить 8 часов в день. Если не хочется, точно не сможешь, это да. Физиологически это точно не сложно, я видел сто человек которые это делали без проблем.
PS: по комметриям я понял, что многие считают что обдумывание кода или его изучение не входит в кодинг.
Я конечно имел ввиду 8 часов любого рода работы с кодом.
Беда в том, что многие верят сейчас что человек не может работать с кодом 8 часов, а так бывает только если наниматель уже покалечил всякую мотивацию, ИМХО.
Писать код по 8 часов в день абсолютно нормально и никакая не фантастика. Можно и по 12 если тебе меньше 45 пока. Изучать чужой код по 8 часов в день может мозг расплавиться, это да.
Коллега скорее всего имел ввиду, что запуск недо-проектированных ракет не такая уж плохая стратегия. Если у вас есть деньги чтобы подключить тысячи талантливых инженеров, создать тысячи дорогих испытательных стендов, тогда да, можно запустить с первого раза. Если таких ресурсов нет, можно просто грохнуть десяток плохо спроектированных ракет, чтобы научиться на ошибках и создать совершенство. Это не глупый путь, это просто другой путь.
Да, согласен. Есть ситуации когда отдельный сервис прямо просится и скорее упрощает код чем усложняет в сравнении с монолитом. Спорные моменты возникают когда речь о переходе на микросервисную архитектуру для задач, которые прекрасно ложатся в монолит.
ИМХО, все дело в методиках разработки и количестве денег на рынке ПО.
На проект можно нанять десяток гуру и они успешно будут двигаться вперед. Так было долгое время.
Но если рынок переинвестирован, наниматели могут себе позволить расшитяться.
Так много гуру на рынке нет, но можно разбавить их разработчиками мидл и джун уровня. При этом методика разработки меняется. Теперь вместо специалистов, которые умеют все и сидят глубоко погрузившися в код мы видим кучу аналитиков, которые подробно описывают PBI с критериями приемки, дробя работу на очень мелкие куски. И видим аджайл команды, которые тянут из бэклога очень тривиальные задачи, типа "добавить код для того-то в место такое-то для удовлетворения такому-то списку критериев".
Т.е. имея слишком много денег и недостаток людей отрасль выработала методики как потратить в 5 раз больше денег для того чтобы ускориться на 20%, при этом разбавив умную часть разработки тривиальными задачами, которым можно обучить почти кого угодно.
В какой-то момент, компании зашли на этом рынке слишком далеко. И теперь маятник качнулся в обратную сторону: сокращение мало квалифицированной части персонала и снова ставка на сильных специалистов.
После того как часть людей покинут рынок разработки, все устаканится на определенном уровне, когда войти в IT могут те кто любит и может, а для остальных это очень не тривиальная задача.
А собственно само количество работы в IT вряд-ли снижается. Скорее по-немногу растет.
Если у вас интернет магазин, можно смело оставаться на монолите. И если у вас CRM платформа на пол миллиона строк кода, тоже можно не париться, если монолит вменяемый пусть будет монолит. Вот если у вас проект на десяток миллионов строк кода, который пилят больше сотни человек, тут без микросервисов будет туго. Тут пожалуй пора.
В идеальном мире у нас был бы код страницы, который запрашивает с сервиса список dto-шек с вопросами, из которых он делает список вьюшек swiitch-case-ом (спрятанным в фабрику или нет, не важно), с которыми работает пользователь. После того как пользователь нажимает кнопку сабмит, код страницы проходит по списку вьюшек, достает через виртуальную функцию из каждой новый dto и отдает список сервису для отправки на сервер.
Здесь у каждого класса своя ответственность: у сервиса только передача данных, у вьюшек - только редактирование, у страницы - инициализация и управление этим.
Дальше, нам нужно впереть все это в концепт ангулара не сильно покалечив.
Каждый класс вьюшек без вариантов становится компонентом ангулар.
Компоненты развертываются из списка dto с помошью *ngIf:
Теперь вопрос - как достать данные из этих компонентов.
Фреймворки всегда имеют минусы и плюсы. Плюс - путь для решения пролем уже есть. Минус - этот путь в половине случаев не то что бы оптимален.
Для того, чтобы достать данные из компонентов нужен будет еще один объект - буфер для накопления результатов.
Он будет иметь один метод для приема dto от компонентов-влюшек.
Внутри он просто сохраняет/обновляет dto в словаре по некому ключу вопроса (номеру, например).
Второй его метод отдает результаты странице для отправки на сервер с помощью сервиса.
В конструкторе в этот класс-буфер можно передать исходный список dto, что позволит ему помимо прочего иметь функцию, возвращающую количество не отвеченных вопросов, чтобы код странциы мог определить можно ли уже сабмитить результат.
Вроде ничего не забыли.
Проверяем на сопровождаемость.
Для добавления нового типа вопросов достаточно добавить входную и выходную dto и компонет-вьюшку. Еще нужно добавить *ngIf. Код страницы, сервис и буфер менять не нужно.
Тесты:
Каждый компонент тестируется по сценарию - входная dto, набор кликов, выходная.
Буфер тестируется совсем просто и отдельно (если его вообще нужно тестировать).
В сервисе тестировать нечего.
Страница для тестирования требует мок сервиса, мок буфера и настоящие компоненты, если опять таки есть смысл ее тестировать.
Вот эти два пункта ИМХО и есть основная причина по которой нужны микросервисы:
Когда мы хотим вообще другой релизный цикл для модуля - хотим деплоить его много, часто, и версионировать своими версиями, и не хотим, чтобы пришлось в релизы тащить все 50 модулей вместе с ним.
Ну либо у нас большая система, и какие-то модули поддерживает отдельная команда, Тогда может быть они сами хотят решать всё что описано выше, и пусть решают себе, и дайте им контроль над тем, как деплоится их код, а не мучайте в общем релизе общего артефакта. Или мучайте если уж так хотите, кто я такой чтобы вам тут указывать.
Еще хотелось бы прочитать мнение автора про проблемы с общей базы данных и разделении базы между микросервисами. Я помню, что это была основная причина уложнения когда мы выделили микросервисы из монолита.
Я переехал полтора года назад по программе harbour. Но сейчас она закрыта. Я не в теме, но половина русскоговорящих вокруг меня переехали по карте поляка. Возможно и вы сможете ее получить.
Донт паник. Как раз искал работу в Польше. Мне 50, опыт программирования - десятилетия, но крайне не релевантный - чисто символический опыт веба, то дельфи то алгоритмы, то аналитиком. Искал работу 3 месяца. В европейские компании собесился раз 10, но нот ивен клоуз. Они ждут прямо совсем релевантный опыт, и очень приятное общение на английском. К счастью компаний с русскими, белорусскими и украинскими корнями здесь очень много. И освоившись и таки в конце смог от них получить сразу 2 офера мидл плюс или синьор минус. По зарплатам - для бэкендера меньше 3000$ после налогов от русскоязычных предложений не видел. Если компания ЕС, то будет от 4000$.
Ошибки конечно делать можно. По моему опыту, HR при приеме на работу вполне закроют на них глаза и поставят вам B2 если вы чешете по теме уверенно. Но есть и минусы, если это галеры то потом появится учитель, который тестит язык в компании и он офииально впаяет вам A2 за ошибки в артиклях и неиспользование всяких "used to". Потому что есть эффективность, а есть товарный вид. Увы сейчас состояние рынка таково что товарный вид на первом месте (там где важен английский).
ИМХО, в попытке быстро и самостоятельно улучшить язык самая сложная часть - перевод словарного запаса полученного в чтении и фильмах в активный. Здесь помимо прочего помгоает общение с GPT.
Давайте не обманывать себя. У нас есть только одно настоящее определение сознания: сознанием обладает то, что думает, действует, чувствует по принципам, сходным с теми которые работают у человека.
Чем больше сходства, тем больше сознания. Мало сходства - мало сознания.
Животное не говорит и не мыслит лоичически, но с ним можно наладить контакт как с человеком, значит где-то что-то похожее на сознание у него есть. И так далее.
GPT не обладает сознанием потому что у него нет памяти кроме сообщений на экране.
С другой стороны, GPT во время обучения мог обладать чем-то похожим на сознание. Потому что это была сеть, которая уже знала что-то, затем встечалась с новыми данными и переосмысливала свое понимание, строя шаг за шагом модель мира, как это делает мозг.
Так у них после защиты диссертации специалист называется "доктор философии", он же по нашему "кандидат наук" (плюс-минус). А следующей стадии обычно у них нет.
Микросервисы проще всегда, просто потому, что вы работаете с меньшим количеством кода и пилите конкретный проект, а с другим сервисом общаетесь через gateway.
Хм.. Не согласен. Был свидетелем частичного перехода продукта на 10 млин строк кода с монолита на микросервисы. Такое как вы пишете впечатление может создаться у человека который две недели в проекте, или если в этом монолите забили на любую архитектуру и затыкали дыры кто во что горазд. Но если монолит работоспособен и конкурентен, то обычно это означает что его проектировали далеко не дураки. В нем всегда будет совершенно ясное разделение на модули, слои, будут красивые эффективные концепции. Причем все это будет сделано лучше чем в микросервисах из за отсутствия дополнительных ограничений.
Если эта архитектура не выработана, то очень наивно надеятся, что просто выбор микросервисной архитектуры эту архитектуру внесет. Если компания не смогла нанять людей, которые могли бы сделать красивый монолит, она тем более не сможет сделать вменяемую микросервисную архитектуру.
В сущности микросервисную архитектуру со всеми ее концепциями примерно раз в 10 проще один в один воспроизвесити в монолите, чем в ее натуральном виде. Просто API сервисов превратятся в интерфейсы.
Если вам нужно добавить новую фитчу, в монолите вы попадаете в обсустроенный мир, где все уже предусмотрено, надо только посмотреть что он вам предоставляет и добавить свой код. В микросервисах конечно тоже подобное можно реализовать, но тогда это будет опять тот же монолит, только раз в 100 более медленный.
Суть микросервисов, как раз в том чтобы в каждом сервисе было намного больше кода чем нужно, что вам придется делать самостоятельно много вещей которые в монолите уже были бы из коробки. И соответственно придется иметь дело с большим количеством плохого кода чем в случае монолита. Но зато теперь команда может добавить в базу сущность или использовать любимый фреймворк не спрашивая главного архитектора компании. И не нужно идти на поклон к ведущему девелоперу, чтобы добавить мелкую фишку в платформу, потому что удобной и гибкой платформы больше никакой нет, а вместо нее локальный кривоватый кусочек кода, воспроизводящий то что было в платфонме в частном случае. Оно хуже чем было в платформе монолита, но зато ваше персональное решение, которое можно менять хоть каждый спринт.
Потому, очевидно, вам не надо разбираться, какая часть кода про этот функционал, а какая нет. Не надо раздумывать, не натворит-ли ваша фича что-то в другом функционале.
Ну нет, так не бывает. Я такого во всяком случае ни разу не видел. Так бывает если позволить рулить в проекте программистом с двумя годами опыта. Проблема когда у вас одна фитча ломает другие преодолевается любым девелопером после того как он запустил свои первые 30 000 строк кода. Если люди этого не умеют и вы поручите им проектировать микросервисную архитектуру, то результат буде точно таким же - непостижимо запутанная сеть микросервисов вместо непостижимого монолита.
Так что единственное, что в монолите проще, это наговнокодить и поруинить всё, а вот разбираться с рукотворным памятником тараканам из головы конкретного разработчика, вот это куда сложнее, чем в микросервисах.
Так в микросервисе как раз разработчик чувствует себя гораздо свободнее в плане говнокода. И потом с ним все равно придется разбираться.
Могу повториться, по моему мнению это очень наивная надежда. Если люди не умеют строить архитектуру в монолите (это относительно простой навык) и вы просто добавите им искуственные заборы, все станет только хуже, потому что работа с заборами требует больших навыков, чем без них.
Это примерно как задолбаться с процедурным говнокодом и заставить людей пользовать ООП и надеяться что теперь все станет лучше. Никогда в жизни не станет. Люди которые не научились писать понятный процедурный код точно не смогут написать понятный объектный.
так что монолит это хорошо до определённого момента, пока есть ядро функционала. Когда фичи разбухают, есть смысл их выносить. Ну, прям как деление клетки
Да, это совершенно верно. Но проблема не в запутанности монолита или говнокоде в нем. Проблема в том что монолит это идеальная архитектура для сольного разработчика, который в одиночку пилит весь проект. В случае если проект пилит 100 человек, возникют те самые проблемы о которых я писал. Вам нужно добавить фитчу, для этого нужно что-то поменять том самом удобном и универсальном окружении монолита, которое вы используете. И для этого становитесь в очередь к ведущему разработчику компании, чтобы он это сделал или согласовал, а потом ваш клиент будет ждать пол года пока будет очередной деплой монстра. С микросервисами пишем все самостоятельно, пусть кривее, пусть еще две команды делали почти то же самое, но зато прямо сегодня, отвечает за это конкретная команда и никто ей больше не нужен. И продукт идет вперед.
Самое главное в фидбэке - никогда, никогда не использовать фидбэк для того чтобы определить не нужно ли уволить кого-то из команды. К сожалению это очень распространенная практика, которая превращает работу в игру "дом два" или "кто слабое звено" вместо реальной работы. Кто слабое звено может решить руководитель или заказчик, но только не фидбэк.
Пара замечаний.
Для того чтобы получить работу сейчас приходится проходить через десятки интервью, поэтому никто не ждёт от вас что вы знаете хоть что-то о компании которая вас пригласила. Наоборот, они сами все расскажут.
Второе - важно не валить в кучу стратегию для джунов и войтишников со стратегией для опытных специалистов. Всякого рода стратегии привлечения внимания нужны для первой категории. Вторую категорию рекрутеры находят сами и изучают резюме долго и внимательно. Проблема не быть замеченным а оказаться лучшим из лучших на интервью.
Вот это боюсь что в самую точку. Только что сбежал от этой принудительной социализации (...привет, расскажи о себе! В свободное время я люблю сноуборд и кота, ага) а так же "имбецильно позитивного" менеджмента:, когда на первом и втором месте софтскилы, которыми считается показной позитивчик, полная неспособность что-либо обсуждать, детская обидчивость на любое противоречие, пафосная некометентность (главное побольше анлийских слов в руссой речи), снобическая вера во вбитые догмы и полная индефферентность к результатам труда. Буквально за год начал ненавидеть свою профессию. Понятное дело, кто сможет в таких условиях кодить по 8 часов, непонятно. И главное зачем.
Но (постучал по дереву) похоже пока не везде так, даже на галерах. Надеюсь, не ошибся.
Так я бы с радостью, но так не получается. Сначала тебе 38 и ты решил войти в профессиональное IT из более распространненного и тупикового в те давние времена госа. Как думаете, сколько времени в день пришлось работать, чтобы это сработало? Дальше проект мечты - амбициозная задача которую всю жизнь готовился решать. Как думаете, получилось бы что-то если работать без самоотдачи? Потом на тебе, иммиграция и все с нуля во время кризиса в IT. Опять, как думаете, сколько меня выдержит работодатель если я буду работать не торопясь при условии что на рынке есть 10 очень молодых умных и горячих на мое место? И как я прокормлю толпу подростков дома, которые сами работать начнут еще только лет через 5?
Покой иллюзия, по-моему он доступен только тем кому сразу повезло найти путь на котором можно позволить себе ничего не менять.
Конечно же я не имею ввиду что прямо конкретно код появляется каждую минуту все 8 чавов. По ходу можно думать, писать комментарии как это будет, удаляя их позже и так далее.
Хм... Давайте попробуем разобраться. Я программирую с института, в сумме больше 30 лет. Конечто же когда мне было лет 20, я мог писать код месяцами отходя только поспать, но это было такое время, когда программировать было как играть - очень ново и очень увлекательно.
Поэтому лучше говорить о сегодняшних днях. Пример моей работы - 4 года в маленькой фирме. Мы создавали с нуля несколько не сильно больших продуктов для автоматизации (но и не сильно простых - и сграфическими редакторами и с компьютерным зрением, и фронтом, моноо с чем), сначала я был один, к концу нас стало около трех.
Фирма работала на внутрениий рынок, и это всегда была работа на выживание. Т.е. нет никаких совещаний, чаепитий, походов в курилку, ты просто крутишься как заведенный целый день в кругу текущих задач, которые в прямо или косвенно кодинг. 8 часов, это минимум, в основном было больше. Все коллеги работали на той же скорости и никто вроде не жаловался что ему это не по силам. Ни малейших признаков выгорания ни у кого не было, наоборот, все буквально горели.
Следующая работа - там лично на мне кодинга было меньше, и когда его было меньше я сильно уставал. Наоборот, когда сам писал какой-нибудь большой модуль для моделирования-оптимизации и прочее, писал по 10 часов и не уставал.
Сегодня - галеры. Если надо 8 часов кодить, это счастливый день в конце которого я бодр. Обычно вечером еще тогда пишу пет проект. Если разгребать чужие баги или организационные вопросы, тогда устаю больше.
У меня версия, что современная организация труда что-то сломала в людях и в мотивации. Отсюда мнение про невозможность кодить 8 часов в день. Если не хочется, точно не сможешь, это да. Физиологически это точно не сложно, я видел сто человек которые это делали без проблем.
PS: по комметриям я понял, что многие считают что обдумывание кода или его изучение не входит в кодинг.
Я конечно имел ввиду 8 часов любого рода работы с кодом.
Беда в том, что многие верят сейчас что человек не может работать с кодом 8 часов, а так бывает только если наниматель уже покалечил всякую мотивацию, ИМХО.
Писать код по 8 часов в день абсолютно нормально и никакая не фантастика. Можно и по 12 если тебе меньше 45 пока. Изучать чужой код по 8 часов в день может мозг расплавиться, это да.
Вроде того. Например телескоп Джеймс Уэбб завелся с первого раза в космосе, но это было очень долго и очень дорого.
Коллега скорее всего имел ввиду, что запуск недо-проектированных ракет не такая уж плохая стратегия. Если у вас есть деньги чтобы подключить тысячи талантливых инженеров, создать тысячи дорогих испытательных стендов, тогда да, можно запустить с первого раза. Если таких ресурсов нет, можно просто грохнуть десяток плохо спроектированных ракет, чтобы научиться на ошибках и создать совершенство. Это не глупый путь, это просто другой путь.
Да, согласен. Есть ситуации когда отдельный сервис прямо просится и скорее упрощает код чем усложняет в сравнении с монолитом. Спорные моменты возникают когда речь о переходе на микросервисную архитектуру для задач, которые прекрасно ложатся в монолит.
ИМХО, все дело в методиках разработки и количестве денег на рынке ПО.
На проект можно нанять десяток гуру и они успешно будут двигаться вперед. Так было долгое время.
Но если рынок переинвестирован, наниматели могут себе позволить расшитяться.
Так много гуру на рынке нет, но можно разбавить их разработчиками мидл и джун уровня. При этом методика разработки меняется. Теперь вместо специалистов, которые умеют все и сидят глубоко погрузившися в код мы видим кучу аналитиков, которые подробно описывают PBI с критериями приемки, дробя работу на очень мелкие куски. И видим аджайл команды, которые тянут из бэклога очень тривиальные задачи, типа "добавить код для того-то в место такое-то для удовлетворения такому-то списку критериев".
Т.е. имея слишком много денег и недостаток людей отрасль выработала методики как потратить в 5 раз больше денег для того чтобы ускориться на 20%, при этом разбавив умную часть разработки тривиальными задачами, которым можно обучить почти кого угодно.
В какой-то момент, компании зашли на этом рынке слишком далеко. И теперь маятник качнулся в обратную сторону: сокращение мало квалифицированной части персонала и снова ставка на сильных специалистов.
После того как часть людей покинут рынок разработки, все устаканится на определенном уровне, когда войти в IT могут те кто любит и может, а для остальных это очень не тривиальная задача.
А собственно само количество работы в IT вряд-ли снижается. Скорее по-немногу растет.
Если у вас интернет магазин, можно смело оставаться на монолите. И если у вас CRM платформа на пол миллиона строк кода, тоже можно не париться, если монолит вменяемый пусть будет монолит. Вот если у вас проект на десяток миллионов строк кода, который пилят больше сотни человек, тут без микросервисов будет туго. Тут пожалуй пора.
Здесь проблема не в паттернах а в Angular.
В идеальном мире у нас был бы код страницы, который запрашивает с сервиса список dto-шек с вопросами, из которых он делает список вьюшек swiitch-case-ом (спрятанным в фабрику или нет, не важно), с которыми работает пользователь. После того как пользователь нажимает кнопку сабмит, код страницы проходит по списку вьюшек, достает через виртуальную функцию из каждой новый dto и отдает список сервису для отправки на сервер.
Здесь у каждого класса своя ответственность: у сервиса только передача данных, у вьюшек - только редактирование, у страницы - инициализация и управление этим.
Дальше, нам нужно впереть все это в концепт ангулара не сильно покалечив.
Каждый класс вьюшек без вариантов становится компонентом ангулар.
Компоненты развертываются из списка dto с помошью *ngIf:
*ngFor="let q of questions"<QuestionComponent1 *ngIf q.type = "Type1" [question]= q>
<QuestionComponent2 *ngIf q.type = "Type2" [question] = q>
Теперь вопрос - как достать данные из этих компонентов.
Фреймворки всегда имеют минусы и плюсы. Плюс - путь для решения пролем уже есть. Минус - этот путь в половине случаев не то что бы оптимален.
Для того, чтобы достать данные из компонентов нужен будет еще один объект - буфер для накопления результатов.
Он будет иметь один метод для приема dto от компонентов-влюшек.
Внутри он просто сохраняет/обновляет dto в словаре по некому ключу вопроса (номеру, например).
Второй его метод отдает результаты странице для отправки на сервер с помощью сервиса.
В конструкторе в этот класс-буфер можно передать исходный список dto, что позволит ему помимо прочего иметь функцию, возвращающую количество не отвеченных вопросов, чтобы код странциы мог определить можно ли уже сабмитить результат.
Вроде ничего не забыли.
Проверяем на сопровождаемость.
Для добавления нового типа вопросов достаточно добавить входную и выходную dto и компонет-вьюшку. Еще нужно добавить *ngIf. Код страницы, сервис и буфер менять не нужно.
Тесты:
Каждый компонент тестируется по сценарию - входная dto, набор кликов, выходная.
Буфер тестируется совсем просто и отдельно (если его вообще нужно тестировать).
В сервисе тестировать нечего.
Страница для тестирования требует мок сервиса, мок буфера и настоящие компоненты, если опять таки есть смысл ее тестировать.
В общем все выглядит изолированным и SOLIDным.
Вот эти два пункта ИМХО и есть основная причина по которой нужны микросервисы:
Еще хотелось бы прочитать мнение автора про проблемы с общей базы данных и разделении базы между микросервисами. Я помню, что это была основная причина уложнения когда мы выделили микросервисы из монолита.
Я переехал полтора года назад по программе harbour. Но сейчас она закрыта. Я не в теме, но половина русскоговорящих вокруг меня переехали по карте поляка. Возможно и вы сможете ее получить.
Донт паник. Как раз искал работу в Польше. Мне 50, опыт программирования - десятилетия, но крайне не релевантный - чисто символический опыт веба, то дельфи то алгоритмы, то аналитиком. Искал работу 3 месяца. В европейские компании собесился раз 10, но нот ивен клоуз. Они ждут прямо совсем релевантный опыт, и очень приятное общение на английском. К счастью компаний с русскими, белорусскими и украинскими корнями здесь очень много. И освоившись и таки в конце смог от них получить сразу 2 офера мидл плюс или синьор минус. По зарплатам - для бэкендера меньше 3000$ после налогов от русскоязычных предложений не видел. Если компания ЕС, то будет от 4000$.
Ошибки конечно делать можно. По моему опыту, HR при приеме на работу вполне закроют на них глаза и поставят вам B2 если вы чешете по теме уверенно. Но есть и минусы, если это галеры то потом появится учитель, который тестит язык в компании и он офииально впаяет вам A2 за ошибки в артиклях и неиспользование всяких "used to". Потому что есть эффективность, а есть товарный вид. Увы сейчас состояние рынка таково что товарный вид на первом месте (там где важен английский).
ИМХО, в попытке быстро и самостоятельно улучшить язык самая сложная часть - перевод словарного запаса полученного в чтении и фильмах в активный. Здесь помимо прочего помгоает общение с GPT.
Давайте не обманывать себя. У нас есть только одно настоящее определение сознания: сознанием обладает то, что думает, действует, чувствует по принципам, сходным с теми которые работают у человека.
Чем больше сходства, тем больше сознания. Мало сходства - мало сознания.
Животное не говорит и не мыслит лоичически, но с ним можно наладить контакт как с человеком, значит где-то что-то похожее на сознание у него есть. И так далее.
GPT не обладает сознанием потому что у него нет памяти кроме сообщений на экране.
С другой стороны, GPT во время обучения мог обладать чем-то похожим на сознание. Потому что это была сеть, которая уже знала что-то, затем встечалась с новыми данными и переосмысливала свое понимание, строя шаг за шагом модель мира, как это делает мозг.
Так у них после защиты диссертации специалист называется "доктор философии", он же по нашему "кандидат наук" (плюс-минус). А следующей стадии обычно у них нет.
Хм.. Не согласен. Был свидетелем частичного перехода продукта на 10 млин строк кода с монолита на микросервисы. Такое как вы пишете впечатление может создаться у человека который две недели в проекте, или если в этом монолите забили на любую архитектуру и затыкали дыры кто во что горазд. Но если монолит работоспособен и конкурентен, то обычно это означает что его проектировали далеко не дураки. В нем всегда будет совершенно ясное разделение на модули, слои, будут красивые эффективные концепции. Причем все это будет сделано лучше чем в микросервисах из за отсутствия дополнительных ограничений.
Если эта архитектура не выработана, то очень наивно надеятся, что просто выбор микросервисной архитектуры эту архитектуру внесет. Если компания не смогла нанять людей, которые могли бы сделать красивый монолит, она тем более не сможет сделать вменяемую микросервисную архитектуру.
В сущности микросервисную архитектуру со всеми ее концепциями примерно раз в 10 проще один в один воспроизвесити в монолите, чем в ее натуральном виде. Просто API сервисов превратятся в интерфейсы.
Если вам нужно добавить новую фитчу, в монолите вы попадаете в обсустроенный мир, где все уже предусмотрено, надо только посмотреть что он вам предоставляет и добавить свой код. В микросервисах конечно тоже подобное можно реализовать, но тогда это будет опять тот же монолит, только раз в 100 более медленный.
Суть микросервисов, как раз в том чтобы в каждом сервисе было намного больше кода чем нужно, что вам придется делать самостоятельно много вещей которые в монолите уже были бы из коробки. И соответственно придется иметь дело с большим количеством плохого кода чем в случае монолита. Но зато теперь команда может добавить в базу сущность или использовать любимый фреймворк не спрашивая главного архитектора компании. И не нужно идти на поклон к ведущему девелоперу, чтобы добавить мелкую фишку в платформу, потому что удобной и гибкой платформы больше никакой нет, а вместо нее локальный кривоватый кусочек кода, воспроизводящий то что было в платфонме в частном случае. Оно хуже чем было в платформе монолита, но зато ваше персональное решение, которое можно менять хоть каждый спринт.
Ну нет, так не бывает. Я такого во всяком случае ни разу не видел. Так бывает если позволить рулить в проекте программистом с двумя годами опыта. Проблема когда у вас одна фитча ломает другие преодолевается любым девелопером после того как он запустил свои первые 30 000 строк кода. Если люди этого не умеют и вы поручите им проектировать микросервисную архитектуру, то результат буде точно таким же - непостижимо запутанная сеть микросервисов вместо непостижимого монолита.
Так в микросервисе как раз разработчик чувствует себя гораздо свободнее в плане говнокода. И потом с ним все равно придется разбираться.
Могу повториться, по моему мнению это очень наивная надежда. Если люди не умеют строить архитектуру в монолите (это относительно простой навык) и вы просто добавите им искуственные заборы, все станет только хуже, потому что работа с заборами требует больших навыков, чем без них.
Это примерно как задолбаться с процедурным говнокодом и заставить людей пользовать ООП и надеяться что теперь все станет лучше. Никогда в жизни не станет. Люди которые не научились писать понятный процедурный код точно не смогут написать понятный объектный.
Да, это совершенно верно. Но проблема не в запутанности монолита или говнокоде в нем. Проблема в том что монолит это идеальная архитектура для сольного разработчика, который в одиночку пилит весь проект. В случае если проект пилит 100 человек, возникют те самые проблемы о которых я писал. Вам нужно добавить фитчу, для этого нужно что-то поменять том самом удобном и универсальном окружении монолита, которое вы используете. И для этого становитесь в очередь к ведущему разработчику компании, чтобы он это сделал или согласовал, а потом ваш клиент будет ждать пол года пока будет очередной деплой монстра. С микросервисами пишем все самостоятельно, пусть кривее, пусть еще две команды делали почти то же самое, но зато прямо сегодня, отвечает за это конкретная команда и никто ей больше не нужен. И продукт идет вперед.
Самое главное в фидбэке - никогда, никогда не использовать фидбэк для того чтобы определить не нужно ли уволить кого-то из команды. К сожалению это очень распространенная практика, которая превращает работу в игру "дом два" или "кто слабое звено" вместо реальной работы. Кто слабое звено может решить руководитель или заказчик, но только не фидбэк.