Автор неправ. Аргументы за — какие-то высосанные из пальца. Из серии «сам придумал — сам с собой поспорил».
Потому что, на большом масштабе монорепозиторий будет решать все те же самые проблемы, которые решает и полирепозиторий, но при этом провоцируя вас к сильной связанности вашего кода и требуя невероятных усилий по увеличению масштабируемости вашей системы контроля версий. Таким образом, в среднесрочной и долгосрочной перспективе монорепозиторий не дает никаких организационных преимуществ, в то время как оставляет лучших инженеров компании с пост-травматическим синдромом (проявляется в виде пускания слюней и бессвязного бормотания о производительности git).
что я подразумеваю под «на большом масштабе»? Нет однозначного ответа на этот вопрос, но т.к. я уверен, что вы спросите меня об этом, давайте скажем, что это около 100 разработчиков, пишущих код фул-тайм.
Исходя из того, что разработчик в каждый момент времени будет иметь доступ только к небольшой порции исходного кода, есть ли хоть какая-то разница между загрузкой части монорепозитория или загрузкой нескольких независимых репозиториев? Разницы нет.
Следующий аргумент, приводимый обычно сторонниками монорепозиториев, заключается в том, что хранение всего кода в одном монорепозитории лишает вас необходимости управлять зависимостями, т.к. весь код собирается в одно и то же время. Это ложь! На большом масштабе просто нет возможности пересобирать весь исходный код и прогонять все автоматизированные тесты каждый раз, когда кто-то коммитит изменения в систему контроля версий
На больших проектах монорепозиторий действительно не нужен. Но на малых проектах, или в малых командах (и особенно если всего 1 разработчик), или вообще в начале проекта — монорепозиторий очень удобен. Если проект-прототип получит развитие, то уже далее, в какой-то момент монорепозиторий надо будет разделить.
Проведу некую аналогию — было множество споров, что лучше — монолит или микросервисы. У каждой из архитектур свои + и -. Я считаю что существует промежуточный вариант — микросервисный монолит, который будет жить в монорепозитории. Он хорош на старте проекта, и если проект «взлетит» и получит развитие, то будет рефакторинг в честные микросервисы и разные репозитории.
Если разум нужен нам для того, чтобы формировать здравые суждения, то трудно представить себе более серьезный производственный брак, чем предвзятость подтверждения («склонность к подтверждению своей точки зрения»). Представьте себе мышь, которая мыслит как человек. Эта мышь, «которая ищет подтверждения тому, что вокруг нет котов», вскоре станет кошачьим обедом. Тот факт, что выжило и человечество, и эта его черта, говорит о том, что у нее есть некая адаптирующая функция."
Я бы добавил поле — сколько времени потратил исполнитель на выполнение поручения. А потом статистику — 90% времени уходит на ненужные поручения. Или на работу на заполнения ненужных данных. А вместо «предоставить информацию» — вот автоматизированный отчёт, сам смотри.
Зря вы так про «Да какая разница сколько она весит». Я смотрю на это. Это как толщина книги, выбрать что-то на пару часов или на полдня.
И статус синхронизации меня не вводит в заблуждение, да и навигация устраивает.
Большинство неудобств этого подхода можно выявить при попытке сделать UI для редактирования. Если посмотреть репозиторий, на вот это ChangePubDateService: IChangePubDateService -> public Book UpdateBook(ChangePubDateDto dto) То вот вообще не хочется делать отдельный сервис (+ интерфейс, + DTO) для изменения Title, отдельно для изменения Description, отдельно если надо их изменить одновременно.
Куча boilerplate, ради академичности.
Ну почему сразу костыль, и только для конкретного абонента. База общая, и для всех кто поставил прогу.
Черный список решает проблему спокойствия абонента. Лично для меня это важнее. И оно работает уже сейчас, а не когда-нибудь когда победит добро.
Если цель другая — нанести побольше ущерба спамеру, то видимо и инструмент нужен другой. И не факт что это решается технически.
Более эффективно установить на телефон прогу, которая при звонке пробьёт номер по базе спамеров через интернет, и автоматом повесит трубку, а после звонка предложит добавить номер в эту базу. Уже есть готовое решение под андроид.
Хотя Electron-приложения — это растущее и развивающееся явление, и их реализация близка к реализации веб-приложений, у них, всё же, есть некоторые минусы. Во-первых, такие приложения используют собственные экземпляры браузера Chromium. Многие знают о том, сколько оперативной памяти нужно для работы Chrome. Теперь, для того, чтобы оценить ситуацию, возникающую в системе при одновременном запуске нескольких Electron-приложений, надо взять их количество и умножить на этот объём памяти. Если интересно — откройте несколько Electron-приложений и посмотрите на то, сколько памяти они потребляют.
В этой фразе можно заменить Electron на PWA и она будет истиной. Так чем тогда лучше?
В том, что на бэке мы генерируем те самые валидные devid с определенным лимитом по времени. Например, не более 1000 шт в минуту.
А храните их где? Я бы снял нагрузку на их прегенерацию и хранение добавлением поля devid_sign (шифрование), по которому и проверять валидность. А счётчик неуспешных попыток положил бы в redis, с устареванием по времени.
Генерироваться из чего? Если имеется ввиду сам код, то на практике это вряд ли реализуемо
А это зависит от выбранных инструментов/языка программирования.
Я пишу под .Net, для автогенерации есть либа, подключить — несколько строчек.
Для Java и Php наверняка тоже есть аналоги, reflection api ведь у них есть.
Для Js, ну да, тяжелый случай, есть нет Typescript.
А какие проблемы вы видите с версионированием?
Большое количество версий, распухание спецификации. Исходная проблема ведь так и обозначена «спецификации может быстро разрастись до нескольких тысяч строк. В таком виде поддерживать этот файл вручную невозможно.»
У OpenAPI есть серьёзный недостаток — сложность структуры и, зачастую, избыточность. Для небольшого проекта содержимое JSON-файла спецификации может быстро разрастись до нескольких тысяч строк. В таком виде поддерживать этот файл вручную невозможно. Это — серьёзная угроза для самой идеи поддержания актуальной спецификации по мере развития API.
Просто этот файл должен генерироваться автоматически.
Вместо создания нового стандарта «который проще вручную редактировать».
И это вы ещё до версионирования не добрались.
На больших проектах монорепозиторий действительно не нужен. Но на малых проектах, или в малых командах (и особенно если всего 1 разработчик), или вообще в начале проекта — монорепозиторий очень удобен. Если проект-прототип получит развитие, то уже далее, в какой-то момент монорепозиторий надо будет разделить.
Проведу некую аналогию — было множество споров, что лучше — монолит или микросервисы. У каждой из архитектур свои + и -. Я считаю что существует промежуточный вариант — микросервисный монолит, который будет жить в монорепозитории. Он хорош на старте проекта, и если проект «взлетит» и получит развитие, то будет рефакторинг в честные микросервисы и разные репозитории.
или ставьте третий хост.
И статус синхронизации меня не вводит в заблуждение, да и навигация устраивает.
github.com/JonPSmith/EfCore.GenericBizRunner/blob/46766b6b1cec3956daacac28cd6b1ce9cd0e68da/ServiceLayer/BookServices/Concrete/ChangePubDateService.cs#L35
Куча boilerplate, ради академичности.
Черный список решает проблему спокойствия абонента. Лично для меня это важнее. И оно работает уже сейчас, а не когда-нибудь когда победит добро.
Если цель другая — нанести побольше ущерба спамеру, то видимо и инструмент нужен другой. И не факт что это решается технически.
Один из шагов настройки ПИД регулятора — это проверка по критериям устойчивости. Это математика. У вас регулятор настроен методом перебора параметров.
Мне не хватает.
Нет поддержки resx-файлов.
Да и nuget-manager неудобен.
В этой фразе можно заменить Electron на PWA и она будет истиной. Так чем тогда лучше?
А храните их где? Я бы снял нагрузку на их прегенерацию и хранение добавлением поля devid_sign (шифрование), по которому и проверять валидность. А счётчик неуспешных попыток положил бы в redis, с устареванием по времени.
А это зависит от выбранных инструментов/языка программирования.
Я пишу под .Net, для автогенерации есть либа, подключить — несколько строчек.
Для Java и Php наверняка тоже есть аналоги, reflection api ведь у них есть.
Для Js, ну да, тяжелый случай, есть нет Typescript.
Большое количество версий, распухание спецификации. Исходная проблема ведь так и обозначена «спецификации может быстро разрастись до нескольких тысяч строк. В таком виде поддерживать этот файл вручную невозможно.»
Просто этот файл должен генерироваться автоматически.
Вместо создания нового стандарта «который проще вручную редактировать».
И это вы ещё до версионирования не добрались.