Микросервисы могут решить когнитивную нагрузку разработчиков, ценой когнитивной нагрузки других разработчиков (кто будет объединять микросервисы в приложение выполняющее бизнес-фичу) и девопсов.
Я из мира фронтенда, у нас вместо микросервисов есть микрофронты (по факту микросервисы). Часто слышу, а давайте начнем делать микрофронты, но только это потребует кучи времени настроек CI, особого мышления, так как сильно изменится способ взаимодействия с микрофронтом против обычного компонента. За 1,5 года на последнем проекте я смог выделить для себя только один микрофронт, который бы привел к уменьшению кванта развертывания, так как есть два приложения с разным релизным циклом, в которых надо одновременно зарелизить один и тот же компонент.
Я для себя выделил две эвристики того, как различать( Coupling связанность) и (Cohesion связность).
Первое. Отталкиваюсь от слов цена и ценность. Цена (связанность) - что мы платим, за используемые технологии и ограничения, которые накладываем на код. Ценность (связность) - что мы получим для бизнеса.
Второе. Связанность - это объединение кода библиотеками и фреймворками. А связность - это объединение бизнес-логикой.
Оба определения не идеальны, но как минимум толкают в нужном направлении.
Сделаешь много атомарных микросервисов, потом придется строить оркестратор. Сделаешь более жирные сервисы, придется мириться с другими ограничениями или проблемами. Вся архитектура сводится к тому, что у каждого проекта свои задачи и свои ограничения и как лучше написать - черт его знает, потому что нет серебрянной пули.
Если все сводится в итоге к тому, чтобы сделать из бэкендеров фуллстеков, то что мешает сделать наоборот. Берем фронтендера, который поднимает бэкенд на nodeJS и пишет уже на знакомом ему JS/TS. Если речь про простые бэкенды/фронтенды, то в чем проблема? Если декомпозировать приложение, то это будет набор CRUD-контроллеров с парой методов посложнее. И туда еще можно прикрутить SSR)
Соглашусь, что куча паттернов может быть решена особенностями языка, библиотеками или фреймворками. Это не исключает того, что паттерны стоит знать. Поэтому я бы изучил паттерны по какой-то простой попсовой книге или на сайте на том языке, который я использую. А потом дополнительно какие-то моменты смотрел бы уже сразу под свой стек.
Да, она познавательная, но есть один нюанс. Разбирать примеры на C++ сложно, так как язык не самый популярный и какие-нибудь Java/C#/JS подошли бы лучше. А если вы разработчик на Python, то разобрать код еще сложнее.
Также книга написана довольно муторно, можно было ее переписать в более попсовом формате, чтобы легче было читать. В целом, если книга не обновляется в течении 25-30 лет, это не очень хорошо. Можно было даже выпустить несколько разных вариантов с примерами под разные языки, Java Edition или Python Edition.
Я бы добавил сюда "Чистую архитектуру" Дядюшки Боба - книга легко читается и дает понимание того, откуда и зачем появились современные принципы.
На счет паттернов, я бы предпочел не общую книгу, а книгу, которая содержит примеры на языке, на котором я пишу. Читал паттерны ООП банды 4-х, которую никто не обновлял с 1993 или 1995 года, и читать примеры на c++ или smalltalk (если вы знаете вообще о таком) сущее наказание и вынос мозга.
"Кабанчик" вряд ли будет сильно нужен джуну, который пока не умеет программировать, как будто эта книга больше для уровня миддл и выше, когда начинается этап проектирования.
А что особенного дает Testplan если уже есть Playwright, Cypress? Их также можно натравить на storybook и получить скриншотные тесты вашего UI-кита. Также можно запустить тест условного веб-приложения (можно назвать UI-тесты), мокать данные и делать скриншоты в это время, тем самым получив динамику страниц и проверку на их целостность во время выполнения user story.
Согласен, что 20% может быть многовато для того, чтобы исправлять техдолг, но это были просто числа "например". Это не железное правило. Если команда может не создавать технический долг до тех пор, пока не потребуется обновить все библиотеки или что-то подобное, то можно хоть соотношение 99 к 1 делать с упором на бизнес.
Чтобы задачи не порождали техдолг, надо сперва определиться с тем, что входит в задачу. Например, во фронтенде тесты встречаются гораздо реже, и если захочется исправить ситуацию, то потребуется много времени и сил, чтобы начать их писать (научить команду писать тесты, найти нужную стратегию покрытия тестами кода и т.д.), пока идет подготовка к тестированию - команда уже напишет еще кучу непротестированого кода.
Согласен, что техдолг - это не только недоделки, но и тесты, документация, обновление библиотек, end of life сервисов, перенастройка CI и т.д. Просто "неноделки" можно решать через DoD-ы гораздо проще, чем обновление библиотек.
Полностью согласен, я бы даже добавил еще от себя на счет обучения технологиям. Не надо придумывать проект, который должен будет принести профит и деньги, надо просто взять и сделать учебный проект с синтетическими данными.
Для блогов есть уже много готовых ресурсов, особенно для начинающего блогера завести ТГ, ВК - вполне неплохой вариант, чем сделать сайт, на который нужно еще как-то нагнать трафик.
Для спама, мемесов, котиков (хотя котикам рады во всех чатах) можно завести отдельный чат, который можно поставить на mute, в него можно не вступать или игнорировать ещё как- нибудь. Можно завести правило на то, чтобы призывать в чате того, кто нужен для решения проблемы - если вас не позвали, можете игнорировать чат (тоже экономит время).
Почему лучше вести переписку даже между двумя членами команды в общем чате хорошая идея? Если ваш коллега вас заигнорил (отвлёкся и забыл, или нет времени, или токсик), то тогда уже можно привлечь ПМ-а, чтобы он фасилитировал процесс и увидел, что вы как взрослый человек приложили все усилия для решения проблемы. А также он сам увидит какая была проблема. А вот при общении в "личке" не понятно когда вы обратились и обращались ли за ответом к коллеге.
На счёт требования. Сперва вы собираете требования/решения в "хоть каком-то виде", потому что идёт процесс общения, а в конце вы или коллега можете сделать резюме, которое будет перенесено в задачу или куда надо. Это по сути тоже самое, что митинг ноут после каких-то встреч-созвонов. И вот тут можно позвать ПМа, чтобы он увидел ваше резюме, сказал ОК и не тратил свое время на чтение всего чата (у него тоже есть свои рабочие задачи).
Перекладывать все с сеньора (потому что ему надо работать и думать) на ПМ-а не всегда возможно. ПМ или лид могут не понимать ваш стек технологий, ПМ-у тем более не обязательно быть вообще программистом. Также, вы всегда можете обсудить с коллегой что-то совместно в чате - вы же взрослые люди, а вот если заиграет детство в одном месте или нужно вмешательство ПМа - тогда можно обратиться к нему. Иначе ваш ПМ будет отвечать на сообщения раз в несколько часов, потому что его будут дёргать по всякой фигне и вы и другие коллеги.
Вся связь через МП-а или лида - довольно удобная штука, ее можно решить через введение чата команды. Все вопросы можно задавать через него, тогда это решает сазу кучу проблем:
К сеньору не будет постоянно приходить какой-нибудь джун и теребить его, для этого есть чат и там может кто-то еще ответить.
В ходе беседы может выявиться какая-то серьезная проблема, которая может потребовать уточнений/пояснений от других специалистов, которые уже есть в чате и их надо просто туда позвать для уточнений.
Будет хоть в каком-то виде собрано решение какой-то проблемы, которое можно будет перенести пояснением в задачу.
Понятно, что есть личные конфликты, которые стоит решать через лида. А также есть личные вопросы, например пойдет ли твой коллега в бар, которые стоит спрашивать в личке)
Из своей жизни могу привести два варианта борьбы с техдолгом на уровне процессов:
Относительно распространенная практика - выделение квоты на техдолг. Например, вы работаете по спринтам и 20% спринта посвящаете техдолгу. Но тут надо уметь контролировать бизнес, ибо он будет напихивать в ваш спринт бизнесовых задач с горкой и приносить горящие задачи по среди спринта.
Второй вариант борьбы с техдолгом - это явно прописывать то, что должно входить в завершенную задачу (definition of done). Например, надо сделать сервис + тесты (юнит и/или интеграционные) + документация, и если чего-то из этого нет, то задача остается на этапе разработки. А задачу на тесты и документацию выносить в отдельный техдолг только тогда, когда есть угроза срывов дедлайнов или других серьезных проблем. Это не исключает техдолг, но позволяет заложить время на то, чтобы его создавать меньше. На практике несколько раз проходил такой момент, что тесты откладывали в задачу по техдолгу, а потом удаляли десятки задач на тесты, потому что делать их уже никто не планирует. Лучше сразу взять побольше срок на выполнение задачи (в рамках разумного), чем просить на это время.
В целом, это очень похоже на "метод 360 градусов", только очень упрощённый и обобщенный до 1-го вопроса. При желании, можно посмотреть аналогичные опросы. Но если у вас нет штата сотрудников отвечающих за процесс опросов и анализа результатов, то такой метод с одним вопросом кажется очень эффективным.
Написание статей - это скорее софт-скилл, который помогает собрать свои мысли в кучку, так же как и ведение какого-то дневника или канала. Заодно, умение доходчиво мыслить помогает в будущем при общении с коллегами и помогает в документировании своих решений.
По своему опыту, скажу, что это может даваться слишком тяжело (есть две статьи и свой мини-блог):
Нужна какая-то тема для статьи/поста, и ее поиск может занять долгое время (ни разу не находил тему, тема выбирала меня через обстоятельства). Мне как специалисту не хочется делать перепечатки/переводы чужих статей, как по мне это ближе к инфоцыганству. Мне хочется показать свой опыт, свои знания, которые могут помочь другим.
Написать хороший текст, тоже надо уметь. Несколько раз мои статьи читали и находили моменты, которые вызывали проблемы в понимании материала, приходилось переписывать. Формулировать мысли тяжело - если это не основной вид деятельности.
Кажется, что степень того, насколько это легко и круто, зависит от софт-скиллов человека. Но как раз таки пишу статьи и в блоге для того, чтобы развивать эти навыки, а заодно искать какие-то интересные мысли и знания.
Console не ограничивается лишь одним методом log. Их очень довольно много, и сразу оговорюсь, что для тестирования извне их или не применить, или очень сложно или нет смысла.
Но, например, для того, чтобы вывести таблицу есть отдельный метод .table(), который явно подойдет больше для отображения табличных данных.
Также, можно еще можно иногда пользоваться методами dir и dirxml.
Интересная статья, но есть один момент, который хочется узнать. Изменение этих настроек сказалось ли на других параметрах: потребление памяти, потребление GPU и т.д? Хочется понять реальную стоимость решения, а не только время потраченное разработчиками.
P.S. Разработчикам уважение, проделана классная и интересная работа
А при чем тут nodejs и nestjs? В тексте они упоминаются один раз. Как будто их можно заменить на любой сервис написанный на "язык + фреймворк выберите сами".
Также кажется указывать конкретные технологии при проектировании не очень хорошая идея. Ну или надо уточнять почему нам больше подходит MongoDb для поиска, потому что в зависимости от функционала, архитектурных решений можно вести эффективный поиск в реляционной базе или, вовсе, в графовой.
Микросервисы могут решить когнитивную нагрузку разработчиков, ценой когнитивной нагрузки других разработчиков (кто будет объединять микросервисы в приложение выполняющее бизнес-фичу) и девопсов.
Я из мира фронтенда, у нас вместо микросервисов есть микрофронты (по факту микросервисы). Часто слышу, а давайте начнем делать микрофронты, но только это потребует кучи времени настроек CI, особого мышления, так как сильно изменится способ взаимодействия с микрофронтом против обычного компонента. За 1,5 года на последнем проекте я смог выделить для себя только один микрофронт, который бы привел к уменьшению кванта развертывания, так как есть два приложения с разным релизным циклом, в которых надо одновременно зарелизить один и тот же компонент.
Я для себя выделил две эвристики того, как различать( Coupling связанность) и (Cohesion связность).
Первое. Отталкиваюсь от слов цена и ценность. Цена (связанность) - что мы платим, за используемые технологии и ограничения, которые накладываем на код. Ценность (связность) - что мы получим для бизнеса.
Второе. Связанность - это объединение кода библиотеками и фреймворками. А связность - это объединение бизнес-логикой.
Оба определения не идеальны, но как минимум толкают в нужном направлении.
Сделаешь много атомарных микросервисов, потом придется строить оркестратор. Сделаешь более жирные сервисы, придется мириться с другими ограничениями или проблемами. Вся архитектура сводится к тому, что у каждого проекта свои задачи и свои ограничения и как лучше написать - черт его знает, потому что нет серебрянной пули.
Если все сводится в итоге к тому, чтобы сделать из бэкендеров фуллстеков, то что мешает сделать наоборот. Берем фронтендера, который поднимает бэкенд на nodeJS и пишет уже на знакомом ему JS/TS. Если речь про простые бэкенды/фронтенды, то в чем проблема? Если декомпозировать приложение, то это будет набор CRUD-контроллеров с парой методов посложнее. И туда еще можно прикрутить SSR)
Соглашусь, что куча паттернов может быть решена особенностями языка, библиотеками или фреймворками. Это не исключает того, что паттерны стоит знать. Поэтому я бы изучил паттерны по какой-то простой попсовой книге или на сайте на том языке, который я использую. А потом дополнительно какие-то моменты смотрел бы уже сразу под свой стек.
Да, она познавательная, но есть один нюанс. Разбирать примеры на C++ сложно, так как язык не самый популярный и какие-нибудь Java/C#/JS подошли бы лучше. А если вы разработчик на Python, то разобрать код еще сложнее.
Также книга написана довольно муторно, можно было ее переписать в более попсовом формате, чтобы легче было читать. В целом, если книга не обновляется в течении 25-30 лет, это не очень хорошо. Можно было даже выпустить несколько разных вариантов с примерами под разные языки, Java Edition или Python Edition.
Спасибо, очень подробный ответ. В таком контексте соглашусь, что есть смысл делать такой инструмент.
Я бы добавил сюда "Чистую архитектуру" Дядюшки Боба - книга легко читается и дает понимание того, откуда и зачем появились современные принципы.
На счет паттернов, я бы предпочел не общую книгу, а книгу, которая содержит примеры на языке, на котором я пишу. Читал паттерны ООП банды 4-х, которую никто не обновлял с 1993 или 1995 года, и читать примеры на c++ или smalltalk (если вы знаете вообще о таком) сущее наказание и вынос мозга.
"Кабанчик" вряд ли будет сильно нужен джуну, который пока не умеет программировать, как будто эта книга больше для уровня миддл и выше, когда начинается этап проектирования.
А что особенного дает Testplan если уже есть Playwright, Cypress? Их также можно натравить на storybook и получить скриншотные тесты вашего UI-кита. Также можно запустить тест условного веб-приложения (можно назвать UI-тесты), мокать данные и делать скриншоты в это время, тем самым получив динамику страниц и проверку на их целостность во время выполнения user story.
Аналогично, для самых популярных команд завел алиасы, недавно описал ещё себе в github, чтобы переносить между рабочими и домашними машинами.
Вместо `git checkout master` ввожу `git cm`, вот и вся магия. Возможно, стоит заменить на switch, но и так работает.
Наверное стоит доработать до полного конфига, чтобы и другие настройки тоже переносить.
Согласен, что 20% может быть многовато для того, чтобы исправлять техдолг, но это были просто числа "например". Это не железное правило. Если команда может не создавать технический долг до тех пор, пока не потребуется обновить все библиотеки или что-то подобное, то можно хоть соотношение 99 к 1 делать с упором на бизнес.
Чтобы задачи не порождали техдолг, надо сперва определиться с тем, что входит в задачу. Например, во фронтенде тесты встречаются гораздо реже, и если захочется исправить ситуацию, то потребуется много времени и сил, чтобы начать их писать (научить команду писать тесты, найти нужную стратегию покрытия тестами кода и т.д.), пока идет подготовка к тестированию - команда уже напишет еще кучу непротестированого кода.
Согласен, что техдолг - это не только недоделки, но и тесты, документация, обновление библиотек, end of life сервисов, перенастройка CI и т.д. Просто "неноделки" можно решать через DoD-ы гораздо проще, чем обновление библиотек.
Полностью согласен, я бы даже добавил еще от себя на счет обучения технологиям. Не надо придумывать проект, который должен будет принести профит и деньги, надо просто взять и сделать учебный проект с синтетическими данными.
Для блогов есть уже много готовых ресурсов, особенно для начинающего блогера завести ТГ, ВК - вполне неплохой вариант, чем сделать сайт, на который нужно еще как-то нагнать трафик.
Для остального есть докер и гитхаб)
Для спама, мемесов, котиков (хотя котикам рады во всех чатах) можно завести отдельный чат, который можно поставить на mute, в него можно не вступать или игнорировать ещё как- нибудь. Можно завести правило на то, чтобы призывать в чате того, кто нужен для решения проблемы - если вас не позвали, можете игнорировать чат (тоже экономит время).
Почему лучше вести переписку даже между двумя членами команды в общем чате хорошая идея? Если ваш коллега вас заигнорил (отвлёкся и забыл, или нет времени, или токсик), то тогда уже можно привлечь ПМ-а, чтобы он фасилитировал процесс и увидел, что вы как взрослый человек приложили все усилия для решения проблемы. А также он сам увидит какая была проблема. А вот при общении в "личке" не понятно когда вы обратились и обращались ли за ответом к коллеге.
На счёт требования. Сперва вы собираете требования/решения в "хоть каком-то виде", потому что идёт процесс общения, а в конце вы или коллега можете сделать резюме, которое будет перенесено в задачу или куда надо. Это по сути тоже самое, что митинг ноут после каких-то встреч-созвонов. И вот тут можно позвать ПМа, чтобы он увидел ваше резюме, сказал ОК и не тратил свое время на чтение всего чата (у него тоже есть свои рабочие задачи).
Перекладывать все с сеньора (потому что ему надо работать и думать) на ПМ-а не всегда возможно. ПМ или лид могут не понимать ваш стек технологий, ПМ-у тем более не обязательно быть вообще программистом. Также, вы всегда можете обсудить с коллегой что-то совместно в чате - вы же взрослые люди, а вот если заиграет детство в одном месте или нужно вмешательство ПМа - тогда можно обратиться к нему. Иначе ваш ПМ будет отвечать на сообщения раз в несколько часов, потому что его будут дёргать по всякой фигне и вы и другие коллеги.
Вся связь через МП-а или лида - довольно удобная штука, ее можно решить через введение чата команды. Все вопросы можно задавать через него, тогда это решает сазу кучу проблем:
К сеньору не будет постоянно приходить какой-нибудь джун и теребить его, для этого есть чат и там может кто-то еще ответить.
В ходе беседы может выявиться какая-то серьезная проблема, которая может потребовать уточнений/пояснений от других специалистов, которые уже есть в чате и их надо просто туда позвать для уточнений.
Будет хоть в каком-то виде собрано решение какой-то проблемы, которое можно будет перенести пояснением в задачу.
Понятно, что есть личные конфликты, которые стоит решать через лида. А также есть личные вопросы, например пойдет ли твой коллега в бар, которые стоит спрашивать в личке)
Из своей жизни могу привести два варианта борьбы с техдолгом на уровне процессов:
Относительно распространенная практика - выделение квоты на техдолг. Например, вы работаете по спринтам и 20% спринта посвящаете техдолгу. Но тут надо уметь контролировать бизнес, ибо он будет напихивать в ваш спринт бизнесовых задач с горкой и приносить горящие задачи по среди спринта.
Второй вариант борьбы с техдолгом - это явно прописывать то, что должно входить в завершенную задачу (definition of done). Например, надо сделать сервис + тесты (юнит и/или интеграционные) + документация, и если чего-то из этого нет, то задача остается на этапе разработки. А задачу на тесты и документацию выносить в отдельный техдолг только тогда, когда есть угроза срывов дедлайнов или других серьезных проблем. Это не исключает техдолг, но позволяет заложить время на то, чтобы его создавать меньше. На практике несколько раз проходил такой момент, что тесты откладывали в задачу по техдолгу, а потом удаляли десятки задач на тесты, потому что делать их уже никто не планирует. Лучше сразу взять побольше срок на выполнение задачи (в рамках разумного), чем просить на это время.
В целом, это очень похоже на "метод 360 градусов", только очень упрощённый и обобщенный до 1-го вопроса. При желании, можно посмотреть аналогичные опросы. Но если у вас нет штата сотрудников отвечающих за процесс опросов и анализа результатов, то такой метод с одним вопросом кажется очень эффективным.
Написание статей - это скорее софт-скилл, который помогает собрать свои мысли в кучку, так же как и ведение какого-то дневника или канала. Заодно, умение доходчиво мыслить помогает в будущем при общении с коллегами и помогает в документировании своих решений.
По своему опыту, скажу, что это может даваться слишком тяжело (есть две статьи и свой мини-блог):
Нужна какая-то тема для статьи/поста, и ее поиск может занять долгое время (ни разу не находил тему, тема выбирала меня через обстоятельства). Мне как специалисту не хочется делать перепечатки/переводы чужих статей, как по мне это ближе к инфоцыганству. Мне хочется показать свой опыт, свои знания, которые могут помочь другим.
Написать хороший текст, тоже надо уметь. Несколько раз мои статьи читали и находили моменты, которые вызывали проблемы в понимании материала, приходилось переписывать. Формулировать мысли тяжело - если это не основной вид деятельности.
Кажется, что степень того, насколько это легко и круто, зависит от софт-скиллов человека. Но как раз таки пишу статьи и в блоге для того, чтобы развивать эти навыки, а заодно искать какие-то интересные мысли и знания.
Console не ограничивается лишь одним методом log. Их очень довольно много, и сразу оговорюсь, что для тестирования извне их или не применить, или очень сложно или нет смысла.
Но, например, для того, чтобы вывести таблицу есть отдельный метод .table(), который явно подойдет больше для отображения табличных данных.
Также, можно еще можно иногда пользоваться методами dir и dirxml.
Интересная статья, но есть один момент, который хочется узнать. Изменение этих настроек сказалось ли на других параметрах: потребление памяти, потребление GPU и т.д? Хочется понять реальную стоимость решения, а не только время потраченное разработчиками.
P.S. Разработчикам уважение, проделана классная и интересная работа
А при чем тут nodejs и nestjs? В тексте они упоминаются один раз. Как будто их можно заменить на любой сервис написанный на "язык + фреймворк выберите сами".
Также кажется указывать конкретные технологии при проектировании не очень хорошая идея. Ну или надо уточнять почему нам больше подходит MongoDb для поиска, потому что в зависимости от функционала, архитектурных решений можно вести эффективный поиск в реляционной базе или, вовсе, в графовой.