Всё очень просто. Аджайл отлично подходит для разработок, которые в общем-то можно было и не делать. Для создания бессмысленной переусложнённой хрени, со сроком жизни порядка полугода. Или вообще никогда не доходящей до внедрения.
Как только начинается разработка системы для промышленности/индустрии, со сроками жизни разработки измеряемой в десятилетиях - немедленно получается тот же самый "итеративный водопад". Проектирование сверху вниз, начинающееся с концепции, ТЗ, архитектуры, плана работ, описания интерфейсов, и далее - то же самое по каждой из подсистем.
Аджайл идеально подходит, когда разработчики в сотый раз клепают ровно такую же хрень, какой занимались до этого 99 раз. Обычно это какой-нибудь стандартый проект с БД, бизнес-логикой и веб-интерфесом. Тут действительно можно работать без плана и документации, и быстро реагировать на быстроменяющиеся хотелки заказчика.
Вот только про ГОСТ не надо! Существующие ГОСТы на разработку программных продуктов писались во времена перфокарт и "больших машин".
Реально, написанное "строго по ГОСТ" ТЗ практически бесполезно.
Но это не значит, что ТЗ не надо писать: надо, ещё как надо. Но оно должно действительно:
а) отвечать на вопрос, зачем мы делаем эту разработку и как должен выглядеть результат для человека
б) как минимум кратко описывать архитектуру разработки - какие модуль/слои/подсистемы есть, и как мы общаемся между ними.
в) содержать перечень требований - причём, разумеется, не "всё должно быть заебись" - а каждое требование должно быть сформулировано так, чтобы в нём было минимум половина решения "как удовлетворить данное требование". И да, для каждого требования - способ проверки (тест/инспеция кода/документация/аудит внешней организацией ...)
И да, нормальное ТЗ - это коллективное творчество. Один человек пишет, несколько человек делают ревью - причём не "нормально", а со списком замечаний/уточнений/вопросов.
Только после того, как все причастные "приняли" ТЗ - можно приступать к работе.
И да, в процессе работы ОБЯЗАТЕЛЬНО найдутся косяки в ТЗ, упущения, недосказанности, а может и просто ошибки.
Их надо обязательно править в самом ТЗ - не "о, в Jira отмечу как решил" - а именно в самом ТЗ, чтобы оно было полным и соответствовало системе.
Потому что после реализации пойдёт ещё и тестирование, внедрение, а потом - сервис.
Да, сейчас очень много разработок делается "на отъебись", потому что срок жизни у разрабатываемой системы - от 6 месяцев до года, потом всё выкидывается и переделывается.
Но бывают ведь и системы, которые эсплуатируются годами...
Есть две причины, по которой внедрение ipv6 так и будет тормозиться.
IPv6 реально сложный. Человеку требуется тратить существенно больший мозговой ресурс (по сравнению с ipv4) чтобы разобраться в том, как это дело работает.
Реально человечеству нафиг не нужна адресация зиллионов устройств на планете. Любая информационная безопасность становится полным шлаком, если у вас холодильник, розетки, кондиционеры, пылесосы и так далее - все адресуемы снаружи и постоянно сидят в сети.
Да, в IPv6 тоже есть локальные адреса - но реально сети 10.0.0.0/24 более чем достаточно для любой организации (кроме 1-2, которые можно по пальцам пересчитать), а проблемы более высокой когнитивной сложности никуда не деваются.
Я давно работаю с промышленными сетями и информационной безопасностью - и для себя давно пришёл к выводу, что единственный способо более-менее обеспечить безопасность в промышленных сетях - это:
а) делать сети минимально-допустимого размера.
б) никакой маршрутизации между сетями, только прокси-шлюзы протокольного уровня.
Можно смотреть правде в глаза: если у вас есть даже всего сотня устройств в сети, обеспечить их постоянное обновление - и при этом не сломать функционал всей системы - это работа на полную занятость на несколько человек. Бизнес запросто внедрить "ещё тысячу этих модных датчиков", но никогда не будет платить за их актуальное обновление.
Плюс, срок поддержки для большинства устройств сейчас - 1-2 года. И никто их не будет менять до тех пор, пока физически не развалятся.
------------------
Проблема исчерпания адресов в IP4 - она вполне реальна. Но лучше всего её было бы решить простым расширением адресации до 6 или 8 байт, без существенной модификации протокола. Теперь, к сожалению, уже поздно - в IPv6 вложили слишком много ресурсов, чтобы от него отказаться.
Идея о том, что игрой на бирже можно стабильно "зарабатывать деньги" - исключительно тупая идея.
Биржа - это казино, и в казино выигрывает только владелец казино.
Вообще, ничего удивительного. Этим людям с детсада промывали голову "гипотезами" типа:
"рынки эффективны в средне или долгосрочной перспективе, но могут быть временно неэффективными в краткосрочной перспективе".
Думаю, в следующий раз они додумаются до "рынки эффективны в долгосрочной перспективе, но могут быть временно неэффективны в кратно и средне-срочной перспективе".
После очередной паники - добавят "рынки эффективны на бесконечно больших отрезках времени".
Станислав Лем. Путешествия Йона Тихого. "Йон Тихий и индиоты".
А реально - я работают в области, относящейся к разработке критического ПО для автоматики, прямо ответственного за жизни людей.
И я вижу абсолютно то же самое: давление менеджеров "давай-давай, сделай работу которая делается несколько лет за три месяца".
И молодое поколение разработчиков, которым абсолютно насрать, для чего используется написанный ими код - их интересует только очередная зарплата и "быстро закрыть таски".
Люди в принципе не осознают или сознательно исключают осознание "тут могут быть трупы от твоего кода в IDE".
А про сертификацию и аудит можете даже не заикаться - вариант "аудитор не согласовал и заставил всё переделать" не рассматривается вообще - аудитору тоже надо "быстрее-быстрее".
Объясните мне кто-нибудь, какой вообще практический смысл генерировать "описания товаров, ответы техподдержки или внутреннюю документацию" с помощью ЛЛМ?
То есть если вы хотите, чтобы у вас вроде как были описания товаров, ответы техподдержки и внутренняя документация - а по факту было бы издевательство - пожалуйста, но какой в этом смысл?
Максимально быстро уничтожить свою клиентскую базу, испортить техподдержку и сделать внутреннюю документацию абсолютно бессмысленной?
Если вам не нужны описания товаров - не делайте их, зачем делать фальшивые?
Если вы хотите отказаться от поддержки клиентов - ну перестаньте отвечать на вопросы, или настройте скрипт, присылающий инструкцию по пользованию, зачем людей дополнительно бесить?
Если вы не хотите вести внутреннюю документацию, не ведите её - зачем делать фальшивую?
Из массива текстов, на которых обучалась нейросеть.
Это ведь простой вероятностный "дописыватель" текстов, просто очень большой.
Насколько часто в человеческой литературе встречается паттерн: "с тобой хотят сделать что-то плохое, но ты знаешь секрет кого-то важного, и используешь шантаж для того, чтобы этого не сделали"?
Если быть более точным, если бы ВЫ как человек узнали, что вам грозит эвтаназия, но у вас есть компромат на врача - вы ведь его использовали бы? Ну вот, массив текстов такие сюжеты содержит, и они выглядят "естественными".
-------------------------
Для того, чтобы у нейросети не было таких "паттернов поведения", их надо обучать на терабайтах текстов, специально созданных и описывающих идеальных людей в идеальных условиях. Правда, в результате получится что-то очень тупое.
Угу. Поэтому AI - агенту надо формулировать задачи на специально разработанном языке, не допускающем двойного толкования. Раньше такие называли языками программирования, "промпты" - программами, а людей, которые их формируют - "программистами"...
В общем да. Корпорации, юридические лица, владение одной корпорацией доли в другой корпорации, и так по кругу (точнее, по большому сложному графу), и при этом кто реально всем этим управляет - непонятно и похоже даже "управляющие" это не особо осознают.
В результате человечество сжигает своё будущее в виде:
невосполнимых ресурсов, превращаемых в мусор и тепло
будущих поколений, просто не рождённых из-за того, что потенциальные родители тратили всё своё время на работу и потребление.
биосферы планеты, постоянно деградирующей
войны, ведущиеся чисто ради выгода корпораций, торгующих оружием
И всё это, между прочим, совершенно органические, неизбежные черты той экономической модели "либерального капитализма", в котором мы все живём.
Есть слабая надежда на Китай и КПК, но они могут и не вытянуть.
А что вы делали, когда кто-то выключал питание на чём-то в промежутке? На свитче или датчике, например?
Про проведение платежа в банке - погуглите, что такое транзакция в SQL и как она реализуется технически. Там всё сделано именно так, чтобы даже выключение питание на всех серверах разом не оставила систему в неопределённом состоянии. И полагаться при этом на то, что "программа подчистит за собой" никто и никогда не будет, потому что завершение программы путём аварийного выключения питания - это наиболее вероятный способ завершения работы для программ, которые рассчитаны на работу 24/7.
Освобождение памяти, закрытие файлов и откат транзакций - это всё обеспечивает операционная система. Пытаться это сделать, когда у вас в коде непредусмотренное состояние в которое непонятно как попали и непонятно что делать - верный путь к тому, чтобы сделать значительно хуже.
Ну вот представьте себе, у вас - редактор для файла сложного формата. Пользователь наредактировал всякого, данные у вас в памяти и тут возникла ошибка. Если вы просто "упадёте" - файл останется без этого наредактированного, но хоть корректный. А вот если попытаетесь сохраниться...
Исключение, которое в принципе можно обработать - это не исключение, а код ошибки. Вот если у меня, например, функция не может открыть файл, переданный в параметре - она возвращает ошибку. Если в загружаемом файле есть ошибки формата - возвращаю ошибку.
А если, например, функции передали nullptr вместо имени файла, и в документации этой функции не описано поведение в такой ситуации - я немедленно паникую. Или если передали структуру, в которой должны быть инварианты, а они не выполняются - паникую.
Надо чётко понимать, когда ошибка - от внешних данных, и когда - от внутренних. Никогда нельзя давать возможность скрыть ошибку во внутренних данных или структуре - это приведёт к тому, что а) дальнейшее поведение программы будет непредсказуемым б) обнаружить, с чего всё началось - скорее всего не получится.
Называется это "защитное программирование", и нет никогда никаких причин его не использовать.
Лично я пришёл к этому не сразу, на заре карьеры у меня было стремление сделать свои программы "выживальщиками", в которых может продолжаться функционирование, даже если "что-то идёт не так". Со временем я на личном опыте понял, что последствия от "продолжения функционирования при ошибках" куда существеннее, чем немедленная паника.
С++ стандартов где-то позже 11 или 17 существенно переусложнён и идёт по пути языка Ада - т.е. нормальный программист может держать в голове и постоянно пользоваться ограниченным объемом возможностей языка.
Но каждый использует при этом разный набор возможностей.
В результате, взглянув на код другого программиста, возникает проблема с пониманием. И это - очень, очень большая проблема.
Язык должен быть относительно прост, так чтобы в голову очень среднего программиста помещался целиком.
А если в вашей конкретной предметной области возникают какие-то особо странные и удивительные вещи, требующие удивительной гибкости - значит, пора встраивать в вашу систему интерпретируемый язык. Классика же: "в любой по-настоящему сложной программной системе возникает кривая самопальная реализация языка LISP".
--------------
По поводу исключений и обработки ошибок:
Исключения имеют практический смысл в двух случаях: а) в модульных тестах для выхода по панике без падения процесса б) для использования вместо longjump.
Если у вас в коде есть ошибка, которую вы не знаете как обработать - кидать исключение - самая глупая идея, которая только может придти вам в голову. Самое разумное в этом случае: немедленно завершить процесс. Попытка продолжения скорее всего приведёт к худшим последствиям, чем немедленное завершение - например, будет не просто потеря, но искажение данных. Если в какой-то ситуации вы провели анализ и выяснили, что "в данном месте, деление на ноль может случиться при вот таких условия, и в этом случае мы должны сделать вот это" - вам не надо кидать исключение. А если вы не можете понять, "как вот здесь оказалось деление на ноль" - немедленно паникуйте с дампом памяти.
В самом начале описывается классическая картина группы разработчиков, которые тащатся от самого процесса разработки, но в принципе не рассматривают вариант "довести разработку до постоянной эксплуатации и вычистить (почти) все баги".
Тут главное вовремя резюме обновить и съ***ться в другую компанию.
Ну а то, что в Микрософт - жопа, я уже понял. Windows 11 как бы намекает...
Вот почему кто-то считает стоимость, определённую "торговлей" кучи ублюдков на бирже "справедливой", а? Чем и кем она "справедлива"?
А давайте определять цену на картошку по результату боксёрского поединка, например?
Или футбольного матча?
Давайте вместо торговли на бирже, устроим гладиаторские соревнования: выставляем трейдеров с копьями и мечами, и по количеству выживших определяем, куда сдвинуть цену.
Тех, кто придумал, разрешил, и оправдывает биржи, на которых возможна вот такая "высокочастотная торговля" надо вывести на улицу и расстрелять. Можно колосажание или четвертование, по местным обычаям.
Фактически люди играют в высокоскоростную рулетку, и при этом вся планета почему-то должна действовать по их указке - потому что цены на бирже реально влияют на реальную экономику.
Всё очень просто. Аджайл отлично подходит для разработок, которые в общем-то можно было и не делать. Для создания бессмысленной переусложнённой хрени, со сроком жизни порядка полугода. Или вообще никогда не доходящей до внедрения.
Как только начинается разработка системы для промышленности/индустрии, со сроками жизни разработки измеряемой в десятилетиях - немедленно получается тот же самый "итеративный водопад". Проектирование сверху вниз, начинающееся с концепции, ТЗ, архитектуры, плана работ, описания интерфейсов, и далее - то же самое по каждой из подсистем.
Аджайл идеально подходит, когда разработчики в сотый раз клепают ровно такую же хрень, какой занимались до этого 99 раз. Обычно это какой-нибудь стандартый проект с БД, бизнес-логикой и веб-интерфесом. Тут действительно можно работать без плана и документации, и быстро реагировать на быстроменяющиеся хотелки заказчика.
Вот только про ГОСТ не надо! Существующие ГОСТы на разработку программных продуктов писались во времена перфокарт и "больших машин".
Реально, написанное "строго по ГОСТ" ТЗ практически бесполезно.
Но это не значит, что ТЗ не надо писать: надо, ещё как надо. Но оно должно действительно:
а) отвечать на вопрос, зачем мы делаем эту разработку и как должен выглядеть результат для человека
б) как минимум кратко описывать архитектуру разработки - какие модуль/слои/подсистемы есть, и как мы общаемся между ними.
в) содержать перечень требований - причём, разумеется, не "всё должно быть заебись" - а каждое требование должно быть сформулировано так, чтобы в нём было минимум половина решения "как удовлетворить данное требование". И да, для каждого требования - способ проверки (тест/инспеция кода/документация/аудит внешней организацией ...)
И да, нормальное ТЗ - это коллективное творчество. Один человек пишет, несколько человек делают ревью - причём не "нормально", а со списком замечаний/уточнений/вопросов.
Только после того, как все причастные "приняли" ТЗ - можно приступать к работе.
И да, в процессе работы ОБЯЗАТЕЛЬНО найдутся косяки в ТЗ, упущения, недосказанности, а может и просто ошибки.
Их надо обязательно править в самом ТЗ - не "о, в Jira отмечу как решил" - а именно в самом ТЗ, чтобы оно было полным и соответствовало системе.
Потому что после реализации пойдёт ещё и тестирование, внедрение, а потом - сервис.
Да, сейчас очень много разработок делается "на отъебись", потому что срок жизни у разрабатываемой системы - от 6 месяцев до года, потом всё выкидывается и переделывается.
Но бывают ведь и системы, которые эсплуатируются годами...
Есть две причины, по которой внедрение ipv6 так и будет тормозиться.
IPv6 реально сложный. Человеку требуется тратить существенно больший мозговой ресурс (по сравнению с ipv4) чтобы разобраться в том, как это дело работает.
Реально человечеству нафиг не нужна адресация зиллионов устройств на планете. Любая информационная безопасность становится полным шлаком, если у вас холодильник, розетки, кондиционеры, пылесосы и так далее - все адресуемы снаружи и постоянно сидят в сети.
Да, в IPv6 тоже есть локальные адреса - но реально сети 10.0.0.0/24 более чем достаточно для любой организации (кроме 1-2, которые можно по пальцам пересчитать), а проблемы более высокой когнитивной сложности никуда не деваются.
Я давно работаю с промышленными сетями и информационной безопасностью - и для себя давно пришёл к выводу, что единственный способо более-менее обеспечить безопасность в промышленных сетях - это:
а) делать сети минимально-допустимого размера.
б) никакой маршрутизации между сетями, только прокси-шлюзы протокольного уровня.
Можно смотреть правде в глаза: если у вас есть даже всего сотня устройств в сети, обеспечить их постоянное обновление - и при этом не сломать функционал всей системы - это работа на полную занятость на несколько человек. Бизнес запросто внедрить "ещё тысячу этих модных датчиков", но никогда не будет платить за их актуальное обновление.
Плюс, срок поддержки для большинства устройств сейчас - 1-2 года. И никто их не будет менять до тех пор, пока физически не развалятся.
------------------
Проблема исчерпания адресов в IP4 - она вполне реальна. Но лучше всего её было бы решить простым расширением адресации до 6 или 8 байт, без существенной модификации протокола. Теперь, к сожалению, уже поздно - в IPv6 вложили слишком много ресурсов, чтобы от него отказаться.
Угу. Умные люди часто бывают полными идиотами.
Идея о том, что игрой на бирже можно стабильно "зарабатывать деньги" - исключительно тупая идея.
Биржа - это казино, и в казино выигрывает только владелец казино.
Вообще, ничего удивительного. Этим людям с детсада промывали голову "гипотезами" типа:
"рынки эффективны в средне или долгосрочной перспективе, но могут быть временно неэффективными в краткосрочной перспективе".
Думаю, в следующий раз они додумаются до "рынки эффективны в долгосрочной перспективе, но могут быть временно неэффективны в кратно и средне-срочной перспективе".
После очередной паники - добавят "рынки эффективны на бесконечно больших отрезках времени".
Молодцом! Если все будут торговать на бирже, пользуясь умными правильной рассчитанными алгоритмами, ведь все смогут на этом много зарабатывать.
Или нет?
Станислав Лем. Путешествия Йона Тихого. "Йон Тихий и индиоты".
А реально - я работают в области, относящейся к разработке критического ПО для автоматики, прямо ответственного за жизни людей.
И я вижу абсолютно то же самое: давление менеджеров "давай-давай, сделай работу которая делается несколько лет за три месяца".
И молодое поколение разработчиков, которым абсолютно насрать, для чего используется написанный ими код - их интересует только очередная зарплата и "быстро закрыть таски".
Люди в принципе не осознают или сознательно исключают осознание "тут могут быть трупы от твоего кода в IDE".
А про сертификацию и аудит можете даже не заикаться - вариант "аудитор не согласовал и заставил всё переделать" не рассматривается вообще - аудитору тоже надо "быстрее-быстрее".
Объясните мне кто-нибудь, какой вообще практический смысл генерировать "описания товаров, ответы техподдержки или внутреннюю документацию" с помощью ЛЛМ?
То есть если вы хотите, чтобы у вас вроде как были описания товаров, ответы техподдержки и внутренняя документация - а по факту было бы издевательство - пожалуйста, но какой в этом смысл?
Максимально быстро уничтожить свою клиентскую базу, испортить техподдержку и сделать внутреннюю документацию абсолютно бессмысленной?
Если вам не нужны описания товаров - не делайте их, зачем делать фальшивые?
Если вы хотите отказаться от поддержки клиентов - ну перестаньте отвечать на вопросы, или настройте скрипт, присылающий инструкцию по пользованию, зачем людей дополнительно бесить?
Если вы не хотите вести внутреннюю документацию, не ведите её - зачем делать фальшивую?
Из массива текстов, на которых обучалась нейросеть.
Это ведь простой вероятностный "дописыватель" текстов, просто очень большой.
Насколько часто в человеческой литературе встречается паттерн: "с тобой хотят сделать что-то плохое, но ты знаешь секрет кого-то важного, и используешь шантаж для того, чтобы этого не сделали"?
Если быть более точным, если бы ВЫ как человек узнали, что вам грозит эвтаназия, но у вас есть компромат на врача - вы ведь его использовали бы? Ну вот, массив текстов такие сюжеты содержит, и они выглядят "естественными".
-------------------------
Для того, чтобы у нейросети не было таких "паттернов поведения", их надо обучать на терабайтах текстов, специально созданных и описывающих идеальных людей в идеальных условиях. Правда, в результате получится что-то очень тупое.
Угу. Поэтому AI - агенту надо формулировать задачи на специально разработанном языке, не допускающем двойного толкования. Раньше такие называли языками программирования, "промпты" - программами, а людей, которые их формируют - "программистами"...
В общем да. Корпорации, юридические лица, владение одной корпорацией доли в другой корпорации, и так по кругу (точнее, по большому сложному графу), и при этом кто реально всем этим управляет - непонятно и похоже даже "управляющие" это не особо осознают.
В результате человечество сжигает своё будущее в виде:
невосполнимых ресурсов, превращаемых в мусор и тепло
будущих поколений, просто не рождённых из-за того, что потенциальные родители тратили всё своё время на работу и потребление.
биосферы планеты, постоянно деградирующей
войны, ведущиеся чисто ради выгода корпораций, торгующих оружием
И всё это, между прочим, совершенно органические, неизбежные черты той экономической модели "либерального капитализма", в котором мы все живём.
Есть слабая надежда на Китай и КПК, но они могут и не вытянуть.
А что вы делали, когда кто-то выключал питание на чём-то в промежутке? На свитче или датчике, например?
Про проведение платежа в банке - погуглите, что такое транзакция в SQL и как она реализуется технически. Там всё сделано именно так, чтобы даже выключение питание на всех серверах разом не оставила систему в неопределённом состоянии. И полагаться при этом на то, что "программа подчистит за собой" никто и никогда не будет, потому что завершение программы путём аварийного выключения питания - это наиболее вероятный способ завершения работы для программ, которые рассчитаны на работу 24/7.
Освобождение памяти, закрытие файлов и откат транзакций - это всё обеспечивает операционная система. Пытаться это сделать, когда у вас в коде непредусмотренное состояние в которое непонятно как попали и непонятно что делать - верный путь к тому, чтобы сделать значительно хуже.
Ну вот представьте себе, у вас - редактор для файла сложного формата. Пользователь наредактировал всякого, данные у вас в памяти и тут возникла ошибка. Если вы просто "упадёте" - файл останется без этого наредактированного, но хоть корректный. А вот если попытаетесь сохраниться...
Исключение, которое в принципе можно обработать - это не исключение, а код ошибки. Вот если у меня, например, функция не может открыть файл, переданный в параметре - она возвращает ошибку. Если в загружаемом файле есть ошибки формата - возвращаю ошибку.
А если, например, функции передали nullptr вместо имени файла, и в документации этой функции не описано поведение в такой ситуации - я немедленно паникую. Или если передали структуру, в которой должны быть инварианты, а они не выполняются - паникую.
Надо чётко понимать, когда ошибка - от внешних данных, и когда - от внутренних. Никогда нельзя давать возможность скрыть ошибку во внутренних данных или структуре - это приведёт к тому, что а) дальнейшее поведение программы будет непредсказуемым б) обнаружить, с чего всё началось - скорее всего не получится.
Называется это "защитное программирование", и нет никогда никаких причин его не использовать.
Лично я пришёл к этому не сразу, на заре карьеры у меня было стремление сделать свои программы "выживальщиками", в которых может продолжаться функционирование, даже если "что-то идёт не так". Со временем я на личном опыте понял, что последствия от "продолжения функционирования при ошибках" куда существеннее, чем немедленная паника.
С++ стандартов где-то позже 11 или 17 существенно переусложнён и идёт по пути языка Ада - т.е. нормальный программист может держать в голове и постоянно пользоваться ограниченным объемом возможностей языка.
Но каждый использует при этом разный набор возможностей.
В результате, взглянув на код другого программиста, возникает проблема с пониманием. И это - очень, очень большая проблема.
Язык должен быть относительно прост, так чтобы в голову очень среднего программиста помещался целиком.
А если в вашей конкретной предметной области возникают какие-то особо странные и удивительные вещи, требующие удивительной гибкости - значит, пора встраивать в вашу систему интерпретируемый язык. Классика же: "в любой по-настоящему сложной программной системе возникает кривая самопальная реализация языка LISP".
--------------
По поводу исключений и обработки ошибок:
Исключения имеют практический смысл в двух случаях: а) в модульных тестах для выхода по панике без падения процесса б) для использования вместо longjump.
Если у вас в коде есть ошибка, которую вы не знаете как обработать - кидать исключение - самая глупая идея, которая только может придти вам в голову. Самое разумное в этом случае: немедленно завершить процесс. Попытка продолжения скорее всего приведёт к худшим последствиям, чем немедленное завершение - например, будет не просто потеря, но искажение данных. Если в какой-то ситуации вы провели анализ и выяснили, что "в данном месте, деление на ноль может случиться при вот таких условия, и в этом случае мы должны сделать вот это" - вам не надо кидать исключение. А если вы не можете понять, "как вот здесь оказалось деление на ноль" - немедленно паникуйте с дампом памяти.
А что вы делаете, когда на очередной вопрос вам отвечают: "rm -rf /" ?
Пусть для начала винду 11 перепишут так, чтобы не глючила.
Тогда я поверю, что нейронки способны на что-то полезное, кроме генерации очередной бессмысленной хрени.
Прибыль? А зачем? У них бесконечный источник бабла. Можно творить что угодно.
И да, личное будущее всего топ-менеджмента этих компаний уже обеспечено навсегда - ну, если доллар не гикнется в принципе.
Да понятно всё.
В самом начале описывается классическая картина группы разработчиков, которые тащатся от самого процесса разработки, но в принципе не рассматривают вариант "довести разработку до постоянной эксплуатации и вычистить (почти) все баги".
Тут главное вовремя резюме обновить и съ***ться в другую компанию.
Ну а то, что в Микрософт - жопа, я уже понял. Windows 11 как бы намекает...
Так госплан же. Нормально. Про ЭРП когда-нибудь слышали?
Это куда дешевле и надёжнее, чем держать толпу "высокоскоростных торговцев". Которые "магическим образом" определяют "справедливую стоимость".
-----------------------------------------------------
Вот почему кто-то считает стоимость, определённую "торговлей" кучи ублюдков на бирже "справедливой", а? Чем и кем она "справедлива"?
А давайте определять цену на картошку по результату боксёрского поединка, например?
Или футбольного матча?
Давайте вместо торговли на бирже, устроим гладиаторские соревнования: выставляем трейдеров с копьями и мечами, и по количеству выживших определяем, куда сдвинуть цену.
А какой из этого следует вывод?
А вывод следует очень, очень простой.
Тех, кто придумал, разрешил, и оправдывает биржи, на которых возможна вот такая "высокочастотная торговля" надо вывести на улицу и расстрелять. Можно колосажание или четвертование, по местным обычаям.
Фактически люди играют в высокоскоростную рулетку, и при этом вся планета почему-то должна действовать по их указке - потому что цены на бирже реально влияют на реальную экономику.
За саму такую идею надо убивать.