А это ещё одна ошибка. Интерфейсы создаются на использующей их стороне. Как ни крути - не надо класть все рядом с тем что будет использовано.
Возьмём такой пример. Апи имеет один и тот же интерфейс. Меняется только апи версия. По Вашей логике будут созданы 2 разных апи рядом с каждым компонентом с которым этот компонент работает.
Апи не важно с чем он взаимодействует. У него есть абстрактные объекты и их методы. Как это сделано под капотом не важно.
Мы с Вами разговариваем на разных языках. Я представляю всю реализацию на интерфейсах, Вы предоставляете на инстансах. Отсюда и возникает необходимость писать код рядом с с тем, с чем он будет взаимодействовать
В этом и состоит ошибка разделения кода по фича стилю. Апи само по себе уже специфично, т.к. предоставляет собственный интерфейс взаимодействия. Поэтому его функционал нельзя раскидывать по всем компонентам, которые он использует.
Вы путаете теплое с мягким, а так же пытаетесь впихнуть функционал модуля апи во все модули с которым он взаимодействует. Это не верный способ организации фича подхода, учитывая что апи это отдельная фича приложения. Во всех ваших примерах, в фичах комментов, постов и т.п. есть рычаги взаимодействия, а в апи модуля эти рычаги используются и должны храниться в одном месте.
В языке по типу Котлин можно было бы описать метод в контексте его надобности (глобально описать трудно, т.к Vip в разном контексте может быть разный, тогда и методов будет куча) и сделать так
order.isVip()
И не надо никаких переменных. Но увы не все языки так могут. Вот и получаем кучу переменных с подробностями что бы не путаться
То, что я написал, это масштабирование БД, если БД не справляется в рамках одного микросервиса. Смотрите мой комментарий ниже по поводу Вашей ситуации в статье
Философия микросервисов фактически копирует философию Unix, согласно которой каждая программа должна «делать что-то одно, и делать это хорошо» и взаимодействовать с другими программами простыми средствами: микросервисы минимальны и предназначаются для единственной функции.
Я скажу даже проще:
Микросервис - это независимая часть большой программы, которая владеет данными и функционалом их модификации и больше никто этого делать не может. Если говорить в рамках MVC, то микросервис это MC
В вашем случае идёт пересечение владения данными, которые используются двумя частями. Разделите их на пользователей и авторизации и сразу все упростится. В идеале это две разные БД на разных машинах. Надо проверить, с микросервиса авторизации, существует ли пользователь? Обращаетесь к сервису пользователей, а не лезете в ее БД.
Если другими словами: в любой момент любой микросервис может поменять модель хранения данных и если лезть в них, обходя ответственного, все сломается. Всегда помните это и МС архитектура подстроится сама собой
Перечисленые этапы "работы" — это не проблема работы, а проблема в нас самих. Мы сами позволяем себе так нами распоряжаться. Подумайте как то на досуге
Самое главное про что все авторы таких статей не пишут — вся инфраструктура завязывается на, к примеру, Амазон и она не работоспособна нигде больше. Если облако повысит цены — можно легко и быстро прогореть
Тимлидов можно поделить на две большие группы: технические и коммуникативные профессионалы. Первые занимают руководящую должность потому что именно они — самые сильные программисты. Вторые хорошо умеют находить общий язык и со всеми членами команды, и с «неадекватным» заказчиком, и со «странным» руководством.
Прочитав это начало — сразу понятно, что автор не видит разницу явно. Отсюда весь огород в статье.
Первые — это технически подкованные люди не сильно общительные и они становятся техлидами, которые следят за качеством разработки, проводят ревью, могут заниматься менторством. Для них работа на тяп ляп — самоуничтожение. Они этого не могут допустить. Именно они обдумывают сложность реализации фич. С ними обычно советуется вся команда, т.к обычно такие люди на голову выше других по знаниям технологий и трендов.
Вторые — публичные общительные люди и они становятся тимлидами, которые управляют скоростью разработки. Они поддерживают определенный темп разработки. Ведут задачи в таскменеджере, общаются со всей командой, ПМ, клиентами. Держат руку на пульсе разработки. Это те люди, которые могут быстро на коленке написать любой код, что бы закрыть дедлайны.
Эти две должности совместить в одном человеке просто не реально. Он выгорит моментально.
Я всем советую — определите свои обязанности в команде или пусть Вам их сообщат. Работа кардинально станет проходить по другому, потому как Вы будете понимать, как Вам действовать в каждой ситуации, к кому обратиться, если это не в вашей компетенции
Очень "интересная" логика. По умолчанию, если выражаться математикой цикл [0,10). В расте об эргономике вообще не думают? Обычно сахар в виде ".." подразумевает полное включение от и до
Boomburum Вижу появился функционал скрытия веток комментариев (раньше скрывало вообще все и это походу был баг?)
А возможно сделать настройку "сворачивать подкомментарии с уровнем больше N" где 0 — выкл.
В настройках не нашел
Проект может в себя включать несколько команд. И в каждой команде должен быть тимлид. РП руководит ТЛ. Каждый ТЛ руководит своей командой. Если команда в проекте одна, то как правило РП и есть ТЛ или наоборот
Это обратный эффект перегруженного мозга. Он начинает урезать не нужные процессы. Эмоциональное состояние - в первую очередь
Езда на моноколесе и еда это уже автоматические привычки. По сути выполняется одна задача - проектирование
А это ещё одна ошибка. Интерфейсы создаются на использующей их стороне. Как ни крути - не надо класть все рядом с тем что будет использовано.
Возьмём такой пример. Апи имеет один и тот же интерфейс. Меняется только апи версия. По Вашей логике будут созданы 2 разных апи рядом с каждым компонентом с которым этот компонент работает.
Апи не важно с чем он взаимодействует. У него есть абстрактные объекты и их методы. Как это сделано под капотом не важно.
Мы с Вами разговариваем на разных языках. Я представляю всю реализацию на интерфейсах, Вы предоставляете на инстансах. Отсюда и возникает необходимость писать код рядом с с тем, с чем он будет взаимодействовать
В этом и состоит ошибка разделения кода по фича стилю. Апи само по себе уже специфично, т.к. предоставляет собственный интерфейс взаимодействия. Поэтому его функционал нельзя раскидывать по всем компонентам, которые он использует.
Вы путаете теплое с мягким, а так же пытаетесь впихнуть функционал модуля апи во все модули с которым он взаимодействует. Это не верный способ организации фича подхода, учитывая что апи это отдельная фича приложения. Во всех ваших примерах, в фичах комментов, постов и т.п. есть рычаги взаимодействия, а в апи модуля эти рычаги используются и должны храниться в одном месте.
Я Ваши примеры организовал так
Если возникает циклическая зависимость - это явный признак выделить общую сущность и сделать рефакторинг
В языке по типу Котлин можно было бы описать метод в контексте его надобности (глобально описать трудно, т.к Vip в разном контексте может быть разный, тогда и методов будет куча) и сделать так
И не надо никаких переменных. Но увы не все языки так могут. Вот и получаем кучу переменных с подробностями что бы не путаться
То, что я написал, это масштабирование БД, если БД не справляется в рамках одного микросервиса. Смотрите мой комментарий ниже по поводу Вашей ситуации в статье
Цитата из той же Википедии:
Я скажу даже проще:
Микросервис - это независимая часть большой программы, которая владеет данными и функционалом их модификации и больше никто этого делать не может. Если говорить в рамках MVC, то микросервис это MC
В вашем случае идёт пересечение владения данными, которые используются двумя частями. Разделите их на пользователей и авторизации и сразу все упростится. В идеале это две разные БД на разных машинах. Надо проверить, с микросервиса авторизации, существует ли пользователь? Обращаетесь к сервису пользователей, а не лезете в ее БД.
Если другими словами: в любой момент любой микросервис может поменять модель хранения данных и если лезть в них, обходя ответственного, все сломается. Всегда помните это и МС архитектура подстроится сама собой
Вы забываете о таком понятии как партицирование и реплики. Вуаля и ваша БД снова летает
Перечисленые этапы "работы" — это не проблема работы, а проблема в нас самих. Мы сами позволяем себе так нами распоряжаться. Подумайте как то на досуге
Согласен. Хороший ПМ получается как раз таки из Тимлида.
Самое главное про что все авторы таких статей не пишут — вся инфраструктура завязывается на, к примеру, Амазон и она не работоспособна нигде больше. Если облако повысит цены — можно легко и быстро прогореть
Перечислены одни крайности. Это и приводит к проблемам
Прочитав это начало — сразу понятно, что автор не видит разницу явно. Отсюда весь огород в статье.
Первые — это технически подкованные люди не сильно общительные и они становятся техлидами, которые следят за качеством разработки, проводят ревью, могут заниматься менторством. Для них работа на тяп ляп — самоуничтожение. Они этого не могут допустить. Именно они обдумывают сложность реализации фич. С ними обычно советуется вся команда, т.к обычно такие люди на голову выше других по знаниям технологий и трендов.
Вторые — публичные общительные люди и они становятся тимлидами, которые управляют скоростью разработки. Они поддерживают определенный темп разработки. Ведут задачи в таскменеджере, общаются со всей командой, ПМ, клиентами. Держат руку на пульсе разработки. Это те люди, которые могут быстро на коленке написать любой код, что бы закрыть дедлайны.
Эти две должности совместить в одном человеке просто не реально. Он выгорит моментально.
Я всем советую — определите свои обязанности в команде или пусть Вам их сообщат. Работа кардинально станет проходить по другому, потому как Вы будете понимать, как Вам действовать в каждой ситуации, к кому обратиться, если это не в вашей компетенции
Очень "интересная" логика. По умолчанию, если выражаться математикой цикл [0,10). В расте об эргономике вообще не думают? Обычно сахар в виде ".." подразумевает полное включение от и до
В Конце, Хорошее и четкое описание того, чем должен заниматься тимлид, техлид и CTO
Boomburum Вижу появился функционал скрытия веток комментариев (раньше скрывало вообще все и это походу был баг?)
А возможно сделать настройку "сворачивать подкомментарии с уровнем больше N" где 0 — выкл.
В настройках не нашел
Проект может в себя включать несколько команд. И в каждой команде должен быть тимлид. РП руководит ТЛ. Каждый ТЛ руководит своей командой. Если команда в проекте одна, то как правило РП и есть ТЛ или наоборот