В мейнстримных компиляторах диагностика ушла вперед, да. Но тот же gcc без флагов -Wall -Werror не покажет никакого предупреждения про некорректное присваивание. В топовых open source проектах это скорее всего включено, поэтому такие ошибки оттуда ушли.
Из этого же не следует, что "теперь не осталось компиляторов, которые промолчат, встретив присваивание в условии"? Проекты под проверку PVS Studio же не случайно выбираются, а по популярности, объему кода и т.д. Выборка скорее всего смещенная. Тот же Хромиум разрабатывают в Гугле и качество кода там скорее всего выше, чем в целом в индустрии.
Утверждение "теперь не осталось компиляторов" неплохо бы подтвердить списком компиляторов, на которых автор проверил это утверждение. Иначе как-то голословно звучит на мой взгляд
Современные компиляторы умеют распознавать опечатку в сравнении и показывать предупреждение в таких случаях. В дополнение к этому предупреждения могут обрабатываться как ошибки, что вызовет ошибку сборки в случае опечатки. В Compiler Explorer видно, что и clang, и gcc, и msvc выдают ошибку с правильными флагами компиляции: https://godbolt.org/z/G73b6sbTM
Так-то с зарплаты, и то если сюда добавить всякие разные социальные взносы, уплачиваемые работодателем. С других видов дохода физлица платят 13/15%. К примеру, налог с прироста капитала или рента какая-нибудь.
Вы пишете, что компании других стран успешно переняли идеи Lean production, что помогло им выиграть ценовую конкуренцию. Из этого не следует, что идеи были плохими, скорее наоборот.
Но из-за того, что многие там продолжили фокусироваться на этой локальной оптимальности, они начинали вредить своему маркетингу и сервису. Или как минимум - не помогать.
Пример про экономику Японии кажется надуманным. Рецессия там началась еще в 1990 году, но какое отношение к этому имеет Lean production непонятно от слова совсем. https://en.wikipedia.org/wiki/Lost_Decades
union в С++ - это удобный инструмент для отстрела конечностей, своих и чужих. В то время как struct - это тот же класс, но с более удобными модификаторами доступа по умолчанию. struct практичен, позволяет писать более короткий и ясный код. Минус у него один - находятся эстеты, которым нравится писать слово "class", а "struct" их коробит по причинам зачастую не вполне рациональным.
Золотые деньги тоже подвержены инфляции, потому что новое золото добывается в рудниках, а товаров от этого процесса больше не становится. После открытия Америки в Европу хлынуло награбленное золото из колоний, что привело к росту цен в "реальных" деньгах. https://ru.wikipedia.org/wiki/Революция_цен
Cложности в таком сценарии вызваны не способом хранения кода, а тем, что 2 проекта долгое время живут независимо друг от друга, код в них сильно расходится, что приводит к большому числу конфликтов. Если оба проекта в итоге будут мержить свой код в основную ветку, то конфликтов не избежать в любом случае, независимо от способа организации кода. Полирепа лишь позволит в каких-то репозиториях этот процесс немного отложить за счет технического долга. Одно из возможных решений тут - не заводить долгоживущих веток. Примерно так: 1. Вливать изменения в основную ветку как можно чаще: дробить коммиты, не накапливать тысячи строк изменений. Бонус - небольшие пулл-реквесты проще ревьювить. 2. Нужен CI, который соберет код и в идеале еще запустит тесты и позволит убедиться, что сервисы во втором проекте не ломаются от изменений в первом. Наличие такого CI дополнительно мотивирует выкладывать код в основную ветку чаще. 3. При необходимости стоит прятать новые фичи под флаги. В качестве бонуса эти флаги потом в A/B тестах можно использовать. 4. Релизить сервисы чаще, не копить изменения месяцами/годами. Проблему разрешения конфликтов в коде все эти меры не решают, но позволяют уменьшить число конфликтов, цену ошибки и т.д.
Переход на версию +1 библиотеки 1 тянет за собой переход на версию +5 библиотеки 2
В монорепе по-хорошему все зависимости должны храниться в самой монорепе. Версионирования библиотек как такового нет, потому что всегда используется та версия, которая закоммичена в текущей ревизии.
Изначально речь шла об организации кода, разрабатываемого внутри компании - хранить ли его в одном большом монорепозитории или в множестве маленьких - полирепозитории. Мой пример относился к сценарию, когда нужно внести изменения в несколько разных частей в кодовой базы - библиотеки, микросервисы, какие-то тулы и т.п. Допустим, мне в рамках работы над проектом надо внести изменения в код 1 сервиса и 2 библиотек, от которых сервис зависит. Если все это хранится в разных репозиториях, то нужно сделать 3 пулл-реквеста. Разве не так? В монорепозитории я могу обойтись 1 пулл-реквестом. В фейсбучной монорепе, о которой пишется в статье, это мог бы быть стек коммитов (диффов), связанных с друг другом. Такой стек можно к примеру поребейзить относительно более свежей ревизии монорепозитория одной командой. В полирепозитории в каждом подрепозитории ребейз (или мердж) нужно делать отдельно.
Ветки можно создавать в любом репозитории: и в моно-, и в поли-. Вот только в полирепе это будет N веток по числу реп, с которыми приходится работать. Не понял ваш комментарий про "ничего лишнего не прилетело". В системе контроля версий вы всегда сами выбираете, какую ревизию счекаутить. Если вы имеете в виду процесс синхронизации долгоживущей ветки с основной, то в полирепе у вас будут те же самые проблемы с мердж-конфликтами. Рано или поздно все ветки придется вмерджить в master/trunk/main etc. После того, как все изменения закоммичены в ветки, все это добро нужно будет отправить на CI и code review. И тут снова вместо одного пулл-реквеста у вас будет N пулл-реквестов. Внутри CI ваш код будет запускаться с другими версиями соседних репозиториев, т.к. в соседних репозиториях пулл-реквесты еще не вмерджены в основную ветку. Соответственно, в разработке это придется учитывать, какие-нибудь флаги и условия расставить. Либо просто забить на CI и мерджить как есть.
Как систему не докомпозируй, а все равно на практике бывает нужно потестить изменения сразу в нескольких репозиториях (или директориях в случае монорепы). И тут монорепа гораздо удобнее. Для удобной работы с коллекцией репозиториев можно накрутить тулинг (например, как в Хромиуме), но в это нужно вкладываться.
Тем не менее бумажки, называемые рублями, в СССР были. Автоматизированную компьютерная система учёта и распределения всего производимого человечеством - это что-то из области фантастики. Хотя бы потому что эта система предполагает единые для всей планеты правила ведения этого самого учета. Сомневаюсь, что человечество способно о таком договориться. Ну и если представить что такая система есть, то там все равно внутри будет какой-то аналог денег для учёта ценности "всего производимого человечеством".
Идеальное общество, как вы его описываете, невозможно. Потому что люди в большинстве своем стараются действовать в своих интересах, которые не всегда коррелируют с интересами общества и его порядками. От соблазна получить что-то за счет окружающих никуда не деться. Кто-то может с этим бороться, а кто-то - нет. А еще к этому можно добавить обычную глупость. Идеальных людей не бывает.
Проблема в том, что бартер и прочие безденежные схемы не масштабируются. Поэтому ваш очень простой пример с домами на практике может работать, а вот с космическими программами так уже не выйдет. Даже в СССР в плановой экономике были деньги, потому что нужна мера оценки вклада каждого участника в экономику.
Ну а как в описанную вами схему вписывается запуск Вояджера? Эти же самые люди, будучи мастерами на все руки, будут еще и Вояджеры запускать из той же самой глины? На практике кирпичи, дома и Вояджеры строят специально обученные люди, а деньги это средство взаимозачетов между этими людьми.
В мейнстримных компиляторах диагностика ушла вперед, да. Но тот же gcc без флагов
-Wall -Werrorне покажет никакого предупреждения про некорректное присваивание. В топовых open source проектах это скорее всего включено, поэтому такие ошибки оттуда ушли.Судя по вашему тону, сраться в комменты пришли вы, а не я
Из этого же не следует, что "теперь не осталось компиляторов, которые промолчат, встретив присваивание в условии"? Проекты под проверку PVS Studio же не случайно выбираются, а по популярности, объему кода и т.д. Выборка скорее всего смещенная. Тот же Хромиум разрабатывают в Гугле и качество кода там скорее всего выше, чем в целом в индустрии.
О каких 8 годах идет речь? Вы о чем сейчас?
Утверждение "теперь не осталось компиляторов" неплохо бы подтвердить списком компиляторов, на которых автор проверил это утверждение. Иначе как-то голословно звучит на мой взгляд
Современные компиляторы умеют распознавать опечатку в сравнении и показывать предупреждение в таких случаях. В дополнение к этому предупреждения могут обрабатываться как ошибки, что вызовет ошибку сборки в случае опечатки.
В Compiler Explorer видно, что и clang, и gcc, и msvc выдают ошибку с правильными флагами компиляции:
https://godbolt.org/z/G73b6sbTM
Так-то с зарплаты, и то если сюда добавить всякие разные социальные взносы, уплачиваемые работодателем. С других видов дохода физлица платят 13/15%. К примеру, налог с прироста капитала или рента какая-нибудь.
Вы пишете, что компании других стран успешно переняли идеи Lean production, что помогло им выиграть ценовую конкуренцию. Из этого не следует, что идеи были плохими, скорее наоборот.
Тут примеров не хватает
Пример про экономику Японии кажется надуманным. Рецессия там началась еще в 1990 году, но какое отношение к этому имеет Lean production непонятно от слова совсем.
https://en.wikipedia.org/wiki/Lost_Decades
union в С++ - это удобный инструмент для отстрела конечностей, своих и чужих. В то время как struct - это тот же класс, но с более удобными модификаторами доступа по умолчанию. struct практичен, позволяет писать более короткий и ясный код. Минус у него один - находятся эстеты, которым нравится писать слово "class", а "struct" их коробит по причинам зачастую не вполне рациональным.
Непонятно почему они не вложат хотя бы часть этих денег в Мекку - инфраструктуру, жилье, транспорт и пр. Так могли бы и деньги отбить с паломников.
Золотые деньги тоже подвержены инфляции, потому что новое золото добывается в рудниках, а товаров от этого процесса больше не становится. После открытия Америки в Европу хлынуло награбленное золото из колоний, что привело к росту цен в "реальных" деньгах.
https://ru.wikipedia.org/wiki/Революция_цен
Cложности в таком сценарии вызваны не способом хранения кода, а тем, что 2 проекта долгое время живут независимо друг от друга, код в них сильно расходится, что приводит к большому числу конфликтов. Если оба проекта в итоге будут мержить свой код в основную ветку, то конфликтов не избежать в любом случае, независимо от способа организации кода. Полирепа лишь позволит в каких-то репозиториях этот процесс немного отложить за счет технического долга.
Одно из возможных решений тут - не заводить долгоживущих веток. Примерно так:
1. Вливать изменения в основную ветку как можно чаще: дробить коммиты, не накапливать тысячи строк изменений. Бонус - небольшие пулл-реквесты проще ревьювить.
2. Нужен CI, который соберет код и в идеале еще запустит тесты и позволит убедиться, что сервисы во втором проекте не ломаются от изменений в первом. Наличие такого CI дополнительно мотивирует выкладывать код в основную ветку чаще.
3. При необходимости стоит прятать новые фичи под флаги. В качестве бонуса эти флаги потом в A/B тестах можно использовать.
4. Релизить сервисы чаще, не копить изменения месяцами/годами.
Проблему разрешения конфликтов в коде все эти меры не решают, но позволяют уменьшить число конфликтов, цену ошибки и т.д.
В монорепе по-хорошему все зависимости должны храниться в самой монорепе. Версионирования библиотек как такового нет, потому что всегда используется та версия, которая закоммичена в текущей ревизии.
Изначально речь шла об организации кода, разрабатываемого внутри компании - хранить ли его в одном большом монорепозитории или в множестве маленьких - полирепозитории. Мой пример относился к сценарию, когда нужно внести изменения в несколько разных частей в кодовой базы - библиотеки, микросервисы, какие-то тулы и т.п. Допустим, мне в рамках работы над проектом надо внести изменения в код 1 сервиса и 2 библиотек, от которых сервис зависит. Если все это хранится в разных репозиториях, то нужно сделать 3 пулл-реквеста. Разве не так? В монорепозитории я могу обойтись 1 пулл-реквестом. В фейсбучной монорепе, о которой пишется в статье, это мог бы быть стек коммитов (диффов), связанных с друг другом. Такой стек можно к примеру поребейзить относительно более свежей ревизии монорепозитория одной командой. В полирепозитории в каждом подрепозитории ребейз (или мердж) нужно делать отдельно.
Ветки можно создавать в любом репозитории: и в моно-, и в поли-. Вот только в полирепе это будет N веток по числу реп, с которыми приходится работать. Не понял ваш комментарий про "ничего лишнего не прилетело". В системе контроля версий вы всегда сами выбираете, какую ревизию счекаутить. Если вы имеете в виду процесс синхронизации долгоживущей ветки с основной, то в полирепе у вас будут те же самые проблемы с мердж-конфликтами. Рано или поздно все ветки придется вмерджить в master/trunk/main etc.
После того, как все изменения закоммичены в ветки, все это добро нужно будет отправить на CI и code review. И тут снова вместо одного пулл-реквеста у вас будет N пулл-реквестов. Внутри CI ваш код будет запускаться с другими версиями соседних репозиториев, т.к. в соседних репозиториях пулл-реквесты еще не вмерджены в основную ветку. Соответственно, в разработке это придется учитывать, какие-нибудь флаги и условия расставить. Либо просто забить на CI и мерджить как есть.
Как систему не докомпозируй, а все равно на практике бывает нужно потестить изменения сразу в нескольких репозиториях (или директориях в случае монорепы). И тут монорепа гораздо удобнее. Для удобной работы с коллекцией репозиториев можно накрутить тулинг (например, как в Хромиуме), но в это нужно вкладываться.
Тем не менее бумажки, называемые рублями, в СССР были. Автоматизированную компьютерная система учёта и распределения всего производимого человечеством - это что-то из области фантастики. Хотя бы потому что эта система предполагает единые для всей планеты правила ведения этого самого учета. Сомневаюсь, что человечество способно о таком договориться. Ну и если представить что такая система есть, то там все равно внутри будет какой-то аналог денег для учёта ценности "всего производимого человечеством".
Идеальное общество, как вы его описываете, невозможно. Потому что люди в большинстве своем стараются действовать в своих интересах, которые не всегда коррелируют с интересами общества и его порядками. От соблазна получить что-то за счет окружающих никуда не деться. Кто-то может с этим бороться, а кто-то - нет. А еще к этому можно добавить обычную глупость. Идеальных людей не бывает.
Проблема в том, что бартер и прочие безденежные схемы не масштабируются. Поэтому ваш очень простой пример с домами на практике может работать, а вот с космическими программами так уже не выйдет. Даже в СССР в плановой экономике были деньги, потому что нужна мера оценки вклада каждого участника в экономику.
Ну а как в описанную вами схему вписывается запуск Вояджера? Эти же самые люди, будучи мастерами на все руки, будут еще и Вояджеры запускать из той же самой глины? На практике кирпичи, дома и Вояджеры строят специально обученные люди, а деньги это средство взаимозачетов между этими людьми.