Есть коврики специальные, котейки стряхивают на них почти все. Но не липнет минеральный наполнитель, который "без запаха", он всегда сухой, потому что быстро все впитывает и цементируется, а силикагель наверное липнет в любом случае, сомневаюсь что он так хорошо и быстро впитывает, как минеральный.
Можно той же самой сетке дать задание оценить свой ответ и доработать его. И дорабатывать пока оценка не станет удовлетворительной. Закольцовывать можно как внешним кодом, так и заставить саму сетку общаться с собой - такие промты тоже есть. Но если это на уровне промтов делать, побочка в том, что весь внутренний диалог сетки вываливается в чатик, так что лучше это прятать. Но наблюдать этот диалог конечно забавно - этакое раздвоение личности, исполнитель и ревизор в одном лице.
Верно. Нужно уметь делегировать, грамотно использовать имеющиеся ресурсы в виде доступных специалистов, тогда достаточно будет лишь выстроить процессы, с учетом реалий на местах, и следить чтобы эти процессы не развалились. И останется лишь роль координатора. Но на практике задача эта не простая, люди не любят изменений, и активно будут противодействовать попыткам выстроить процессы. Нужны крепкие нервы, упертость, навыки убеждения и ведения переговоров. Толковых руководителей немного, но у кого получается, те идут далеко и ярко.
В линукс есть нативный llama.cpp и его производные: запускается сервер с нейронкой, и клиенты к нему шлют запросы. Клиенты есть консольные (сам llama.cpp такой предоставляет), браузерные, есть встроенные в популярные IDE плагинами. Нейронку можно выбрать самому из предустановленного списка или скачать любую другую - они все в стандартных форматах в интернете выложены. Все это работает локально, и доступно на любой современной видеокарте. Nvidia или amd - без разницы, сейчас оба вендора предоставляют равноценную поддержку ускорения нейронок.
Навигатор человека не заменит. Только недавно наблюдал такую картину: навигатор перед перекрестком показывает поворот на спуск, и это ожидаемый вариант, а через минуту навигатор потерялся и начал показывать окраины города, таксист в это время поехал прямо, а не на поворот на спуск, чего я не ожидал, но через 5 минут стало ясно что таксист просто хорошо знает этот район, и просто оптимизировал маршрут через мелкие улочки, а навигатор в себя пришел только уже перед остановкой. Так что тут сразу две проблемы навигатора проявились: он ненадежен и в любой момент может отказать, и он знает дорогу хуже опытного человека.
Нейросети в текущем виде не в состоянии не врать. Это их суть работы: синтез по матрице вероятностей, которую тренируют выдавать наиболее правдоподобные ответы. Но не наиболее правдивые - такой опции нет. Может быть нейросети каких-нибудь других архитектур, принципиально отличных от архитектуры языковых моделей, будут способны хотя бы в подобие мыслительного процесса и минимально осознанных ответов. Текущие же архитектуры на такое принципиально не способны, поэтому их удел пока - всякие развлечения, все что не требует точности и фактов.
Самый правильный вариант не всегда работает. Даже на крупных сайтах не всегда есть какие-либо удобные форматы использования, или же есть только устаревшие проблемные варианты. Разработчик может не разбираться в тонкостях конкретного linux, а их много. У него может просто отсутствовать мотивация поддерживать все это - чего уж говорить, таким страдают даже техногиганты с миллиардными бюджетами.
Так что правильнее, если пакеты под конкретный дистрибутив все же будет компилировать и собирать тот, кто работает с конкретным дистрибутивом.
На практике лучший опыт получается с софтом, исходники которого публично доступны в каком-нибудь репозитории, без регистрации и смс. Для такого софта доступен самый большой набор вариантов: от собственноручной сборки под свою ОС и машину, до прозрачного встраивания софта в любую пакетную базу: любой заинтересованный человек со стороны может подключить чужой публичный репозиторий к своей системе сборки пакетов, без какой-либо бюрократии и ограничений.
Такой софт доступен практически во всех пакетных базах, даже самых экзотических, и в каждой собирается по-своему: где-то статически, где-то под конкретные системные библиотеки доступные в конкретном релизе дистрбутива.
Сейчас много всяких dns со встроенными фильтрами от рекламы и трекинга, достаточно один раз озаботиться и прописать в роутер, и даже не замечаешь что реклама существует. Настолько не замечаешь, что перестаешь понимать на что жалуются люди, забываешь как выглядит интернет без фильтров
Что там с фильмом непонятно, но в играх с HDR разница видна: на SDR все хорошо, но нужно выбирать, или яркие источники света и вместо теней черное пятно, или пересвет но зато видно что в тенях делается, а с HDR доступны одновременно и яркие источники света и детали в тенях - динамический диапазон явно больше, можно заглядывать с улицы в пещеру или тоннель и видеть там что-то. Но некоторые игры это портят эффектом адаптации зрения: на ярких сценах через короткое время затемняют тени, а в темных сценах наоборот завышают яркость неба в окнах.
Также HDR сильно поднимает яркость точечных источников: например яркая-яркая луна ночью на фоне полутьмы окружения. На OLED это неплохо выглядит - там в таких сценах яркости могут быть огромные, хотя на всю панель такую яркость они выдать не способны, перегреваются мгновенно, полная яркость доступна только точечно.
Для 3D сейчас целый класс устройств появился - очки виртуальной реальности и сопутствующие аксессуары
А вот с HDR до сих пор не определились - нарожали 100500 стандартов, и нативно их никто не поддерживает. Что в windows, что в linux HDR прикрутили костылями. Много проблем на ровном месте с этим HDR. Хотя картинка конечно лучше - больше деталей в тенях. Но сейчас и моники научились тени высветлять из коробки, всякие игровые режимы на это и заточены. Хотелось бы чтобы стандарты HDR устаканились и все работало из коробки, как это сейчас с SDR происходит: кабель подключил и не заморачиваешься более.
Приличный ИИ на домашнем компе запускать дорого. А с учетом того, что эти ИИ еще и бестолковые - и смысла в этом нет.
Если хочется поиграться с ИИ - есть облачные решения, и бесплатные, и недорогие коммерческие. В одном телеграмм этих ИИ-ботов целое ведро. В винду и в браузер встроены бесплатные ИИ. Этого более чем достаточно, чтобы поиграться.
Это может быть и гравитационное сжатие: может быть до далеких объектов просто чуть дальше, а мы их видим чуть ближе чем они есть, вот и разница набегает. Или это может быть низкочастотная гравитационная тень от какого-то сверхмассивного объекта, из-за пределов наблюдений, самый ее краешек, который докатывается до нас, очень пологий край огромной гравиворонки, очень слабой из-за огромного расстояния до источника.
Там, наверху, в кулуарах, у ученых сейчас фонтан теорий, большинство из которых сразу отметаются. Рано или поздно найдут несколько более-менее правдоподобных и будут выяснять что подходит под факты.
Абсолютно верно. Потому что консольный инструмент может быть встроен в пайплайн обработки чего-либо и вызываться тысячи раз подряд, как это принято в консольной среде.
Маломощные - конечно. Но большинство пользователей желает иметь мощные GPU, пригодные для игр, и так или иначе вынуждены использовать дискретные GPU.
Мощные GPU, пригодные для современных игр, переехали под крышку процессора относительно недавно, в последние 1-2 поколения процессоров. И дальше мощность этих GPU будет расти, постепенно снижая зависимость пользователей от дискретных GPU.
Конечно тут встанет вопрос с охлаждением всего этого пирога чипов, но его так или иначе решат. Пока же дискретные GPU все еще в приоритете у пользователей, не смотря на то, что последние поколения интегрированных GPU уже приближаются к возможностям дискретных GPU.
Это уже не HDD, и не SSD, а что-то уровня оптических накопителей. Были новости что что-то подобное есть у intel, для внутреннего хранения холодных архивов данных, вместо ленточных стримеров. Также в фантастике уже более полувека витает идея неких кристаллических накопителей, состоящих из собственно массива оптической памяти в виде некого прозрачного кристалла различных форм, и собственно считывающей головки в виде паза под кристалл с вмонтированным внутри лазером, оснащенным оптикой для трехмерного сканирования этого самого кристалла на предмет аномалий в структуре. Технически идея имеет право на жизнь, те же кристаллы всяких видов уже неплохо умеем выращивать, довольно недорого, высокого качества, а оптика и приводы дело нехитрое, тот же оптостаб схожего принципа в каждом смартфоне присутствует, управляющая электроника для всего этого тоже уже отработана, но тут есть фундаментальные проблемы в точности и энергетике, считывать данные не очень сложно, сложно их записывать, к тому же стандартов на такое пока нет и близко, не говоря уже о каких-либо серийных образцах таких накопителей, так что такие технологии пока виднеются где-то в далекой перспективе. Хотя мощные лазеры, способные прожигать кристаллы, уже существуют и очень доступны, доступна и недорогая оптика для них, и даже существуют серийные образцы схожих записывающих устройств низкой точности - их сейчас используют для производства всевозможных стеклянных игрушек, выжигая всякие узоры внутри объема стекла. Но вот все вместе в одном накопителе это совместить пока никому в голову не пришло.
В микросервисной архитектуре все так, да: каждая команда сама решает, без оглядки на остальных, главное чтобы протокол взаимодействия сервисов был документирован и соблюдался. Описанное в посте все же наверное больше проявляется именно в огромных монорепах: в одной части все на коллекциях, в другой на циклах, в третьей вообще рекурсия, а в четвертой автор упоролся в побитовые операции, потому что привык так писать для МК - несколько человек писали в разных стилях, как им было удобно, они свои задачи решили и забыли, а все последующие, стараясь соблюдать существующий стиль, продолжают писать именно в том стиле, который видят в конкретном месте кода, просто потому что проще сделать так, чем связываться с бюрократией и что-то менять. За редкими исключениями: у некоторых все же рано или поздно не выдерживают нервы, и они переписывают какие-то реализации в своем стиле, и таких переписываний туда-сюда за время жизни монорепы может быть несколько штук для одного и того же участка кода.
С микросервисами все гораздо проще: кода немного, его можно быстро понять, команда маленькая, можно со всеми договориться о чем угодно, ответственность за сервис полностью на команде, можно принимать самые смелые решения и делать так, как требуется, а не так, как вынуждает тонна легаси в монорепе, вот и получается что каких-то серьезных проблем с поддержкой просто не возникает, а те что бывают, их можно решить силами команды, просто пользуясь полной свободой в принятии решений.
Даже в пределах одной версии языка на большом моно-проекте в разных частях присутствует разный стиль, т.к. за разные части большого проекта отвечают разные люди, весь проект кому-то одному физически нет возможности охватить, это слишком большой объем информации для человеческого мозга. Разные части еще и написаны в разное время и разными людьми, многих из которых уже нет на проекте. А неизбежная текучка приводит к постепенной утрате экспертизы, и через несколько лет уже не остается тех, кто знает код достаточно хорошо - начинают появляться велосипеды и дублирующая функциональность: люди не знают что уже что-то где-то в недрах кода решено, и пишут свои реализации, и эти реализации множатся. Старый код постепенно начинает отмирать - появляются и растут фрагменты кода, которые больше ни за что не отвечают, не работают, не вызываются, но их просто некому удалить, уже никто уже не может сказать можно ли этот фрагмент трогать, и не поломает ли это что-то, и желающих рисковать нет. Затрудняется поддержка: команда больше не контролирует кодовую базу, кодовая база начинает жить своей жизнью, пухнуть в размерах и сложности. Растет количество ошибок: команда не контролирует код, боится его трогать, никто больше не понимает как он вообще работает, из каких частей состоит - проект превращается в огромный черный ящик. Поддержка такого кода становится настоящей болью для команды, и все меньше и меньше людей хотят в это ввязываться, и деньги тут уже второстепенный фактор, нервы дороже. А еще за эту боль никто не доплачивает: можно уйти на туже или большую зарплату в небольшой молодой проект и забыть про легаси-монстров с огромными монорепозиториями и вечным хаосом, болью и страданиями
Собственно почему и имеет смысл большие проекты разбивать на отдельные части, и связывать их общим публичным интерфейсом, который стандартизируется и закрепляется в документации, и выносить их код в отдельные репозитории. Тогда совершенно не важно что разные части написаны в разном стиле, т.к. за них отвечают отдельные команды, которые их полностью контролируют. Сам код, и соответственно сферы ответственности команд, никак не пересекаются с другими частями проекта, важно лишь чтобы все команды придерживались единого публичного интерфейса. И самим командам проще работать с такими проектами: уже не нужно разрываться и растекаться по огромной кодовой базе, достаточно наработать экспертизу по той небольшой ее части, за которую отвечает твоя команда, что сделать не так сложно. Людей на такие проекты тоже проще искать: погрузиться в небольшую кодовую базу значительно проще, чем в огромного легаси-монстра, в его темные джунгли, которые полны неизвестности и опасностей. Важно что команда способна полностью контролировать свою небольшую часть кодовой базы, и, если нужно, даже переписать ее с нуля, т.к. в сфере ответственности каждой команды вполне конкретная и относительно небольшая часть общего функционала, роль этой части в общем проекте четко описана, ожидаемое поведение документировано, детали реализации полностью отданы в руки конкретной команды. Сейчас такие архитектуры модно обзывать микросервисными, но это не обязательно могут быть прям отдельные сервисы, главное разграничить код и сферы ответственности, стандартизировать интерфейс взаимодействия, иначе быть беде
https://habr.com/ru/articles/852900/ и https://habr.com/ru/companies/mts_ai/articles/831220/ - еще пара кирпичиков в фундамент нормального ассистента, возможность не только формировать ответы, но и взаимодействовать с окружением
Есть коврики специальные, котейки стряхивают на них почти все. Но не липнет минеральный наполнитель, который "без запаха", он всегда сухой, потому что быстро все впитывает и цементируется, а силикагель наверное липнет в любом случае, сомневаюсь что он так хорошо и быстро впитывает, как минеральный.
Можно той же самой сетке дать задание оценить свой ответ и доработать его. И дорабатывать пока оценка не станет удовлетворительной. Закольцовывать можно как внешним кодом, так и заставить саму сетку общаться с собой - такие промты тоже есть. Но если это на уровне промтов делать, побочка в том, что весь внутренний диалог сетки вываливается в чатик, так что лучше это прятать. Но наблюдать этот диалог конечно забавно - этакое раздвоение личности, исполнитель и ревизор в одном лице.
Без обид, но это уже попахивает коррупцией. Очень странно что за него еще и кто-то его работу делает.
Верно. Нужно уметь делегировать, грамотно использовать имеющиеся ресурсы в виде доступных специалистов, тогда достаточно будет лишь выстроить процессы, с учетом реалий на местах, и следить чтобы эти процессы не развалились. И останется лишь роль координатора. Но на практике задача эта не простая, люди не любят изменений, и активно будут противодействовать попыткам выстроить процессы. Нужны крепкие нервы, упертость, навыки убеждения и ведения переговоров. Толковых руководителей немного, но у кого получается, те идут далеко и ярко.
В линукс есть нативный llama.cpp и его производные: запускается сервер с нейронкой, и клиенты к нему шлют запросы. Клиенты есть консольные (сам llama.cpp такой предоставляет), браузерные, есть встроенные в популярные IDE плагинами. Нейронку можно выбрать самому из предустановленного списка или скачать любую другую - они все в стандартных форматах в интернете выложены. Все это работает локально, и доступно на любой современной видеокарте. Nvidia или amd - без разницы, сейчас оба вендора предоставляют равноценную поддержку ускорения нейронок.
Навигатор человека не заменит. Только недавно наблюдал такую картину: навигатор перед перекрестком показывает поворот на спуск, и это ожидаемый вариант, а через минуту навигатор потерялся и начал показывать окраины города, таксист в это время поехал прямо, а не на поворот на спуск, чего я не ожидал, но через 5 минут стало ясно что таксист просто хорошо знает этот район, и просто оптимизировал маршрут через мелкие улочки, а навигатор в себя пришел только уже перед остановкой. Так что тут сразу две проблемы навигатора проявились: он ненадежен и в любой момент может отказать, и он знает дорогу хуже опытного человека.
Нейросети в текущем виде не в состоянии не врать. Это их суть работы: синтез по матрице вероятностей, которую тренируют выдавать наиболее правдоподобные ответы. Но не наиболее правдивые - такой опции нет. Может быть нейросети каких-нибудь других архитектур, принципиально отличных от архитектуры языковых моделей, будут способны хотя бы в подобие мыслительного процесса и минимально осознанных ответов. Текущие же архитектуры на такое принципиально не способны, поэтому их удел пока - всякие развлечения, все что не требует точности и фактов.
Самый правильный вариант не всегда работает. Даже на крупных сайтах не всегда есть какие-либо удобные форматы использования, или же есть только устаревшие проблемные варианты. Разработчик может не разбираться в тонкостях конкретного linux, а их много. У него может просто отсутствовать мотивация поддерживать все это - чего уж говорить, таким страдают даже техногиганты с миллиардными бюджетами.
Так что правильнее, если пакеты под конкретный дистрибутив все же будет компилировать и собирать тот, кто работает с конкретным дистрибутивом.
На практике лучший опыт получается с софтом, исходники которого публично доступны в каком-нибудь репозитории, без регистрации и смс. Для такого софта доступен самый большой набор вариантов: от собственноручной сборки под свою ОС и машину, до прозрачного встраивания софта в любую пакетную базу: любой заинтересованный человек со стороны может подключить чужой публичный репозиторий к своей системе сборки пакетов, без какой-либо бюрократии и ограничений.
Такой софт доступен практически во всех пакетных базах, даже самых экзотических, и в каждой собирается по-своему: где-то статически, где-то под конкретные системные библиотеки доступные в конкретном релизе дистрбутива.
Сейчас много всяких dns со встроенными фильтрами от рекламы и трекинга, достаточно один раз озаботиться и прописать в роутер, и даже не замечаешь что реклама существует. Настолько не замечаешь, что перестаешь понимать на что жалуются люди, забываешь как выглядит интернет без фильтров
Что там с фильмом непонятно, но в играх с HDR разница видна: на SDR все хорошо, но нужно выбирать, или яркие источники света и вместо теней черное пятно, или пересвет но зато видно что в тенях делается, а с HDR доступны одновременно и яркие источники света и детали в тенях - динамический диапазон явно больше, можно заглядывать с улицы в пещеру или тоннель и видеть там что-то. Но некоторые игры это портят эффектом адаптации зрения: на ярких сценах через короткое время затемняют тени, а в темных сценах наоборот завышают яркость неба в окнах.
Также HDR сильно поднимает яркость точечных источников: например яркая-яркая луна ночью на фоне полутьмы окружения. На OLED это неплохо выглядит - там в таких сценах яркости могут быть огромные, хотя на всю панель такую яркость они выдать не способны, перегреваются мгновенно, полная яркость доступна только точечно.
Для 3D сейчас целый класс устройств появился - очки виртуальной реальности и сопутствующие аксессуары
А вот с HDR до сих пор не определились - нарожали 100500 стандартов, и нативно их никто не поддерживает. Что в windows, что в linux HDR прикрутили костылями. Много проблем на ровном месте с этим HDR. Хотя картинка конечно лучше - больше деталей в тенях. Но сейчас и моники научились тени высветлять из коробки, всякие игровые режимы на это и заточены. Хотелось бы чтобы стандарты HDR устаканились и все работало из коробки, как это сейчас с SDR происходит: кабель подключил и не заморачиваешься более.
Приличный ИИ на домашнем компе запускать дорого. А с учетом того, что эти ИИ еще и бестолковые - и смысла в этом нет.
Если хочется поиграться с ИИ - есть облачные решения, и бесплатные, и недорогие коммерческие. В одном телеграмм этих ИИ-ботов целое ведро. В винду и в браузер встроены бесплатные ИИ. Этого более чем достаточно, чтобы поиграться.
Это может быть и гравитационное сжатие: может быть до далеких объектов просто чуть дальше, а мы их видим чуть ближе чем они есть, вот и разница набегает. Или это может быть низкочастотная гравитационная тень от какого-то сверхмассивного объекта, из-за пределов наблюдений, самый ее краешек, который докатывается до нас, очень пологий край огромной гравиворонки, очень слабой из-за огромного расстояния до источника.
Там, наверху, в кулуарах, у ученых сейчас фонтан теорий, большинство из которых сразу отметаются. Рано или поздно найдут несколько более-менее правдоподобных и будут выяснять что подходит под факты.
Абсолютно верно. Потому что консольный инструмент может быть встроен в пайплайн обработки чего-либо и вызываться тысячи раз подряд, как это принято в консольной среде.
Именно так, маркетологи будут в восторге
Маломощные - конечно. Но большинство пользователей желает иметь мощные GPU, пригодные для игр, и так или иначе вынуждены использовать дискретные GPU.
Мощные GPU, пригодные для современных игр, переехали под крышку процессора относительно недавно, в последние 1-2 поколения процессоров. И дальше мощность этих GPU будет расти, постепенно снижая зависимость пользователей от дискретных GPU.
Конечно тут встанет вопрос с охлаждением всего этого пирога чипов, но его так или иначе решат. Пока же дискретные GPU все еще в приоритете у пользователей, не смотря на то, что последние поколения интегрированных GPU уже приближаются к возможностям дискретных GPU.
Это уже не HDD, и не SSD, а что-то уровня оптических накопителей. Были новости что что-то подобное есть у intel, для внутреннего хранения холодных архивов данных, вместо ленточных стримеров. Также в фантастике уже более полувека витает идея неких кристаллических накопителей, состоящих из собственно массива оптической памяти в виде некого прозрачного кристалла различных форм, и собственно считывающей головки в виде паза под кристалл с вмонтированным внутри лазером, оснащенным оптикой для трехмерного сканирования этого самого кристалла на предмет аномалий в структуре. Технически идея имеет право на жизнь, те же кристаллы всяких видов уже неплохо умеем выращивать, довольно недорого, высокого качества, а оптика и приводы дело нехитрое, тот же оптостаб схожего принципа в каждом смартфоне присутствует, управляющая электроника для всего этого тоже уже отработана, но тут есть фундаментальные проблемы в точности и энергетике, считывать данные не очень сложно, сложно их записывать, к тому же стандартов на такое пока нет и близко, не говоря уже о каких-либо серийных образцах таких накопителей, так что такие технологии пока виднеются где-то в далекой перспективе. Хотя мощные лазеры, способные прожигать кристаллы, уже существуют и очень доступны, доступна и недорогая оптика для них, и даже существуют серийные образцы схожих записывающих устройств низкой точности - их сейчас используют для производства всевозможных стеклянных игрушек, выжигая всякие узоры внутри объема стекла. Но вот все вместе в одном накопителе это совместить пока никому в голову не пришло.
В микросервисной архитектуре все так, да: каждая команда сама решает, без оглядки на остальных, главное чтобы протокол взаимодействия сервисов был документирован и соблюдался. Описанное в посте все же наверное больше проявляется именно в огромных монорепах: в одной части все на коллекциях, в другой на циклах, в третьей вообще рекурсия, а в четвертой автор упоролся в побитовые операции, потому что привык так писать для МК - несколько человек писали в разных стилях, как им было удобно, они свои задачи решили и забыли, а все последующие, стараясь соблюдать существующий стиль, продолжают писать именно в том стиле, который видят в конкретном месте кода, просто потому что проще сделать так, чем связываться с бюрократией и что-то менять. За редкими исключениями: у некоторых все же рано или поздно не выдерживают нервы, и они переписывают какие-то реализации в своем стиле, и таких переписываний туда-сюда за время жизни монорепы может быть несколько штук для одного и того же участка кода.
С микросервисами все гораздо проще: кода немного, его можно быстро понять, команда маленькая, можно со всеми договориться о чем угодно, ответственность за сервис полностью на команде, можно принимать самые смелые решения и делать так, как требуется, а не так, как вынуждает тонна легаси в монорепе, вот и получается что каких-то серьезных проблем с поддержкой просто не возникает, а те что бывают, их можно решить силами команды, просто пользуясь полной свободой в принятии решений.
Даже в пределах одной версии языка на большом моно-проекте в разных частях присутствует разный стиль, т.к. за разные части большого проекта отвечают разные люди, весь проект кому-то одному физически нет возможности охватить, это слишком большой объем информации для человеческого мозга. Разные части еще и написаны в разное время и разными людьми, многих из которых уже нет на проекте. А неизбежная текучка приводит к постепенной утрате экспертизы, и через несколько лет уже не остается тех, кто знает код достаточно хорошо - начинают появляться велосипеды и дублирующая функциональность: люди не знают что уже что-то где-то в недрах кода решено, и пишут свои реализации, и эти реализации множатся. Старый код постепенно начинает отмирать - появляются и растут фрагменты кода, которые больше ни за что не отвечают, не работают, не вызываются, но их просто некому удалить, уже никто уже не может сказать можно ли этот фрагмент трогать, и не поломает ли это что-то, и желающих рисковать нет. Затрудняется поддержка: команда больше не контролирует кодовую базу, кодовая база начинает жить своей жизнью, пухнуть в размерах и сложности. Растет количество ошибок: команда не контролирует код, боится его трогать, никто больше не понимает как он вообще работает, из каких частей состоит - проект превращается в огромный черный ящик. Поддержка такого кода становится настоящей болью для команды, и все меньше и меньше людей хотят в это ввязываться, и деньги тут уже второстепенный фактор, нервы дороже. А еще за эту боль никто не доплачивает: можно уйти на туже или большую зарплату в небольшой молодой проект и забыть про легаси-монстров с огромными монорепозиториями и вечным хаосом, болью и страданиями
Собственно почему и имеет смысл большие проекты разбивать на отдельные части, и связывать их общим публичным интерфейсом, который стандартизируется и закрепляется в документации, и выносить их код в отдельные репозитории. Тогда совершенно не важно что разные части написаны в разном стиле, т.к. за них отвечают отдельные команды, которые их полностью контролируют. Сам код, и соответственно сферы ответственности команд, никак не пересекаются с другими частями проекта, важно лишь чтобы все команды придерживались единого публичного интерфейса. И самим командам проще работать с такими проектами: уже не нужно разрываться и растекаться по огромной кодовой базе, достаточно наработать экспертизу по той небольшой ее части, за которую отвечает твоя команда, что сделать не так сложно. Людей на такие проекты тоже проще искать: погрузиться в небольшую кодовую базу значительно проще, чем в огромного легаси-монстра, в его темные джунгли, которые полны неизвестности и опасностей. Важно что команда способна полностью контролировать свою небольшую часть кодовой базы, и, если нужно, даже переписать ее с нуля, т.к. в сфере ответственности каждой команды вполне конкретная и относительно небольшая часть общего функционала, роль этой части в общем проекте четко описана, ожидаемое поведение документировано, детали реализации полностью отданы в руки конкретной команды. Сейчас такие архитектуры модно обзывать микросервисными, но это не обязательно могут быть прям отдельные сервисы, главное разграничить код и сферы ответственности, стандартизировать интерфейс взаимодействия, иначе быть беде