В идеальном мире у нас был бы код страницы, который запрашивает с сервиса список 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 человек, возникют те самые проблемы о которых я писал. Вам нужно добавить фитчу, для этого нужно что-то поменять том самом удобном и универсальном окружении монолита, которое вы используете. И для этого становитесь в очередь к ведущему разработчику компании, чтобы он это сделал или согласовал, а потом ваш клиент будет ждать пол года пока будет очередной деплой монстра. С микросервисами пишем все самостоятельно, пусть кривее, пусть еще две команды делали почти то же самое, но зато прямо сегодня, отвечает за это конкретная команда и никто ей больше не нужен. И продукт идет вперед.
Самое главное в фидбэке - никогда, никогда не использовать фидбэк для того чтобы определить не нужно ли уволить кого-то из команды. К сожалению это очень распространенная практика, которая превращает работу в игру "дом два" или "кто слабое звено" вместо реальной работы. Кто слабое звено может решить руководитель или заказчик, но только не фидбэк.
Самое главное в фидбэке - никогда, никогда не использовать фидбэк для того чтобы определить не нужно ли уволить кого-то из команды. К сожалению это очень распространенная практика, которая превращает работу в игру "кто слабое звено" вместо реальной работы. Кто слабое звено может знать руководитель или заказчик, но только не фидбэк.
Да, всегда начинаешь фантазировать, что было бы в идеальном мире при наличии гениального капитана. Если начать эвакуацию сразу, если загружать шлюбки людьми до критического предела, чтобы только что бортами не черпали. Если с первого момента организовать изготовление плотов из всего что есть плавучего на корабле. Сколько бы людей выжило тогда...
Никогда не думал что микросервисы можно рассматривать как средство борьбы со сложностью. Монолит проще всегда, а все архитектурыне преимущества декомпозиции в 10 раз проще реализовать внутри монолита абстрактно чем порезав систему физически на куски.
Преимущества микросервисов - независимый деплой и независимо работающие команды. По-моему только так отвечают даже на собесах.
Например, надо добавить новую фитчу. В монолите при этом может потребоваться несколько сквозных доработок на всех уровнях, начиная с одной на всех модели базы данных. В итоге нужно вовлечь много людей, кто-то занят, придется ждать.
Если же архитектура микросервисная - как правило команда ответственная за фитчу пилит и деплоит ее а другие команды даже ничего не знают. Это реально работает. Плата за такую архитекруру - адово нарушение DRY (нет крутой наработанной за годы платформы на все случаи жизни, каждая команда пилит ее элементы сама) и куча трудностей с агрегацией/синхронизацией данных из разных сервисов.
Как же правильно использовать свое время, чтобы потом не сожалеть
А зачем вам "потом не сожалеть"? Какая разница что о прожитой жизни будет думать уставший старик, которым вы когда-то станете. Намного важнее что вы думаете о ней сейчас.
Если коротко: не делай важные дела, делай самые важные
Кстати, в итоге всю жизнь будешь делать эти самые важные дела, так и не переделаешь, а собственно жизнь может так и не начаться.
... А если серьезно, то скрам и аджайл замечательные вещи, если они вторичны по отношению к работе и воспринимаются как желательные правила игры, не более того.
Потому-то во-первых можно поставить реалистичные цели и их достичь. Пол команды делало что-то другое на самом деле поперек планов на спринт? Ничего страшного, мир не рухнул.
Во-вторых есть ясные моменты когда все синхронизируются в своем понимании происходящего, а так может поленились бы.
В третьих потому что достигая успеха в срок, пусть и условный и демонстрируя результаты люди мотивируют себя и друг друга. Но только при условии что этот срок вторичен, и если нужно забываем про все и идем к цели в разрез любым планам.
Автор еще плохо представляет насколько глубока кроличья нора.
На самом деле аджайл и скрам "нужны" совсем для другого.
Представьте, есть вполне вменяемая задача и не слишком сильная команда.
Если решать задачу в лоб и по старинке, есть опытный лид, который расписывает план решения задачи и делит его между членами команды согласно их спсособностям и компетенциям. И команда с минимальными усилиями движется к цели.
И тут возникает две главные проблемы:
Задачи зависят друг от друга и люди иногда блокируют друг друга и сидят без дела.
Лид не успевает все распланировать и когда это случается команда опять сидит без дела пока он думает.
В итоге менеджеры нервничают: хочется быстрее а люди явно сидят без дела.
Как решить это упроблему? Элементарно - Аджайл!
Вместо того чтобы улучшить разработку нужно ее УХУДШИТЬ! Тогда разработка пойдет в 3 раза медленнее, но все будут заняты аж пыль столбом и у лида будет гораздо больше времени подумать. Все работают, все заняты, все с пафосом называют на совещаниях номера PBI, разруливают блокеры. Менеджеры довольны!
Возвращаясь к статье, автор не знает способа планировать время на RnD задачи, но он есть. Для этого нужно просто разбавить эти задачи всякой ненужной хренью в таком количестве, чтобы неопредленность времени на эти задачи уже почти не была заметна на фоне общей "работы". Прогрммирование не похоже на укладку кирпичей и не нормируется? Давайте испортим его настолько чтобы оно стало похоже.
Немного деталей - а как ухудшить разработку? Есть несколько замечательных приемов.
Во-первых инжеренрый дух креатива и целеустнемленности нужно заменить на игру в разработку, желательно предельно пафосную и забитую разными церемониями. Фокус с работы необходимо переместить на процессы. Бесплатный бонус - в таких условиях вы можете нанимать кого угодно - все будут работть примерно одинаково. Больше нет интеллектуальных элитариев.
Во-вторых, задачи обязательно нужно раздавать совершенно случайным людям по принципе кто первый того сегодня и тапки (у нас не должно быть незаменимых!). Человек уже делал нечто подобное 10 раз с справится за пол часа? Это плохо, потому что лид потратил 2 часа чтобы принять решения что нужно сделать. Отдадим эту задачу тому кто все это в первый раз видит и он провозится весь спринт. Все при деле!
В третьих задачи нужно очень мелко поделить, чтобы работы было буквально на пол часа. Это даст сразу два преимущества. Во-первых количество бюрократии и усилий на создание PR и прочее превзойдут саму задачу. Во-вторых, люди будут сильно перескаться, мешая друг другу. Ошибка одного потребует от людей мобилизации всех их сил, чтобы понять и чего теперь делать со всеми этими уже закрытыми PBI и блокерами (командная работа!)
Наконец последнее и самое важное. Люди или заказчик могут начать что-то подозревать. Поэтому важно создать атмосферу нетерпимости к любым попытка внести в разработку здравый смысл и подвергнуть догмы сомнениям. Кто не понимает важности этой всей системы - тот не профессионал и ему не место в церкви компании.
Это был готовый рецепт как создать прибыльную галеру. Примите на заметку.
"Непротиворечивая" это слишком сильно звучит. Скорее она из разряда "мы конечно понимаем что все что мы говорим это спекуляции без конкретного смысла и все это точно не имеет отношения к действительности, но давайте лучше так, чем никак".
Открою вам секрет, большинство людей как были бедными в 20, так и остаются бедными в 50, не считая того, что к 50 у них есть своя квартира, запасная квартира в которую вложил лишние деньги пока они были, а так же двое или трое детей. Бедные они в том смысле что как в 25 так и в 50 они имеют доход одного порядка, это да. Довольно небольшому проценту удается сделать качественный скачок в доходах.
Я думаю имелся ввиду курс в ютубе "Гитара с нуля" Романа Конограя. Курс действительно классный. Минимум усилий и всякий может спеть что-то из русского рока для непритязательного круга друзей.
История похожа на мою, только я немного еще старше и далеко не так хорош. В итоге всю жизнь отработав в IT, к 50 снова садишься за английский и учебу чтобы снова выглядеть как программист (после периода менеджмента) и снова начинаешь с мидловской позиции.
Совершенно согласен что при наличии семьи в этом мире нужна подушка минимум на год, потому что никогда не знаешь в какой момент станешь опять никому не нужен со всем своим опытом.
И совершенно согласен что стареешь только когда перестал учиться. Пока сам не сдался, то по сути ты 50-летний это все тот же 20 летний студент, только здоровьем немного послабее.
Здесь проблема не в паттернах а в 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 человек, возникют те самые проблемы о которых я писал. Вам нужно добавить фитчу, для этого нужно что-то поменять том самом удобном и универсальном окружении монолита, которое вы используете. И для этого становитесь в очередь к ведущему разработчику компании, чтобы он это сделал или согласовал, а потом ваш клиент будет ждать пол года пока будет очередной деплой монстра. С микросервисами пишем все самостоятельно, пусть кривее, пусть еще две команды делали почти то же самое, но зато прямо сегодня, отвечает за это конкретная команда и никто ей больше не нужен. И продукт идет вперед.
Самое главное в фидбэке - никогда, никогда не использовать фидбэк для того чтобы определить не нужно ли уволить кого-то из команды. К сожалению это очень распространенная практика, которая превращает работу в игру "дом два" или "кто слабое звено" вместо реальной работы. Кто слабое звено может решить руководитель или заказчик, но только не фидбэк.
Самое главное в фидбэке - никогда, никогда не использовать фидбэк для того чтобы определить не нужно ли уволить кого-то из команды. К сожалению это очень распространенная практика, которая превращает работу в игру "кто слабое звено" вместо реальной работы. Кто слабое звено может знать руководитель или заказчик, но только не фидбэк.
Да, всегда начинаешь фантазировать, что было бы в идеальном мире при наличии гениального капитана. Если начать эвакуацию сразу, если загружать шлюбки людьми до критического предела, чтобы только что бортами не черпали. Если с первого момента организовать изготовление плотов из всего что есть плавучего на корабле. Сколько бы людей выжило тогда...
Никогда не думал что микросервисы можно рассматривать как средство борьбы со сложностью. Монолит проще всегда, а все архитектурыне преимущества декомпозиции в 10 раз проще реализовать внутри монолита абстрактно чем порезав систему физически на куски.
Преимущества микросервисов - независимый деплой и независимо работающие команды. По-моему только так отвечают даже на собесах.
Например, надо добавить новую фитчу. В монолите при этом может потребоваться несколько сквозных доработок на всех уровнях, начиная с одной на всех модели базы данных. В итоге нужно вовлечь много людей, кто-то занят, придется ждать.
Если же архитектура микросервисная - как правило команда ответственная за фитчу пилит и деплоит ее а другие команды даже ничего не знают. Это реально работает. Плата за такую архитекруру - адово нарушение DRY (нет крутой наработанной за годы платформы на все случаи жизни, каждая команда пилит ее элементы сама) и куча трудностей с агрегацией/синхронизацией данных из разных сервисов.
А зачем вам "потом не сожалеть"? Какая разница что о прожитой жизни будет думать уставший старик, которым вы когда-то станете. Намного важнее что вы думаете о ней сейчас.
Кстати, в итоге всю жизнь будешь делать эти самые важные дела, так и не переделаешь, а собственно жизнь может так и не начаться.
... А если серьезно, то скрам и аджайл замечательные вещи, если они вторичны по отношению к работе и воспринимаются как желательные правила игры, не более того.
Потому-то во-первых можно поставить реалистичные цели и их достичь. Пол команды делало что-то другое на самом деле поперек планов на спринт? Ничего страшного, мир не рухнул.
Во-вторых есть ясные моменты когда все синхронизируются в своем понимании происходящего, а так может поленились бы.
В третьих потому что достигая успеха в срок, пусть и условный и демонстрируя результаты люди мотивируют себя и друг друга. Но только при условии что этот срок вторичен, и если нужно забываем про все и идем к цели в разрез любым планам.
Автор еще плохо представляет насколько глубока кроличья нора.
На самом деле аджайл и скрам "нужны" совсем для другого.
Представьте, есть вполне вменяемая задача и не слишком сильная команда.
Если решать задачу в лоб и по старинке, есть опытный лид, который расписывает план решения задачи и делит его между членами команды согласно их спсособностям и компетенциям. И команда с минимальными усилиями движется к цели.
И тут возникает две главные проблемы:
Задачи зависят друг от друга и люди иногда блокируют друг друга и сидят без дела.
Лид не успевает все распланировать и когда это случается команда опять сидит без дела пока он думает.
В итоге менеджеры нервничают: хочется быстрее а люди явно сидят без дела.
Как решить это упроблему? Элементарно - Аджайл!
Вместо того чтобы улучшить разработку нужно ее УХУДШИТЬ! Тогда разработка пойдет в 3 раза медленнее, но все будут заняты аж пыль столбом и у лида будет гораздо больше времени подумать. Все работают, все заняты, все с пафосом называют на совещаниях номера PBI, разруливают блокеры. Менеджеры довольны!
Возвращаясь к статье, автор не знает способа планировать время на RnD задачи, но он есть. Для этого нужно просто разбавить эти задачи всякой ненужной хренью в таком количестве, чтобы неопредленность времени на эти задачи уже почти не была заметна на фоне общей "работы". Прогрммирование не похоже на укладку кирпичей и не нормируется? Давайте испортим его настолько чтобы оно стало похоже.
Немного деталей - а как ухудшить разработку? Есть несколько замечательных приемов.
Во-первых инжеренрый дух креатива и целеустнемленности нужно заменить на игру в разработку, желательно предельно пафосную и забитую разными церемониями. Фокус с работы необходимо переместить на процессы. Бесплатный бонус - в таких условиях вы можете нанимать кого угодно - все будут работть примерно одинаково. Больше нет интеллектуальных элитариев.
Во-вторых, задачи обязательно нужно раздавать совершенно случайным людям по принципе кто первый того сегодня и тапки (у нас не должно быть незаменимых!). Человек уже делал нечто подобное 10 раз с справится за пол часа? Это плохо, потому что лид потратил 2 часа чтобы принять решения что нужно сделать. Отдадим эту задачу тому кто все это в первый раз видит и он провозится весь спринт. Все при деле!
В третьих задачи нужно очень мелко поделить, чтобы работы было буквально на пол часа. Это даст сразу два преимущества. Во-первых количество бюрократии и усилий на создание PR и прочее превзойдут саму задачу. Во-вторых, люди будут сильно перескаться, мешая друг другу. Ошибка одного потребует от людей мобилизации всех их сил, чтобы понять и чего теперь делать со всеми этими уже закрытыми PBI и блокерами (командная работа!)
Наконец последнее и самое важное. Люди или заказчик могут начать что-то подозревать. Поэтому важно создать атмосферу нетерпимости к любым попытка внести в разработку здравый смысл и подвергнуть догмы сомнениям. Кто не понимает важности этой всей системы - тот не профессионал и ему не место в
церквикомпании.Это был готовый рецепт как создать прибыльную галеру. Примите на заметку.
"Непротиворечивая" это слишком сильно звучит. Скорее она из разряда "мы конечно понимаем что все что мы говорим это спекуляции без конкретного смысла и все это точно не имеет отношения к действительности, но давайте лучше так, чем никак".
Открою вам секрет, большинство людей как были бедными в 20, так и остаются бедными в 50, не считая того, что к 50 у них есть своя квартира, запасная квартира в которую вложил лишние деньги пока они были, а так же двое или трое детей. Бедные они в том смысле что как в 25 так и в 50 они имеют доход одного порядка, это да. Довольно небольшому проценту удается сделать качественный скачок в доходах.
Я думаю имелся ввиду курс в ютубе "Гитара с нуля" Романа Конограя. Курс действительно классный. Минимум усилий и всякий может спеть что-то из русского рока для непритязательного круга друзей.
Примерно так, только многомировая интерпретация это не теория. Это интерпретация.
История похожа на мою, только я немного еще старше и далеко не так хорош. В итоге всю жизнь отработав в IT, к 50 снова садишься за английский и учебу чтобы снова выглядеть как программист (после периода менеджмента) и снова начинаешь с мидловской позиции.
Совершенно согласен что при наличии семьи в этом мире нужна подушка минимум на год, потому что никогда не знаешь в какой момент станешь опять никому не нужен со всем своим опытом.
И совершенно согласен что стареешь только когда перестал учиться. Пока сам не сдался, то по сути ты 50-летний это все тот же 20 летний студент, только здоровьем немного послабее.