Работа не остановится потому что кто-то будет чуть меньше пить чай в рабочее время. Ваш персонал (если вы в своем уме) не загружен на 100% в нормальной ситуации. И вот эта подушка ежедневной неэффективности - дает вам антихрупкость: сотрудник ушел, а работа выполняется. Не то чтобы это всем нравилось - но выполняется!
Дальше - с чего бы за пару-тройку месяцев пока придет и впряжется новый сотрудник у вас уволился костяк ? Нет, разумеется - если вы объявили что увольнения продолжатся и каждый потенциально под прицелом - люди начнут проактивно искать работу и уйдут. Но если все знают что вы ищете замену, участвуют в собесах с кандидатами - такого эффекта я лично не наблюдал. В принципе, правильно выше написали - реакция коллектива зависит от отношений в нем - и с начальством. Если начальство относится к работникам как к холопам - это одна ситуация. Если установлены здоровые рабочие отношения - принципиально другая...
Не отменяя наличие эффективных менеджеров - я тем не менее буду утверждать что нормальная текучесть кадров уже учтена в бизнес-модели и в зарплатах всех участников процесса. Причем если у вас текучесть сегодня равна нулю - вы эту экономию никогда в жизни не увидите на банковском счете. Скорее - кто-то будет чуть дольше пить чай в рабочее время.
И да - у вас проблема если люди уходят - не успев прийти. И если у вас решила уволиться половина сотрудников в один день - это тоже проблема. Но пока вы находитесь плюс-минус в среднем по рынку - неэффективность от временного перераспределения работы, найма и адаптации - это эффект второго порядка малости от того бардака, который обычно имеет место в нормальном предприятии. Это не значит что надо бардак починить - потому что максимальная эффективность любой системы достигается на границе ее устойчивости ("паровой котел предельно эффективен в последнюю миллисекунду перед взрывом"). Однако - возмущение от единичных замен сотрудников система вполне себе переживает без особого вреда для себя.
Другой аргумент - если бы разница в цене для фирмы между состояниями: "должность не занята, на балансе деньги" и "должность занята, на балансе человеческий капитал" - действительно достигала тех миллионов про которые пишут консультанты - рынок неизбежно реагировал на это появлением замещающих товаров и повышением цены труда. Так что равновесие восстановилось бы...
Поэтому к сказкам про миллионы, которые компании теряют от ухода сотрудников - я отношусь примерно как к советам коучей от тайм-менеджмента пить кофе на ходу и не чинить самому кран: потому что это же жуткая потеря времени, эквивалентная целому состоянию - если помножить это на стоимость рабочего часа и на длительность жизни. По факту вам никто не заплатит ни копейки! Ни за то что вы пили кофе стоя, ни за то проведете ли вы выходной с разводным ключем в ванной - или с пивом под телевизор. Уж есть так хочется что-то пооптимизировать - тогда надо брать теорию ограничений Голдратта.
Короче - "... в топку, Зина! И этого, как его - Кауцкого - тоже в топку!" (С) проф. Преображенский.
К заголовку статьи - заменить разработчика не стоит примерно ничего. Точнее - это стоит некоторой потери эффективности организации процесса в моменте, но она настолько незаметна на фоне неэффективности рядовой организации - что даже говорить об этом смешно. При этом да, заинтересованные лица (от "экспертов рынка" до "кадровых агентств") могут вам нарисовать креативные расчеты, показывающие что не сотрудничая именно с ними вы теряете миллионы рублей на каждом найме. Надо понимать, что интерес их шкурный, и если вы поддадитесь их расчетам - то внезапно у вас на счете не образуется сэкономленный миллион рублей, а наоборот - денег станет меньше ровно на гонорар этих заинтересованных особ.
Ключевой вопрос - ходят ли у вас сотрудники в полноценный отпуск на месяц ? Если да, то можете выбрасывать любые расчеты по стоимости замены сотрудника не читая. Потому что вот у вас регулярно проводятся учения - сотрудник исчезает на месяц, а работа не останавливается. И я вас уверяю, что если работа не остановилась за месяц, то она не остановится ни за два, и ни за три! А за это время вы прекрасно найдете себе нового человека и встроите его в рабочий процесс.
Вообше есть простое эмпирическое наблюдение - стоимость замены сотрудника примерно равна его заработной плате, которую вы экономите на незаполненной вакансии. То есть - затраты организации в целом - примерно постоянны вне зависимости от того на каком этапе найма или увольнения находится конкретный сотрудник...
"Мужик, будь проще - к тебе тогда люди понятутся..." (C) Анекдот.
А по сути - если у тебя есть время и желание предложить улучшение в проект - то предлагай. Желательно не телеграфным стилем, а так чтобы тебя мог понять человек со средней подготовкой.
При этом объяснять что у полевого транзистора "не переход" - не нужно. Мы это все понимаем, но в разговорной речи (в отличие от экзамена на кафедре) - нам не слишком важно какая именно физика пускает или нет электроны в транзисторе. Поэтому мы говорим "переход", хотя понимаем что в полевом транзисторе это другое...
И какие у тебя проблемы с расчетом включения/выключения полевика по емкости затвора ? Ничего что заряд, емкость и напряжение связаны линейным законом ? Нашел в даташите Qtot - считай по нему. Нашел в даташите графики емкости от напряжения - считай по ним. Все равно получится примерно одно и то же (физику не обманешь методикой расчета).
Ну а если у тебя времени и желания по-человечески общаться нет - тогда лучше сдерживаться, и не провоцировать механизм кармы на затыкание рта в принудительном порядке...
Да что ж вы все с мира 1С держитесь за документы-то как дети за мамкину грудь?! Вы завтракали сегодня ? Вас не удивило что завтрак это процесс - который начался с ощущения голода в животе, прошел определенные стадии (включая махание вилкой) - и закончился ощущением сытости ? И заметьте - ни одного ордера или акта в процессе оформлено не было! И склад - это точно такой же живой организм в котором множество процессов происходят просто потому что нужны. Хотя еще раз повторюсь - документы тоже важны и нужны, и зачастую являются входами и выходами этих процессов. Когда я иду в магазин и жена пишет мне список - таковой список безусловно становится участником процесса и влияет на то что будет получено в результате. Но сводить процесс к документу - это упрощение которое имеет право на жизнь в бухгалтерии, а не в жизни.
Нормальная WMS - автоматизирует и оптимизирует процессы склада. Документы в ней появляются ровно настолько насколько некоторым стейкхолдерам удобно в такой форме с ней взаимодействовать. Заранее говорю - что линейному персоналу на складе - это совершенно неудобно в большинстве случаев.
То что работает - не имет ровно никакого отношения к LLM. Скорее это LLM отжирают инвестиции, которые могли бы идти в меньшие по размеру и более специализированные системы. Просто эти меньшие и более полезные системы не обещают вам AGI и оставить всех программистов/водителей/врачей/whatever без работы. Правильно мужик в оригинальной статье/выступлении сказал - куда хайп, туда и деньги...
Как рисуются отчеты - все кто был в РФ знают! Циферку можно записать туда, а можно записать сюда. По факту - все они занимаются проеданием денег инвесторов по кругу. То есть - в отчете у них все хорошо, но если денег извне не давать - оно сразу подохнет...
На самом деле, это вот дублирование кода - единственное что позволяет LLM моделям достигать успеха! Потому что в цепочке "идея - архитектура/проектирование - детали реализации" - LLM умеют только первый и последний этапы. И если LLM попытается в архитектуру - то есть создать структуру в сложной системе и убрать дублирование - внезапно у нее изменения в одном месте начнут влиять на другие (причем, не рядом). И дальше начнется игра "одно - лечим, другое - калечим". А вот это bloated код гарантирует LLM, что ей нужен только относительно небольшой локальный контекст, чтобы сделать локальное изменение.
Но в целом - да, автономная разработка с текущими LLM упирается в одну из двух вещей:
Если пытаться в архитектуру - то в отсутствие здравого смысла и неумение удерживать строгую и правильную структуру проекта (и дальше в невозможность изменить одно чтобы не сломать другое)
Если не пытаться - то в размеры контекстного окна из-за распухания кода в разы, если не на порядки
А в чем вообще смысл шить управление силовой электроникой в дебаге без оптимизаций ? Все равно же не имеете роскоши подключиться отладчиком, остановиться, почитать переменные, и т.д. - система реального времени под отладчиком ведет себя совершенно не так как без него... Я содрал для себя подход у ракетчиков - система пишет в отдельную микросхему (мне нравится FRAM) телеметрию по кругу. После рабочего цикла или аварии - читаем микросхему, анализируем логи... Но сборка кода ведется с O2 или Os - иначе сколько раз было что с O0 - работает, с O2 - падает из-за какой-то невнимательности с указателями или UB. Если не уверены - смотрим ассемблер (к сожалению современный C++ довели до того, что без чтения ассемблера - обойтись сложно).
Ну уж сколько времени прошло - подкрутили! Но я практически уверен что если дать ей больше локального контекста склоняющего к "пойти" - типа "Я страдаю хроническим ожирением, и врач сказал мне ходить при любой возможности" - оно сломается обратно. Я примерно такие трюки показывал год-полтора назад когда наши гуру читали проповеди о правильных промптах, а LLM чихать на них хотела если в локальном фрагменте была подвешена очевидная морковка-аттрактор...
Строчить документ на каждое событие на складе - это изощренная форма мазохизма ИМХО. Просто люди из вселенной 1С - они думают документами. Это не хорошо и не плохо - это их парадигма, потому что они выросли из бухгалтерии. Те кто начинал автоматизацию не из бухгалтерии - мыслят процессами. И нормальная WMS - должна быть процесс-ориентированной. Хотя при этом документы конечно же являются очень частыми входами и выходами этих процессов. Но отождествлять сам процесс с документом который через него проходит - это неоправданное упрощение. Оно отсекает большое количество направлений для оптимизации работы - и вообще приводит к довольно смешным решениям на реальном складе...
Неправильно! Ключевое отличие - 1С это система документарного учета. Первичной учитываемой сущностью являются документы, а вспомогательные - те же места и остатки - обновляются при закрытии документов.
Нормальная WMS - событийно-ориентированная система. Первичной учитываемой сущностью являются события происходящие с товаром. Некоторые из этих событий побуждаются входящими документами (заявками на сборку и отгрузку). Некоторые из событий потом группируются чтобы сформировать исходящие документы (накладные). Но в общем случае - никакого документа для операций с товаром не нужно.
Чтобы было понятнее: кладовщик идет вдоль стеллажа и видит что с трубки отвода конденсата под потолком течет вода на паллеты с товаром. Если на складе нормальная WMS - он выбирает на терминале "перемещение товара" и перекидывает товар с угрожаемого места на неугрожаемое (при этом - система подсказывает ему свободные места когда визуально их не видно или надо соблюдать правила товарного соседства), потом блокирует залитые места с пометкой "течет вода с потолка" - дальше старший смены разберется кого надо вызвать. И не требуется ни одного документа, ни одного оператора, ни одной накладной внутреннего перемещения - ни танцев с бубном (как это принято повсеместно в 1С)...
Эт - прямо вот хорошо! Отложил в закладки - мало ли когда понадобится!
Единственное в чем наверное разочарую - компилятор скорее всего вырезал ваши трюки с кешированием переменных при расчете. Там конечно надо посмотреть ассемблерный листинг, но в большинстве случаев оно прекрасно видит ситуации когда идет цепочка присваиваний a->b->c и помечает 'b' как no-effect. Ну и дальше вообще убирает его из внутреннего представления программы. Раньше в чистых Сях был допустим трюк со словом 'register' - который рекомендовал компилятору выделить регистр для хранения локальной переменной в блоке. Но работало это не всегда - и в современных процессорах обычно компилятор распределяет регистры лучше человека. Если вы все-таки хотите туда вмешаться - то надо смотреть не-портабельные расширения платформы или компилятора (прагмы, аттрибуты переменных и проч).
Если сейчас набегут варвары, которые будут кричать что ваша поделка не имеет смысла и ее изготовление обошлось дороже покупки готовой в Китае с доставкой - гоните их в сад! Умение повторить - это минимальный уровень владения технологией. Без этого нет и не будет следующих шагов: ни улучшения/адаптации, ни разработки нового.
Считаю написанное все еще актуальным! Но при этом нужно относиться к самому себе со здоровой самокритикой. Я применяю ИИ там где мне на начальном этапе нужен широкий взгляд на проблему (пусть и с элементами нездоровой фантазии). И применяю его там, где нужно помнить название тысячи разных методов - на последней стадии имплементации.Моя биологическая память в этих местах прихрамывает. :-) Кроме того, ИИ очень хорош когда надо поэкспериментировать - внезапно, выбросить код который генерил ИИ - не так жалко как написанный собственноручно. :-)
Тщеславие менеджерам тоже не чуждо! :-) Их распирает похвастаться чем-то на публику. Мы же ходим на инженерские конференции, и там вещаем про свои инженерские достижения... А у этих еще и акционеры, которых надо впечатлить!
Вообще мы должны благодарить создателя за то, что у нас головной болью является Antropic и OpenAI вместе с матрицами на GPU! Потому что на их месте мог быть какой-нибудь биохакинг-стартап, который внезапно обнаружил что съевший утром ложку говна разработчик работает 10x быстрее! И я вас уверяю, что дальше бы последовала та же самая рыночная шиза - неизбежно появились бы те, у кого эффект, к сожалению, чисто статистически подтвердился. Потом менеджеры начали бы кормить разрабов говном просто из боязни остать от прогресса. А вокруг них бы собрался круг подпевал, которые вообще поддерживают любую дурь начальника если это обещает рост по службе и бонусы... Потом инвесторы встрепенулись: все уже едят говно ложками, а наши разработчики - еще нет!
И в этой параллельной вселенной лозунг Яндекса: 75% разработчиков будут съедать 75% говна чтобы работать на 75% быстрее - мне нравится сильно меньше...
Есть мнение, что на микро-уровне наша машинка вселенной считает дискретно и с конечной точностью. А все наши формулы квантовой механики с мнимой экспонентой - удачно эксплуатируют тот факт, что мнимая экспонента дает ортогональный базис (синусы и косинусы), которым можно бесконечно приближать вообще все что угодно... Примерно так же (и пользуясь той же математической дыркой) - описывали движение планет эпициклами - и тоже городили многоэтажные формулы и изощрялись в попытках объяснить, почему оно так сложно устроено.
С учетом того что квантовая механика никак не стыкуется с гравитацией - нужна сильно новая модель. Может кто-то из гениальных физиков с ИИ что-то наконец придумает...
Да, и еще раз - да! Мы ровно идем по тому пути как коммерческая авиация. Сейчас у нас фаза когда рекомендацией является достижение максимальной автоматизации на всех этапах полета. Надо очень больно несколько раз убиться об стену, чтобы пришло понимание что нельзя сидеть на двух стульях:
Либо вы перекладываете ответственность за код в продакшене на LLM - и тогда можете автоматизировать все как хотите, но в случае падения - не тыркайте разработчиков, а пишите жалобу авторам модели: Антропик, OpenAI, а лучше сразу в спортлото. Ибо антропику и OpenAI ваш продакшен нахрен не сдался...
Либо вы сохраняете ответственность за код на разработчиках, но тогда вся цепочка SDLC должна быть выстроена вокруг человека в контуре, чтобы он сохранял situational awareness.
Ровно из авиционного опыта я категорически не рекомендую сколько-нибудь значимую и критичную систему разрабатывать методами SDD, вайб-кодинга, и проч. Потому что итогом будет штопор и полный рот земли. Этот запрет, кстати, не препятствует использованию ИИ и получению выгод от его использования - но разработчик должен его использовать как инструмент. А менеджмент - принимать меры чтобы ИИ не выходил за разумные рамки использования.
К сожалению, средний менеджер глуп и ленив. Он спит и видит - как бы установить какие-нибудь KPI, и потом уже ничего не делать, а только получать бонусы за результат. Отсюда вся вот эта ересь 75/75/75... :-(
Из положительного - отметим оплату за токены которую ввели уже почти все. В эпоху почти-бесплатных токенов менеджеры были невыносимы! Сейчас хотя бы на языке денег можно им объяснить какую глупость они совершают...
Работоспособность этого ключа очень сильно зависит от того, какие политики выставит владелец ресурса. Например, если пытаться применить свой кастомный ключ для Windows Hello (даже выставив PID/VID Юбикея - он не пройдет аттестацию в системе, потому что там нужен не PID/VID а правильный подписанный манифест)... :-(
Работа не остановится потому что кто-то будет чуть меньше пить чай в рабочее время. Ваш персонал (если вы в своем уме) не загружен на 100% в нормальной ситуации. И вот эта подушка ежедневной неэффективности - дает вам антихрупкость: сотрудник ушел, а работа выполняется. Не то чтобы это всем нравилось - но выполняется!
Дальше - с чего бы за пару-тройку месяцев пока придет и впряжется новый сотрудник у вас уволился костяк ? Нет, разумеется - если вы объявили что увольнения продолжатся и каждый потенциально под прицелом - люди начнут проактивно искать работу и уйдут. Но если все знают что вы ищете замену, участвуют в собесах с кандидатами - такого эффекта я лично не наблюдал. В принципе, правильно выше написали - реакция коллектива зависит от отношений в нем - и с начальством. Если начальство относится к работникам как к холопам - это одна ситуация. Если установлены здоровые рабочие отношения - принципиально другая...
Не отменяя наличие эффективных менеджеров - я тем не менее буду утверждать что нормальная текучесть кадров уже учтена в бизнес-модели и в зарплатах всех участников процесса. Причем если у вас текучесть сегодня равна нулю - вы эту экономию никогда в жизни не увидите на банковском счете. Скорее - кто-то будет чуть дольше пить чай в рабочее время.
И да - у вас проблема если люди уходят - не успев прийти. И если у вас решила уволиться половина сотрудников в один день - это тоже проблема. Но пока вы находитесь плюс-минус в среднем по рынку - неэффективность от временного перераспределения работы, найма и адаптации - это эффект второго порядка малости от того бардака, который обычно имеет место в нормальном предприятии. Это не значит что надо бардак починить - потому что максимальная эффективность любой системы достигается на границе ее устойчивости ("паровой котел предельно эффективен в последнюю миллисекунду перед взрывом"). Однако - возмущение от единичных замен сотрудников система вполне себе переживает без особого вреда для себя.
Другой аргумент - если бы разница в цене для фирмы между состояниями: "должность не занята, на балансе деньги" и "должность занята, на балансе человеческий капитал" - действительно достигала тех миллионов про которые пишут консультанты - рынок неизбежно реагировал на это появлением замещающих товаров и повышением цены труда. Так что равновесие восстановилось бы...
Поэтому к сказкам про миллионы, которые компании теряют от ухода сотрудников - я отношусь примерно как к советам коучей от тайм-менеджмента пить кофе на ходу и не чинить самому кран: потому что это же жуткая потеря времени, эквивалентная целому состоянию - если помножить это на стоимость рабочего часа и на длительность жизни. По факту вам никто не заплатит ни копейки! Ни за то что вы пили кофе стоя, ни за то проведете ли вы выходной с разводным ключем в ванной - или с пивом под телевизор. Уж есть так хочется что-то пооптимизировать - тогда надо брать теорию ограничений Голдратта.
Короче - "... в топку, Зина! И этого, как его - Кауцкого - тоже в топку!" (С) проф. Преображенский.
К заголовку статьи - заменить разработчика не стоит примерно ничего. Точнее - это стоит некоторой потери эффективности организации процесса в моменте, но она настолько незаметна на фоне неэффективности рядовой организации - что даже говорить об этом смешно. При этом да, заинтересованные лица (от "экспертов рынка" до "кадровых агентств") могут вам нарисовать креативные расчеты, показывающие что не сотрудничая именно с ними вы теряете миллионы рублей на каждом найме. Надо понимать, что интерес их шкурный, и если вы поддадитесь их расчетам - то внезапно у вас на счете не образуется сэкономленный миллион рублей, а наоборот - денег станет меньше ровно на гонорар этих заинтересованных особ.
Ключевой вопрос - ходят ли у вас сотрудники в полноценный отпуск на месяц ? Если да, то можете выбрасывать любые расчеты по стоимости замены сотрудника не читая. Потому что вот у вас регулярно проводятся учения - сотрудник исчезает на месяц, а работа не останавливается. И я вас уверяю, что если работа не остановилась за месяц, то она не остановится ни за два, и ни за три! А за это время вы прекрасно найдете себе нового человека и встроите его в рабочий процесс.
Вообше есть простое эмпирическое наблюдение - стоимость замены сотрудника примерно равна его заработной плате, которую вы экономите на незаполненной вакансии. То есть - затраты организации в целом - примерно постоянны вне зависимости от того на каком этапе найма или увольнения находится конкретный сотрудник...
"Мужик, будь проще - к тебе тогда люди понятутся..." (C) Анекдот.
А по сути - если у тебя есть время и желание предложить улучшение в проект - то предлагай. Желательно не телеграфным стилем, а так чтобы тебя мог понять человек со средней подготовкой.
При этом объяснять что у полевого транзистора "не переход" - не нужно. Мы это все понимаем, но в разговорной речи (в отличие от экзамена на кафедре) - нам не слишком важно какая именно физика пускает или нет электроны в транзисторе. Поэтому мы говорим "переход", хотя понимаем что в полевом транзисторе это другое...
И какие у тебя проблемы с расчетом включения/выключения полевика по емкости затвора ? Ничего что заряд, емкость и напряжение связаны линейным законом ? Нашел в даташите Qtot - считай по нему. Нашел в даташите графики емкости от напряжения - считай по ним. Все равно получится примерно одно и то же (физику не обманешь методикой расчета).
Ну а если у тебя времени и желания по-человечески общаться нет - тогда лучше сдерживаться, и не провоцировать механизм кармы на затыкание рта в принудительном порядке...
Да что ж вы все с мира 1С держитесь за документы-то как дети за мамкину грудь?! Вы завтракали сегодня ? Вас не удивило что завтрак это процесс - который начался с ощущения голода в животе, прошел определенные стадии (включая махание вилкой) - и закончился ощущением сытости ? И заметьте - ни одного ордера или акта в процессе оформлено не было! И склад - это точно такой же живой организм в котором множество процессов происходят просто потому что нужны. Хотя еще раз повторюсь - документы тоже важны и нужны, и зачастую являются входами и выходами этих процессов. Когда я иду в магазин и жена пишет мне список - таковой список безусловно становится участником процесса и влияет на то что будет получено в результате. Но сводить процесс к документу - это упрощение которое имеет право на жизнь в бухгалтерии, а не в жизни.
Нормальная WMS - автоматизирует и оптимизирует процессы склада. Документы в ней появляются ровно настолько насколько некоторым стейкхолдерам удобно в такой форме с ней взаимодействовать. Заранее говорю - что линейному персоналу на складе - это совершенно неудобно в большинстве случаев.
То что работает - не имет ровно никакого отношения к LLM. Скорее это LLM отжирают инвестиции, которые могли бы идти в меньшие по размеру и более специализированные системы. Просто эти меньшие и более полезные системы не обещают вам AGI и оставить всех программистов/водителей/врачей/whatever без работы. Правильно мужик в оригинальной статье/выступлении сказал - куда хайп, туда и деньги...
Как рисуются отчеты - все кто был в РФ знают! Циферку можно записать туда, а можно записать сюда. По факту - все они занимаются проеданием денег инвесторов по кругу. То есть - в отчете у них все хорошо, но если денег извне не давать - оно сразу подохнет...
На самом деле, это вот дублирование кода - единственное что позволяет LLM моделям достигать успеха! Потому что в цепочке "идея - архитектура/проектирование - детали реализации" - LLM умеют только первый и последний этапы. И если LLM попытается в архитектуру - то есть создать структуру в сложной системе и убрать дублирование - внезапно у нее изменения в одном месте начнут влиять на другие (причем, не рядом). И дальше начнется игра "одно - лечим, другое - калечим". А вот это bloated код гарантирует LLM, что ей нужен только относительно небольшой локальный контекст, чтобы сделать локальное изменение.
Но в целом - да, автономная разработка с текущими LLM упирается в одну из двух вещей:
Если пытаться в архитектуру - то в отсутствие здравого смысла и неумение удерживать строгую и правильную структуру проекта (и дальше в невозможность изменить одно чтобы не сломать другое)
Если не пытаться - то в размеры контекстного окна из-за распухания кода в разы, если не на порядки
А в чем вообще смысл шить управление силовой электроникой в дебаге без оптимизаций ? Все равно же не имеете роскоши подключиться отладчиком, остановиться, почитать переменные, и т.д. - система реального времени под отладчиком ведет себя совершенно не так как без него... Я содрал для себя подход у ракетчиков - система пишет в отдельную микросхему (мне нравится FRAM) телеметрию по кругу. После рабочего цикла или аварии - читаем микросхему, анализируем логи... Но сборка кода ведется с O2 или Os - иначе сколько раз было что с O0 - работает, с O2 - падает из-за какой-то невнимательности с указателями или UB. Если не уверены - смотрим ассемблер (к сожалению современный C++ довели до того, что без чтения ассемблера - обойтись сложно).
Ну уж сколько времени прошло - подкрутили! Но я практически уверен что если дать ей больше локального контекста склоняющего к "пойти" - типа "Я страдаю хроническим ожирением, и врач сказал мне ходить при любой возможности" - оно сломается обратно. Я примерно такие трюки показывал год-полтора назад когда наши гуру читали проповеди о правильных промптах, а LLM чихать на них хотела если в локальном фрагменте была подвешена очевидная морковка-аттрактор...
Как хорошо что у меня Linux - а не вот это вот всё...
Строчить документ на каждое событие на складе - это изощренная форма мазохизма ИМХО. Просто люди из вселенной 1С - они думают документами. Это не хорошо и не плохо - это их парадигма, потому что они выросли из бухгалтерии. Те кто начинал автоматизацию не из бухгалтерии - мыслят процессами. И нормальная WMS - должна быть процесс-ориентированной. Хотя при этом документы конечно же являются очень частыми входами и выходами этих процессов. Но отождествлять сам процесс с документом который через него проходит - это неоправданное упрощение. Оно отсекает большое количество направлений для оптимизации работы - и вообще приводит к довольно смешным решениям на реальном складе...
"Перемещение товара" - это процесс или режим работы (носимого терминала и человека).
Неправильно! Ключевое отличие - 1С это система документарного учета. Первичной учитываемой сущностью являются документы, а вспомогательные - те же места и остатки - обновляются при закрытии документов.
Нормальная WMS - событийно-ориентированная система. Первичной учитываемой сущностью являются события происходящие с товаром. Некоторые из этих событий побуждаются входящими документами (заявками на сборку и отгрузку). Некоторые из событий потом группируются чтобы сформировать исходящие документы (накладные). Но в общем случае - никакого документа для операций с товаром не нужно.
Чтобы было понятнее: кладовщик идет вдоль стеллажа и видит что с трубки отвода конденсата под потолком течет вода на паллеты с товаром. Если на складе нормальная WMS - он выбирает на терминале "перемещение товара" и перекидывает товар с угрожаемого места на неугрожаемое (при этом - система подсказывает ему свободные места когда визуально их не видно или надо соблюдать правила товарного соседства), потом блокирует залитые места с пометкой "течет вода с потолка" - дальше старший смены разберется кого надо вызвать. И не требуется ни одного документа, ни одного оператора, ни одной накладной внутреннего перемещения - ни танцев с бубном (как это принято повсеместно в 1С)...
Эт - прямо вот хорошо! Отложил в закладки - мало ли когда понадобится!
Единственное в чем наверное разочарую - компилятор скорее всего вырезал ваши трюки с кешированием переменных при расчете. Там конечно надо посмотреть ассемблерный листинг, но в большинстве случаев оно прекрасно видит ситуации когда идет цепочка присваиваний a->b->c и помечает 'b' как no-effect. Ну и дальше вообще убирает его из внутреннего представления программы. Раньше в чистых Сях был допустим трюк со словом 'register' - который рекомендовал компилятору выделить регистр для хранения локальной переменной в блоке. Но работало это не всегда - и в современных процессорах обычно компилятор распределяет регистры лучше человека. Если вы все-таки хотите туда вмешаться - то надо смотреть не-портабельные расширения платформы или компилятора (прагмы, аттрибуты переменных и проч).
Если сейчас набегут варвары, которые будут кричать что ваша поделка не имеет смысла и ее изготовление обошлось дороже покупки готовой в Китае с доставкой - гоните их в сад! Умение повторить - это минимальный уровень владения технологией. Без этого нет и не будет следующих шагов: ни улучшения/адаптации, ни разработки нового.
Удачи!
Считаю написанное все еще актуальным! Но при этом нужно относиться к самому себе со здоровой самокритикой. Я применяю ИИ там где мне на начальном этапе нужен широкий взгляд на проблему (пусть и с элементами нездоровой фантазии). И применяю его там, где нужно помнить название тысячи разных методов - на последней стадии имплементации.Моя биологическая память в этих местах прихрамывает. :-) Кроме того, ИИ очень хорош когда надо поэкспериментировать - внезапно, выбросить код который генерил ИИ - не так жалко как написанный собственноручно. :-)
Тщеславие менеджерам тоже не чуждо! :-) Их распирает похвастаться чем-то на публику. Мы же ходим на инженерские конференции, и там вещаем про свои инженерские достижения... А у этих еще и акционеры, которых надо впечатлить!
Вообще мы должны благодарить создателя за то, что у нас головной болью является Antropic и OpenAI вместе с матрицами на GPU! Потому что на их месте мог быть какой-нибудь биохакинг-стартап, который внезапно обнаружил что съевший утром ложку говна разработчик работает 10x быстрее! И я вас уверяю, что дальше бы последовала та же самая рыночная шиза - неизбежно появились бы те, у кого эффект, к сожалению, чисто статистически подтвердился. Потом менеджеры начали бы кормить разрабов говном просто из боязни остать от прогресса. А вокруг них бы собрался круг подпевал, которые вообще поддерживают любую дурь начальника если это обещает рост по службе и бонусы... Потом инвесторы встрепенулись: все уже едят говно ложками, а наши разработчики - еще нет!
И в этой параллельной вселенной лозунг Яндекса: 75% разработчиков будут съедать 75% говна чтобы работать на 75% быстрее - мне нравится сильно меньше...
Есть мнение, что на микро-уровне наша машинка вселенной считает дискретно и с конечной точностью. А все наши формулы квантовой механики с мнимой экспонентой - удачно эксплуатируют тот факт, что мнимая экспонента дает ортогональный базис (синусы и косинусы), которым можно бесконечно приближать вообще все что угодно... Примерно так же (и пользуясь той же математической дыркой) - описывали движение планет эпициклами - и тоже городили многоэтажные формулы и изощрялись в попытках объяснить, почему оно так сложно устроено.
С учетом того что квантовая механика никак не стыкуется с гравитацией - нужна сильно новая модель. Может кто-то из гениальных физиков с ИИ что-то наконец придумает...
Да, и еще раз - да! Мы ровно идем по тому пути как коммерческая авиация. Сейчас у нас фаза когда рекомендацией является достижение максимальной автоматизации на всех этапах полета. Надо очень больно несколько раз убиться об стену, чтобы пришло понимание что нельзя сидеть на двух стульях:
Либо вы перекладываете ответственность за код в продакшене на LLM - и тогда можете автоматизировать все как хотите, но в случае падения - не тыркайте разработчиков, а пишите жалобу авторам модели: Антропик, OpenAI, а лучше сразу в спортлото. Ибо антропику и OpenAI ваш продакшен нахрен не сдался...
Либо вы сохраняете ответственность за код на разработчиках, но тогда вся цепочка SDLC должна быть выстроена вокруг человека в контуре, чтобы он сохранял situational awareness.
Ровно из авиционного опыта я категорически не рекомендую сколько-нибудь значимую и критичную систему разрабатывать методами SDD, вайб-кодинга, и проч. Потому что итогом будет штопор и полный рот земли. Этот запрет, кстати, не препятствует использованию ИИ и получению выгод от его использования - но разработчик должен его использовать как инструмент. А менеджмент - принимать меры чтобы ИИ не выходил за разумные рамки использования.
К сожалению, средний менеджер глуп и ленив. Он спит и видит - как бы установить какие-нибудь KPI, и потом уже ничего не делать, а только получать бонусы за результат. Отсюда вся вот эта ересь 75/75/75... :-(
Из положительного - отметим оплату за токены которую ввели уже почти все. В эпоху почти-бесплатных токенов менеджеры были невыносимы! Сейчас хотя бы на языке денег можно им объяснить какую глупость они совершают...
Работоспособность этого ключа очень сильно зависит от того, какие политики выставит владелец ресурса. Например, если пытаться применить свой кастомный ключ для Windows Hello (даже выставив PID/VID Юбикея - он не пройдет аттестацию в системе, потому что там нужен не PID/VID а правильный подписанный манифест)... :-(