День 2109. #Оффтоп #RegEx
Доброй пятницы, дорогие подписчики.
Сегодня порекомендую вам замечательное видео с канала Мэта Паркера Stand-up Maths.
Сначала, не подглядывая, как вы думаете, что проверяет следующий код:
Этот метод проверяет, является ли число простым! Да. Но как вот это ^.?$|^(..+?)\1+$ может выдавать простые числа?
Об этом подробно, а также «Regex 101» - объяснение того, как работают регулярные выражения в принципе, и это выражение в частности - от Мэта Паркера смотрите в его видео.
Для тех, кто предпочитает текст, Илья Герасимчук подробно разобрал это регулярное выражение в своей статье.
А вообще, подписывайтесь на канал Мэта, если так же, как я, любите всякие математические приколы (не переживайте, там всё объясняется на уровне средней школы).
Доброй пятницы, дорогие подписчики.
Сегодня порекомендую вам замечательное видео с канала Мэта Паркера Stand-up Maths.
Сначала, не подглядывая, как вы думаете, что проверяет следующий код:
static bool Check(int n)
{
return !Regex.IsMatch(
new string('1', n),
@"^.?$|^(..+?)\1+$"
);
}
Об этом подробно, а также «Regex 101» - объяснение того, как работают регулярные выражения в принципе, и это выражение в частности - от Мэта Паркера смотрите в его видео.
Для тех, кто предпочитает текст, Илья Герасимчук подробно разобрал это регулярное выражение в своей статье.
А вообще, подписывайтесь на канал Мэта, если так же, как я, любите всякие математические приколы (не переживайте, там всё объясняется на уровне средней школы).
👍20👎2
День 2129. #Оффтоп
Почему Разработчики Любят Чистый Код, но Ненавидят Писать Документацию? Начало
В Developer Coefficient, исследовании, заказанном финтех-гигантом Stripe, разработчики сообщили, что они тратят более 17 часов в неделю на задачи по обслуживанию, такие как отладка и рефакторинг — работа, классифицируемая ими как «мытарство».
Опрос разработчиков 2024 на StackOverflow выявил множество тех же проблем и жалоб. Наибольшим разочарованием, с большим отрывом, был технический долг. И наоборот, больше всего разработчиков радовало улучшение качества их кода и среды разработки. И заглядывая в будущее, две области, в которых разработчики чувствовали, что они получат наибольшую выгоду от инструментов GenAI, — это тестирование и документирование.
В какой степени отличная документация помогает сократить «мытарства» и технический долг, которые приводят к разочарованию и выгоранию разработчиков? И в какой степени она может поддерживать то, что делает их счастливыми, например, качество кода?
Действительно ли документация помогает?
Есть эмпирические доказательства того, что хорошая документация оказывает положительное влияние на такие работы, как рефакторинг или отладка. Мета-исследование более 60 научных работ по качеству ПО и документации показало, что преимущества отражаются во многих аспектах: сокращение продолжительности задачи, улучшение качества кода, более высокая производительность и т.п. И исследования показывают, что документация часто занимает 11% рабочего времени разработчиков.
В исследовании PLOS ONE 2023 года была разработана модель для проверки того, какие методы окажут положительное или отрицательное влияние на процесс рефакторинга. Авторы пишут, что «документация помогает в адаптации новых членов команды и обеспечивает согласованность методов рефакторинга во всей команде».
Документация была особенно ценна при рефакторинге, предоставляя план, который экономит время и улучшает фокусировку. Исследователи обнаружили, что хорошая документация «гарантирует, что усилия по рефакторингу направлены на ощутимые и конкретные улучшения качества, максимизируя ценность каждого действия по рефакторингу и гарантируя долгосрочную поддерживаемость и развитие ПО».
Проблемы в поддержании эффективной документации
Почему же разработчики так часто считают документацию низкоприоритетной работой, которую они предпочли бы избегать, и писать вместо этого код?
В быстро меняющихся средах разработки поддержание актуальности документации может быть сложной задачей. Разработчики часто снижают приоритет документации из-за сжатых сроков и сосредоточенности на предоставлении рабочего кода. Это приводит к неформальной, сложной для понимания документации, которая быстро устаревает по мере развития ПО.
Ещё одна важная проблема - документация часто рассматривается как ненужные накладные расходы. Разработчики полагают, что код должен быть понятным сам по себе или что документация замедляет процесс разработки. Но это затрудняет онбординг новых членов команды и увеличивает время на задачи по обслуживанию из-за трат времени на понимание плохо документированного кода.
Устаревшая или недостаточная документация усугубляет технический долг. Поскольку кодовая база меняется, редко обновляемая документация может вводить в заблуждение, что приводит к ошибкам и неэффективным рабочим процессам, способствуя разочарованию и выгоранию.
Возникает новая дисциплина, «инженерия документации», которая пытается сблизить действия по написанию и кодированию, приводя работу по документированию кода в большее соответствие со стилем и целями инженерного отдела.
Чтобы документация не стала второстепенным элементом в жизненном цикле разработки, она должна быть наблюдаемой, чем-то, что можно измерить по ключевым показателям эффективности и целям, которые разработчики и их менеджеры часто используют при реализации проектов.
Окончание следует…
Источник: https://stackoverflow.blog/2024/11/11/developers-hate-documentation-ai-generated-toil-work/
Почему Разработчики Любят Чистый Код, но Ненавидят Писать Документацию? Начало
В Developer Coefficient, исследовании, заказанном финтех-гигантом Stripe, разработчики сообщили, что они тратят более 17 часов в неделю на задачи по обслуживанию, такие как отладка и рефакторинг — работа, классифицируемая ими как «мытарство».
Опрос разработчиков 2024 на StackOverflow выявил множество тех же проблем и жалоб. Наибольшим разочарованием, с большим отрывом, был технический долг. И наоборот, больше всего разработчиков радовало улучшение качества их кода и среды разработки. И заглядывая в будущее, две области, в которых разработчики чувствовали, что они получат наибольшую выгоду от инструментов GenAI, — это тестирование и документирование.
В какой степени отличная документация помогает сократить «мытарства» и технический долг, которые приводят к разочарованию и выгоранию разработчиков? И в какой степени она может поддерживать то, что делает их счастливыми, например, качество кода?
Действительно ли документация помогает?
Есть эмпирические доказательства того, что хорошая документация оказывает положительное влияние на такие работы, как рефакторинг или отладка. Мета-исследование более 60 научных работ по качеству ПО и документации показало, что преимущества отражаются во многих аспектах: сокращение продолжительности задачи, улучшение качества кода, более высокая производительность и т.п. И исследования показывают, что документация часто занимает 11% рабочего времени разработчиков.
В исследовании PLOS ONE 2023 года была разработана модель для проверки того, какие методы окажут положительное или отрицательное влияние на процесс рефакторинга. Авторы пишут, что «документация помогает в адаптации новых членов команды и обеспечивает согласованность методов рефакторинга во всей команде».
Документация была особенно ценна при рефакторинге, предоставляя план, который экономит время и улучшает фокусировку. Исследователи обнаружили, что хорошая документация «гарантирует, что усилия по рефакторингу направлены на ощутимые и конкретные улучшения качества, максимизируя ценность каждого действия по рефакторингу и гарантируя долгосрочную поддерживаемость и развитие ПО».
Проблемы в поддержании эффективной документации
Почему же разработчики так часто считают документацию низкоприоритетной работой, которую они предпочли бы избегать, и писать вместо этого код?
В быстро меняющихся средах разработки поддержание актуальности документации может быть сложной задачей. Разработчики часто снижают приоритет документации из-за сжатых сроков и сосредоточенности на предоставлении рабочего кода. Это приводит к неформальной, сложной для понимания документации, которая быстро устаревает по мере развития ПО.
Ещё одна важная проблема - документация часто рассматривается как ненужные накладные расходы. Разработчики полагают, что код должен быть понятным сам по себе или что документация замедляет процесс разработки. Но это затрудняет онбординг новых членов команды и увеличивает время на задачи по обслуживанию из-за трат времени на понимание плохо документированного кода.
Устаревшая или недостаточная документация усугубляет технический долг. Поскольку кодовая база меняется, редко обновляемая документация может вводить в заблуждение, что приводит к ошибкам и неэффективным рабочим процессам, способствуя разочарованию и выгоранию.
Возникает новая дисциплина, «инженерия документации», которая пытается сблизить действия по написанию и кодированию, приводя работу по документированию кода в большее соответствие со стилем и целями инженерного отдела.
Чтобы документация не стала второстепенным элементом в жизненном цикле разработки, она должна быть наблюдаемой, чем-то, что можно измерить по ключевым показателям эффективности и целям, которые разработчики и их менеджеры часто используют при реализации проектов.
Окончание следует…
Источник: https://stackoverflow.blog/2024/11/11/developers-hate-documentation-ai-generated-toil-work/
👍6
День 2130. #Оффтоп
Почему Разработчики Любят Чистый Код, но Ненавидят Писать Документацию? Окончание
Начало
Является ли документация, созданная ИИ, хорошим решением?
Существует несколько различных способов, которыми разработчик или команда разработчиков могут подойти к этой проблеме. В этом видео показано, как GitHub CoPilot работает как предиктивный движок, принимая подсказку от разработчика, а затем расширяя мысль и добавляя соответствующие детали.
Одним из ключевых элементов «мытарства» является нарушение состояния потока разработчика: ментальной зоны, где программисты наиболее продуктивны и креативны. Такие прерывания, как поиск недостающей документации или понимание запутанного кода, выводят разработчиков из потока, способствуя выгоранию и снижению удовлетворённости работой. Учитывая, насколько важна документация для сокращения технического долга и поддержания качества кода, автоматизация её создания является естественным решением.
Системы GenAI могут автоматически генерировать документацию либо в режиме реального времени, пока разработчик пишет код, либо после, просматривая кодовую базу. В то время как некоторые предлагают общие предложения на основе своих обучающих данных, другие настраиваются на вашу конкретную кодовую базу.
Переложив бремя создания документации на ИИ, разработчики могут сосредоточиться на задачах, которые им нравятся — разработке и решении проблем, — и при этом следить за тем, чтобы документация оставалась полной и актуальной.
Возможно, самое важное, что эта синергия между GenAI и разработчиками-людьми не устраняет человеческий надзор. Разработчики сохраняют контроль над результатом, направляя ИИ и проверяя точность вывода, что гарантирует соответствие конечного продукта их намерениям.
Лучшие практики для документации в Agile среде
Важно рассматривать эти инструменты как инструменты для внедрения новых лучших практик, которыми по-прежнему управляют люди, а не как роботов, которые выполняют всю работу самостоятельно.
Один из подходов заключается в использовании современных инструментов, которые автоматизируют поиск и создание документации. Инструменты, которые интегрируются со средой разработки, могут автоматически обновлять документацию по мере изменения кода, гарантируя, что она останется актуальной без необходимости значительных ручных усилий.
Другой вариант — внедрение исполняемой документации, которая развивается вместе с кодом. Сюда входят такие методы, как грамотное программирование или использование инструментов, которые генерируют документацию из комментариев и аннотаций кода. Встраивая документацию в сам код, разработчики могут гарантировать, что она останется синхронизированной с кодовой базой.
Принятие стратегии минимальной предварительной документации и подробной проектной документации впоследствии также может быть полезным. Это позволяет командам оставаться гибкими во время разработки, при этом сохраняя важную информацию для будущего использования. Такие практики поддерживают лучшую передачу знаний и помогают сократить труд, связанный с адаптацией и обслуживанием.
Используйте автоматизированный труд
Даже компании, ориентированные на ИИ, знают боль от устаревших документов. Но учитывая всех помощников в разработке кода, будущее, в котором код будет синхронизирован с документацией, вполне вероятно. Если ИИ может генерировать код, он может генерировать документы и поддерживать их в актуальном состоянии. Использование помощи ИИ для сокращения рутинной работы и повышения общего качества кода быстро становится ключевым навыком опытного разработчика.
Используя инструменты документации на основе ИИ, команды разработчиков могут сократить рутинную работу и уменьшить технический долг. Инженеры по документации или технические писатели будут выступать в качестве редакторов и распорядителей любой документации, созданной ИИ, предотвращая попадание ошибок или галлюцинаций в в остальном качественные документы.
Источник: https://stackoverflow.blog/2024/11/11/developers-hate-documentation-ai-generated-toil-work/
Почему Разработчики Любят Чистый Код, но Ненавидят Писать Документацию? Окончание
Начало
Является ли документация, созданная ИИ, хорошим решением?
Существует несколько различных способов, которыми разработчик или команда разработчиков могут подойти к этой проблеме. В этом видео показано, как GitHub CoPilot работает как предиктивный движок, принимая подсказку от разработчика, а затем расширяя мысль и добавляя соответствующие детали.
Одним из ключевых элементов «мытарства» является нарушение состояния потока разработчика: ментальной зоны, где программисты наиболее продуктивны и креативны. Такие прерывания, как поиск недостающей документации или понимание запутанного кода, выводят разработчиков из потока, способствуя выгоранию и снижению удовлетворённости работой. Учитывая, насколько важна документация для сокращения технического долга и поддержания качества кода, автоматизация её создания является естественным решением.
Системы GenAI могут автоматически генерировать документацию либо в режиме реального времени, пока разработчик пишет код, либо после, просматривая кодовую базу. В то время как некоторые предлагают общие предложения на основе своих обучающих данных, другие настраиваются на вашу конкретную кодовую базу.
Переложив бремя создания документации на ИИ, разработчики могут сосредоточиться на задачах, которые им нравятся — разработке и решении проблем, — и при этом следить за тем, чтобы документация оставалась полной и актуальной.
Возможно, самое важное, что эта синергия между GenAI и разработчиками-людьми не устраняет человеческий надзор. Разработчики сохраняют контроль над результатом, направляя ИИ и проверяя точность вывода, что гарантирует соответствие конечного продукта их намерениям.
Лучшие практики для документации в Agile среде
Важно рассматривать эти инструменты как инструменты для внедрения новых лучших практик, которыми по-прежнему управляют люди, а не как роботов, которые выполняют всю работу самостоятельно.
Один из подходов заключается в использовании современных инструментов, которые автоматизируют поиск и создание документации. Инструменты, которые интегрируются со средой разработки, могут автоматически обновлять документацию по мере изменения кода, гарантируя, что она останется актуальной без необходимости значительных ручных усилий.
Другой вариант — внедрение исполняемой документации, которая развивается вместе с кодом. Сюда входят такие методы, как грамотное программирование или использование инструментов, которые генерируют документацию из комментариев и аннотаций кода. Встраивая документацию в сам код, разработчики могут гарантировать, что она останется синхронизированной с кодовой базой.
Принятие стратегии минимальной предварительной документации и подробной проектной документации впоследствии также может быть полезным. Это позволяет командам оставаться гибкими во время разработки, при этом сохраняя важную информацию для будущего использования. Такие практики поддерживают лучшую передачу знаний и помогают сократить труд, связанный с адаптацией и обслуживанием.
Используйте автоматизированный труд
Даже компании, ориентированные на ИИ, знают боль от устаревших документов. Но учитывая всех помощников в разработке кода, будущее, в котором код будет синхронизирован с документацией, вполне вероятно. Если ИИ может генерировать код, он может генерировать документы и поддерживать их в актуальном состоянии. Использование помощи ИИ для сокращения рутинной работы и повышения общего качества кода быстро становится ключевым навыком опытного разработчика.
Используя инструменты документации на основе ИИ, команды разработчиков могут сократить рутинную работу и уменьшить технический долг. Инженеры по документации или технические писатели будут выступать в качестве редакторов и распорядителей любой документации, созданной ИИ, предотвращая попадание ошибок или галлюцинаций в в остальном качественные документы.
Источник: https://stackoverflow.blog/2024/11/11/developers-hate-documentation-ai-generated-toil-work/
👍4
День 2136. #Оффтоп
async2 — Завершение Эксперимента с Асинхронностью в .NET. Начало
Команда .NET работала над новым экспериментом под названием async2, который представляет собой новую реализацию шаблона async/await, разработанную для большей эффективности и гибкости, чем текущая реализация. Он начался с зелёных потоков и закончился экспериментом, который перемещает async и await в среду выполнения. Рассмотрим путь async2 и то, чем закончился эксперимент.
Зелёные потоки
Всё началось с зелёных потоков. Это пользовательские потоки, которые управляются библиотекой времени выполнения или виртуальной машиной, а не операционной системой. Они лёгкие и могут создаваться и управляться быстрее, чем потоки ядра. Зелёные потоки также известны как «сопрограммы» или «волокна» в других языках программирования. Идея заключается в том, что вам, как разработчику, не нужно беспокоиться о потоках.
В настоящее время для потоков и в некоторой степени для async/await создаётся новый стек. Вы можете легко увидеть это в IDE, при отладке (см. картинку).
Зелёные потоки отличаются. Память зелёного потока выделяется в куче. Но это имеет свою цену: поскольку они не управляются ОС, они по своей сути не могут использовать преимущества нескольких ядер. Но для операций, связанных с вводом-выводом, они хорошо подходят.
Отказ от зелёных потоков
Ключевые проблемы, которые привели к отказу от эксперимента с зелеными потоками, были следующими:
1. Сложное взаимодействие между зелёными потоками и существующей моделью асинхронности;
2. Взаимодействие с нативным кодом было сложным и медленнее, чем при использовании обычных потоков;
3. Проблемы совместимости с мерами безопасности, такими как теневые стеки;
4. Неопределённость относительно того, можно ли сделать зелёные потоки быстрее, чем async в важных сценариях, учитывая усилия, необходимые для улучшения.
Это привело к выводу, что зелёные потоки — неверный путь для среды выполнения .NET, и породило эксперимент async2.
async2
Очевидно, это просто кодовое имя. Целью эксперимента было переместить async и await в среду выполнения. Главной мотивацией этого было сделать async более эффективным и гибким. Поскольку async уже используется как идентификатор в C#, команда решила использовать async2 в качестве кодового имени для эксперимента. Если эта штука когда-нибудь попадёт в среду выполнения, она будет называться async — то есть это будет замена текущей реализации async. В следующем посте разберём, что же это такое.
Окончание следует…
Источник: https://steven-giesel.com/blogPost/59752c38-9c99-4641-9853-9cfa97bb2d29/async2-the-net-runtime-async-experiment-concludes
async2 — Завершение Эксперимента с Асинхронностью в .NET. Начало
Команда .NET работала над новым экспериментом под названием async2, который представляет собой новую реализацию шаблона async/await, разработанную для большей эффективности и гибкости, чем текущая реализация. Он начался с зелёных потоков и закончился экспериментом, который перемещает async и await в среду выполнения. Рассмотрим путь async2 и то, чем закончился эксперимент.
Зелёные потоки
Всё началось с зелёных потоков. Это пользовательские потоки, которые управляются библиотекой времени выполнения или виртуальной машиной, а не операционной системой. Они лёгкие и могут создаваться и управляться быстрее, чем потоки ядра. Зелёные потоки также известны как «сопрограммы» или «волокна» в других языках программирования. Идея заключается в том, что вам, как разработчику, не нужно беспокоиться о потоках.
В настоящее время для потоков и в некоторой степени для async/await создаётся новый стек. Вы можете легко увидеть это в IDE, при отладке (см. картинку).
Зелёные потоки отличаются. Память зелёного потока выделяется в куче. Но это имеет свою цену: поскольку они не управляются ОС, они по своей сути не могут использовать преимущества нескольких ядер. Но для операций, связанных с вводом-выводом, они хорошо подходят.
Отказ от зелёных потоков
Ключевые проблемы, которые привели к отказу от эксперимента с зелеными потоками, были следующими:
1. Сложное взаимодействие между зелёными потоками и существующей моделью асинхронности;
2. Взаимодействие с нативным кодом было сложным и медленнее, чем при использовании обычных потоков;
3. Проблемы совместимости с мерами безопасности, такими как теневые стеки;
4. Неопределённость относительно того, можно ли сделать зелёные потоки быстрее, чем async в важных сценариях, учитывая усилия, необходимые для улучшения.
Это привело к выводу, что зелёные потоки — неверный путь для среды выполнения .NET, и породило эксперимент async2.
async2
Очевидно, это просто кодовое имя. Целью эксперимента было переместить async и await в среду выполнения. Главной мотивацией этого было сделать async более эффективным и гибким. Поскольку async уже используется как идентификатор в C#, команда решила использовать async2 в качестве кодового имени для эксперимента. Если эта штука когда-нибудь попадёт в среду выполнения, она будет называться async — то есть это будет замена текущей реализации async. В следующем посте разберём, что же это такое.
Окончание следует…
Источник: https://steven-giesel.com/blogPost/59752c38-9c99-4641-9853-9cfa97bb2d29/async2-the-net-runtime-async-experiment-concludes
👍25
День 2137. #Оффтоп
async2 — Завершение Эксперимента с Асинхронностью в .NET. Окончание
Начало
async — функция компилятора
Текущая реализация async и await — это функция компилятора. Компилятор генерирует конечный автомат для async -метода. Среда выполнения ничего не знает об async и await. Нет никаких следов ключевого слова async в IL или в JIT-скомпилированном коде. И вот с этого начался эксперимент, подробно описанный здесь.
async — функция среды выполнения
Целью эксперимента было переместить async и await в среду выполнения. Это позволило бы среде выполнения иметь больше контроля над самим шаблоном. При этом также была бы другая семантика.
async2 не сохраняет и не восстанавливает контекст синхронизации и контекст исполнения на границах функций, вместо этого позволяя вызывающим методам наблюдать изменения. С ExecutionContext это изменяет поведение AsyncLocal.
Сегодня AsyncLocal используется для хранения данных, которые передаются с логическим контекстом вызова. Они копируются в новый контекст. Тем не менее, если функция глубоко в стеке вызовов изменяет значение AsyncLocal, вызывающий метод не увидит обновлённое значение, его увидят только методы ниже по логическому асинхронному потоку. Например:
Вывод:
В async2 изменения не «откатываются», что приводит к другому выводу:
Сравнение с текущей реализацией
Команда обнаружила, что подход с помещением асинхронности в JIT может дать наилучшие результаты в целом. Вот основные отличия:
1. Производительность
Async обычно медленнее, чем async2, особенно для глубоких стеков вызовов, где async2 имеет производительность, сопоставимую с синхронным кодом в сценариях без приостановки исполнения.
2. Обработка исключений
В async медленно и неэффективно, вызывает паузы GC и влияет на отзывчивость приложений. В async2 улучшена.
3. Ограничение глубины стека
Присутствует в async, что может вызвать проблемы для глубоких стеков вызовов. Нет явных ограничений в async2.
4. Потребление памяти
В async обычно ниже, особенно в сценариях с большим количеством приостановленных задач. В async2 более высокое потребление памяти из-за захвата целых стековых кадров и регистров, но все ещё приемлемо по сравнению с другими факторами, такими как время паузы.
Полный документ здесь.
Что дальше?
Пока это всего лишь эксперимент, который может привести к замене async через несколько лет. Да, может пройти некоторое время, прежде чем это будет выпущено. А для переходной фазы должен быть interop для async <-> async2. В любом случае - очень хорошая отправная точка. Ждём async2, как юнионов.
Источник: https://steven-giesel.com/blogPost/59752c38-9c99-4641-9853-9cfa97bb2d29/async2-the-net-runtime-async-experiment-concludes
async2 — Завершение Эксперимента с Асинхронностью в .NET. Окончание
Начало
async — функция компилятора
Текущая реализация async и await — это функция компилятора. Компилятор генерирует конечный автомат для async -метода. Среда выполнения ничего не знает об async и await. Нет никаких следов ключевого слова async в IL или в JIT-скомпилированном коде. И вот с этого начался эксперимент, подробно описанный здесь.
async — функция среды выполнения
Целью эксперимента было переместить async и await в среду выполнения. Это позволило бы среде выполнения иметь больше контроля над самим шаблоном. При этом также была бы другая семантика.
async2 не сохраняет и не восстанавливает контекст синхронизации и контекст исполнения на границах функций, вместо этого позволяя вызывающим методам наблюдать изменения. С ExecutionContext это изменяет поведение AsyncLocal.
Сегодня AsyncLocal используется для хранения данных, которые передаются с логическим контекстом вызова. Они копируются в новый контекст. Тем не менее, если функция глубоко в стеке вызовов изменяет значение AsyncLocal, вызывающий метод не увидит обновлённое значение, его увидят только методы ниже по логическому асинхронному потоку. Например:
await new AsyncLocalTest().Outer();
public class AsyncLocalTest
{
private readonly AsyncLocal<string>
_al = new();
public async Task Outer()
{
_al.Value = "Out";
Console.WriteLine($"Outer: {_al.Value}");
await Inner();
Console.WriteLine($"Outer: {_al.Value}");
}
private async Task Inner()
{
_al.Value = "In";
Console.WriteLine($"Inner: {_al.Value}");
await Task.Yield();
Console.WriteLine($"Inner: {_al.Value}");
}
}
Вывод:
Outer: Out
Inner: In
Inner: In
Outer: Out
В async2 изменения не «откатываются», что приводит к другому выводу:
Outer: Out
Inner: In
Inner: In
Outer: In
Сравнение с текущей реализацией
Команда обнаружила, что подход с помещением асинхронности в JIT может дать наилучшие результаты в целом. Вот основные отличия:
1. Производительность
Async обычно медленнее, чем async2, особенно для глубоких стеков вызовов, где async2 имеет производительность, сопоставимую с синхронным кодом в сценариях без приостановки исполнения.
2. Обработка исключений
В async медленно и неэффективно, вызывает паузы GC и влияет на отзывчивость приложений. В async2 улучшена.
3. Ограничение глубины стека
Присутствует в async, что может вызвать проблемы для глубоких стеков вызовов. Нет явных ограничений в async2.
4. Потребление памяти
В async обычно ниже, особенно в сценариях с большим количеством приостановленных задач. В async2 более высокое потребление памяти из-за захвата целых стековых кадров и регистров, но все ещё приемлемо по сравнению с другими факторами, такими как время паузы.
Полный документ здесь.
Что дальше?
Пока это всего лишь эксперимент, который может привести к замене async через несколько лет. Да, может пройти некоторое время, прежде чем это будет выпущено. А для переходной фазы должен быть interop для async <-> async2. В любом случае - очень хорошая отправная точка. Ждём async2, как юнионов.
Источник: https://steven-giesel.com/blogPost/59752c38-9c99-4641-9853-9cfa97bb2d29/async2-the-net-runtime-async-experiment-concludes
👍20
День 2144. #Оффтоп
Развлекаемся с ValueTuple
Этот пост, скорее всего, не принесёт вам никакой пользы в вашей повседневной жизни — ну, разве что улыбку. Сегодня мы доведём ValueTuple до крайности!
Тип ValueTuple — это приятный синтаксический сахар. Если у вас есть следующий код, даже если вы назвали элементы кортежа:
Это будет преобразовано компилятором в:
Итак, компилятор генерирует список элементов, пронумерованных от 1 до любого количества элементов, которые у вас есть. Но происходит что-то интересное, если вы добавляете больше 7 элементов:
Это преобразовывается компилятором в:
После 7го элемента компилятор генерирует новое свойство Rest для хранения… ну, остального. Поэтому, если мы немного посходим с ума:
И используем это так:
То мы получим что-то вроде
Если хотите поиграть с этим, заходите на sharblap.io.
Источник: https://steven-giesel.com/blogPost/0a3db64c-e514-45fc-a1a1-2b79cc42f797/having-fun-with-valuetuple
Развлекаемся с ValueTuple
Этот пост, скорее всего, не принесёт вам никакой пользы в вашей повседневной жизни — ну, разве что улыбку. Сегодня мы доведём ValueTuple до крайности!
Тип ValueTuple — это приятный синтаксический сахар. Если у вас есть следующий код, даже если вы назвали элементы кортежа:
(var one, var two) = MyFunc();
Console.WriteLine(one + two);
(int ANumber, int AnotherNumber)
MyFunc() => (1,2);
Это будет преобразовано компилятором в:
[CompilerGenerated]
internal class Program
{
private static void <Main>$(string[] args)
{
ValueTuple<int, int> valueTuple = <<Main>$>g__MyFunc|0_0();
int item = valueTuple.Item1;
int item2 = valueTuple.Item2;
Console.WriteLine(item + item2);
}
[CompilerGenerated]
[return: TupleElementNames(new string[] { "ANumber", "AnotherNumber" })]
internal static ValueTuple<int, int> <<Main>$>g__MyFunc|0_0()
{
return new ValueTuple<int, int>(1, 2);
}
}
Итак, компилятор генерирует список элементов, пронумерованных от 1 до любого количества элементов, которые у вас есть. Но происходит что-то интересное, если вы добавляете больше 7 элементов:
var (a,b,c,d,e,f,g,h) = MyFunc();
Console.WriteLine(a+b+c+d+e+f+g+h);
(int a, int b, int c, int d, int e, int f, int g, int h) MyFunc()
=> (1,2,3,4,5,6,7,8);
Это преобразовывается компилятором в:
ValueTuple<int, int, int, int, int, int, int, ValueTuple<int>> valueTuple = <<Main>$>g__MyFunc|0_0();
int item = valueTuple.Item1;
int item2 = valueTuple.Item2;
int item3 = valueTuple.Item3;
int item4 = valueTuple.Item4;
int item5 = valueTuple.Item5;
int item6 = valueTuple.Item6;
int item7 = valueTuple.Item7;
int item8 = valueTuple.Rest.Item1;
Console.WriteLine(item + item2 + item3 + item4 + item5 + item6 + item7 + item8);
После 7го элемента компилятор генерирует новое свойство Rest для хранения… ну, остального. Поэтому, если мы немного посходим с ума:
(int a, int b, int c, int d, int e, int f, int g, int h, int i, int j, int k, int l, int m, int n, int o, int p, int q, int r, int s, int t, int u, int v, int w, int x, int y, int z, int aa, int bb, int cc, int dd, int ee, int ff, int gg, int hh, int ii, int jj, int kk, int ll, int mm, int nn, int oo, int pp, int qq, int rr, int ss, int tt, int uu, int vv, int ww, int xx) MyFunc()
{
return (1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
11, 12, 13, 14, 15, 16, 17, 18, 19, 20,
21, 22, 23, 24, 25, 26, 27, 28, 29, 30,
31, 32, 33, 34, 35, 36, 37, 38, 39, 40,
41, 42, 43, 44, 45, 46, 47, 48, 49, 50);
}
И используем это так:
var (a,b,c,…,xx) = MyFunc();
То мы получим что-то вроде
valueTuple.Rest.Rest.Rest.Rest.Item1.Если хотите поиграть с этим, заходите на sharblap.io.
Источник: https://steven-giesel.com/blogPost/0a3db64c-e514-45fc-a1a1-2b79cc42f797/having-fun-with-valuetuple
👍22👎1
День 2164. #Оффтоп
Никому Больше не Нравится Название .NET Core
Автор оригинала: Стивен Клири
Я подумал, что будет неплохо написать об истории терминологии «.NET Core». Вот каким я запомнил термин «.NET Core». Это не гарантирует правильности и, конечно, не гарантирует полноты! Я что-то упустил? Не стесняйтесь сообщить в комментариях!
.NET Compact Framework
Я думаю, что впервые услышал термин «.NET Core» в отношении .NET Compact Framework. Это было давно, когда .NET Framework 3.5 был новинкой. Точнее это был «.NET Framework 3.5 SP1» — Service Pack 1. Да, и у .NET раньше были пакеты обновлений.
Я не уверен, является ли «.NET Core» правильным термином для обозначения NetCF или нет. Насколько мне известно, это был неофициальный термин, который был применён, поскольку .NET Compact Framework содержал небольшое подмножество огромного .NET Framework, предназначенное для работы на встраиваемых устройствах. Следовательно, это был «основной» (core), минимальный, фреймворк.
Silverlight, WinRT, Windows Phone, Windows Store и Universal Windows Platform
Прошу прощенья у всех, кого передёрнуло от одного прочтения названия этого раздела…
Все эти технологии имели какое-то отношение к «.NET Core» как к термину. Все они были минимальными подфреймворками полной .NET Framework. И по крайней мере некоторые из них имели схожую терминологию для своих сред выполнения (например, Silverlight работал на «Core CLR»). Мой мозг милостиво забыл грязные подробности. Я только смутно помню, что платформа Windows Phone отличалась от платформы для приложений в Windows Store, а Silverlight стал ещё более урезанным для работы на Windows Phone.
Это было не самое весёлое время для разработчика библиотек.
netcore как моникер целевой платформы
Моникеры целевой платформы (Target framework moniker - TFM) очень важны для разработчиков библиотек.
Термин «.NET Core» официально вошёл в пространство NuGet как TFM, но не для того, что мы называем .NET Core сегодня. Он был для приложений Windows Store (и приложений WinRT) и ненадолго распространился на приложения UWP.
Да, проекты Windows Store ещё в Windows 8.0 (а также WinRT) использовали идентификатор TFM netcore45. Windows 8.1 использовал netcore451. Когда приложения Windows Store были заменены приложениями универсальной платформы Windows (UWP), они недолго использовали netcore50, прежде чем перейти на uap10.0.
Поэтому, если (современной) команде .NET Core вдруг понадобится TFM, они обнаружат, что netcoreNN недоступен. Я предполагаю, что именно поэтому был выбран моникер netcoreappNN (после краткого использования на dnxcore50 и aspnetcore50). Так что .NET Core TFM для старых версий (1.0-3.1) – это с netcoreapp1.0 до netcoreapp3.1. Это была просто досадная историческая случайность.
Больше никакого .NET Core
Команда .NET отказалась от «Core». Теперь у нас единый .NET — большое облегчение для авторов библиотек!
С версии 5 даже TFM изменились: современный .NET использует net9.0 и подобные, опустив прозвище «core» даже из TFM.
Я все ещё время от времени называю .NET как «.NET Core», особенно в разговорах, где упоминаются как .NET Framework, так и нового .NET. Например, я буду говорить «миграция на .NET Core», а не просто «миграция на .NET» для проекта, который в настоящее время нацелен на .NET Framework. Однако правильный термин больше не «.NET Core», а просто «.NET».
Источник: https://blog.stephencleary.com/2024/12/netcore.html
Никому Больше не Нравится Название .NET Core
Автор оригинала: Стивен Клири
Я подумал, что будет неплохо написать об истории терминологии «.NET Core». Вот каким я запомнил термин «.NET Core». Это не гарантирует правильности и, конечно, не гарантирует полноты! Я что-то упустил? Не стесняйтесь сообщить в комментариях!
.NET Compact Framework
Я думаю, что впервые услышал термин «.NET Core» в отношении .NET Compact Framework. Это было давно, когда .NET Framework 3.5 был новинкой. Точнее это был «.NET Framework 3.5 SP1» — Service Pack 1. Да, и у .NET раньше были пакеты обновлений.
Я не уверен, является ли «.NET Core» правильным термином для обозначения NetCF или нет. Насколько мне известно, это был неофициальный термин, который был применён, поскольку .NET Compact Framework содержал небольшое подмножество огромного .NET Framework, предназначенное для работы на встраиваемых устройствах. Следовательно, это был «основной» (core), минимальный, фреймворк.
Silverlight, WinRT, Windows Phone, Windows Store и Universal Windows Platform
Прошу прощенья у всех, кого передёрнуло от одного прочтения названия этого раздела…
Все эти технологии имели какое-то отношение к «.NET Core» как к термину. Все они были минимальными подфреймворками полной .NET Framework. И по крайней мере некоторые из них имели схожую терминологию для своих сред выполнения (например, Silverlight работал на «Core CLR»). Мой мозг милостиво забыл грязные подробности. Я только смутно помню, что платформа Windows Phone отличалась от платформы для приложений в Windows Store, а Silverlight стал ещё более урезанным для работы на Windows Phone.
Это было не самое весёлое время для разработчика библиотек.
netcore как моникер целевой платформы
Моникеры целевой платформы (Target framework moniker - TFM) очень важны для разработчиков библиотек.
Термин «.NET Core» официально вошёл в пространство NuGet как TFM, но не для того, что мы называем .NET Core сегодня. Он был для приложений Windows Store (и приложений WinRT) и ненадолго распространился на приложения UWP.
Да, проекты Windows Store ещё в Windows 8.0 (а также WinRT) использовали идентификатор TFM netcore45. Windows 8.1 использовал netcore451. Когда приложения Windows Store были заменены приложениями универсальной платформы Windows (UWP), они недолго использовали netcore50, прежде чем перейти на uap10.0.
Поэтому, если (современной) команде .NET Core вдруг понадобится TFM, они обнаружат, что netcoreNN недоступен. Я предполагаю, что именно поэтому был выбран моникер netcoreappNN (после краткого использования на dnxcore50 и aspnetcore50). Так что .NET Core TFM для старых версий (1.0-3.1) – это с netcoreapp1.0 до netcoreapp3.1. Это была просто досадная историческая случайность.
Больше никакого .NET Core
Команда .NET отказалась от «Core». Теперь у нас единый .NET — большое облегчение для авторов библиотек!
С версии 5 даже TFM изменились: современный .NET использует net9.0 и подобные, опустив прозвище «core» даже из TFM.
Я все ещё время от времени называю .NET как «.NET Core», особенно в разговорах, где упоминаются как .NET Framework, так и нового .NET. Например, я буду говорить «миграция на .NET Core», а не просто «миграция на .NET» для проекта, который в настоящее время нацелен на .NET Framework. Однако правильный термин больше не «.NET Core», а просто «.NET».
Источник: https://blog.stephencleary.com/2024/12/netcore.html
👍19👎2
День 2165. #Оффтоп #AI
ИИ не Заменит Команду Инженеров. Начало
Если позволите, я тоже немного отдохну. Поэтому вот вам лёгкий лонгрид на праздники.
На заре распространения персональных компьютеров найти работу сисадмином или веб-дизайнером было проще простого. Если ты знал пяток команд командной строки и мог набросать простенькую HTML-форму, обязательно нашёлся бы тот, кто был согласен тебе платить. Не нужно было даже образования. Только настойчивость и желание работать. Сейчас это совсем не так.
В какой-то степени это всегда происходит, когда отрасль взрослеет. Ранние дни любой отрасли — это что-то вроде Дикого Запада, где ставки низкие, регулирование отсутствует, а стандарты только зарождаются. Это никогда не длится долго. Количество предварительных знаний и опыта, которые вам необходимо иметь, прежде чем вы сможете войти в отрасль, стремительно увеличивается. Растут ставки, масштабы и цена ошибок. Появляются сертификации, тренинги, стандарты, юридические процедуры. Мы спорим о том, являются ли инженеры-программисты на самом деле инженерами.
ПО - индустрия обучения
Сейчас никто не возьмёт недоучившегося студента в штат. Необходимые для входа в индустрию знания выросли, вы больше не можете научиться буквально всему на работе, как когда-то.
Но не похоже, что вы можете научиться всему и в вузе. Степень в области компьютерных наук обычно лучше готовит вас к жизни компьютерных исследователей, чем к жизни в качестве обычного инженера-программиста. Более практичным путём в индустрию может стать хороший учебный лагерь по кодированию с упором на решение проблем и изучение современного инструментария. В любом случае вы не столько узнаете, «как выполнять работу», сколько «узнаете достаточно основ, чтобы понимать и использовать инструменты, необходимые для изучения работы».
ПО — индустрия обучения. Вы не можете научиться быть инженером-программистом, читая книги. Вы можете учиться только делая… и делая, и ещё делая. Неважно, какое у вас образование, большая часть обучения происходит на работе… и никогда не заканчивается!
Требуется более 7 лет, чтобы выковать компетентного инженера-программиста (как в большинстве случаев называют, сеньора). Это много лет написания, проверки и развёртывания кода каждый день в команде вместе с более опытными инженерами.
Что значит быть «сеньором»?
Об этом есть целая серия постов на канале. Ищите по тэгу #КакСтатьСеньором
По поводу сроков есть очень много споров:
«7 лет?! Пфф, мне потребовалось 2 года!»
«Меня повысили до сеньора меньше, чем за 5 лет!»
Молодцы! Да, в 7 годах нет ничего волшебного. Но для того, чтобы стать опытным инженером, способным сплотить команду, требуются время и опыт. Более того, нужна практика.
Думаю, мы стали использовать слово «сеньор» как сокращение для инженеров, которые могут поставлять готовый чистый код и быть продуктивными, и кажется, что это огромная ошибка. Это подразумевает, что младшие инженеры менее продуктивны, что неверно. И это упускает из виду истинную природу работы по разработке ПО, в которой написание кода является лишь небольшой частью.
Быть сеньором — это не способность писать код. Это гораздо больше связано с вашей способностью понимать, поддерживать, объяснять и управлять большим объёмом ПО в производстве с течением времени, а также способностью переводить бизнес-потребности в техническую реализацию. Большая часть работы связана с созданием и курированием этих больших, сложных социотехнических систем, а код — это всего лишь одно из представлений этих систем. Это значит, что вы научились, прежде всего, учиться и учить; как держать эти модели в голове и рассуждать о них, и как поддерживать, расширять и эксплуатировать эти системы с течением времени. Это значит, что у вас есть здравый смысл и инстинкты, которым вы можете доверять.
Что подводит нас к вопросу об ИИ.
Продолжение следует…
Источник: https://stackoverflow.blog/2024/12/31/generative-ai-is-not-going-to-build-your-engineering-team-for-you
ИИ не Заменит Команду Инженеров. Начало
Если позволите, я тоже немного отдохну. Поэтому вот вам лёгкий лонгрид на праздники.
На заре распространения персональных компьютеров найти работу сисадмином или веб-дизайнером было проще простого. Если ты знал пяток команд командной строки и мог набросать простенькую HTML-форму, обязательно нашёлся бы тот, кто был согласен тебе платить. Не нужно было даже образования. Только настойчивость и желание работать. Сейчас это совсем не так.
В какой-то степени это всегда происходит, когда отрасль взрослеет. Ранние дни любой отрасли — это что-то вроде Дикого Запада, где ставки низкие, регулирование отсутствует, а стандарты только зарождаются. Это никогда не длится долго. Количество предварительных знаний и опыта, которые вам необходимо иметь, прежде чем вы сможете войти в отрасль, стремительно увеличивается. Растут ставки, масштабы и цена ошибок. Появляются сертификации, тренинги, стандарты, юридические процедуры. Мы спорим о том, являются ли инженеры-программисты на самом деле инженерами.
ПО - индустрия обучения
Сейчас никто не возьмёт недоучившегося студента в штат. Необходимые для входа в индустрию знания выросли, вы больше не можете научиться буквально всему на работе, как когда-то.
Но не похоже, что вы можете научиться всему и в вузе. Степень в области компьютерных наук обычно лучше готовит вас к жизни компьютерных исследователей, чем к жизни в качестве обычного инженера-программиста. Более практичным путём в индустрию может стать хороший учебный лагерь по кодированию с упором на решение проблем и изучение современного инструментария. В любом случае вы не столько узнаете, «как выполнять работу», сколько «узнаете достаточно основ, чтобы понимать и использовать инструменты, необходимые для изучения работы».
ПО — индустрия обучения. Вы не можете научиться быть инженером-программистом, читая книги. Вы можете учиться только делая… и делая, и ещё делая. Неважно, какое у вас образование, большая часть обучения происходит на работе… и никогда не заканчивается!
Требуется более 7 лет, чтобы выковать компетентного инженера-программиста (как в большинстве случаев называют, сеньора). Это много лет написания, проверки и развёртывания кода каждый день в команде вместе с более опытными инженерами.
Что значит быть «сеньором»?
Об этом есть целая серия постов на канале. Ищите по тэгу #КакСтатьСеньором
По поводу сроков есть очень много споров:
«7 лет?! Пфф, мне потребовалось 2 года!»
«Меня повысили до сеньора меньше, чем за 5 лет!»
Молодцы! Да, в 7 годах нет ничего волшебного. Но для того, чтобы стать опытным инженером, способным сплотить команду, требуются время и опыт. Более того, нужна практика.
Думаю, мы стали использовать слово «сеньор» как сокращение для инженеров, которые могут поставлять готовый чистый код и быть продуктивными, и кажется, что это огромная ошибка. Это подразумевает, что младшие инженеры менее продуктивны, что неверно. И это упускает из виду истинную природу работы по разработке ПО, в которой написание кода является лишь небольшой частью.
Быть сеньором — это не способность писать код. Это гораздо больше связано с вашей способностью понимать, поддерживать, объяснять и управлять большим объёмом ПО в производстве с течением времени, а также способностью переводить бизнес-потребности в техническую реализацию. Большая часть работы связана с созданием и курированием этих больших, сложных социотехнических систем, а код — это всего лишь одно из представлений этих систем. Это значит, что вы научились, прежде всего, учиться и учить; как держать эти модели в голове и рассуждать о них, и как поддерживать, расширять и эксплуатировать эти системы с течением времени. Это значит, что у вас есть здравый смысл и инстинкты, которым вы можете доверять.
Что подводит нас к вопросу об ИИ.
Продолжение следует…
Источник: https://stackoverflow.blog/2024/12/31/generative-ai-is-not-going-to-build-your-engineering-team-for-you
5👍20👎1
День 2166. #Оффтоп #AI
ИИ не Заменит Команду Инженеров. Продолжение
1. ПО - индустрия обучения
Нужно перестать каннибализировать наше будущее
Получить первую должность инженера очень сложно. Недостаточно окончить вуз по специальности. Сейчас написано множество статей о том, что начальные должности в различных отраслях заменяются ИИ. Любая работа, которая состоит из рутины, вроде преобразования документа из одного формата в другой, чтение и обобщение кучи текста и т.п., кажется довольно очевидно уязвимой. И это не так уж революционно, это просто часть бума автоматизации.
Однако в последнее время ряд руководителей и «лидеров мнений» в сфере технологий, похоже, убедили себя в том, что ИИ находится на грани замены всей работы, выполняемой джунами. Это говорит о глубоком непонимании того, чем на самом деле занимаются инженеры. Не нанимая и не обучая джунов, мы каннибализируем собственное будущее.
Писать код легко
Написание кода — самая лёгкая часть разработки ПО, и с каждым днём становится проще. Сложная часть — это эксплуатация, понимание, расширение и управление им на протяжении всего его жизненного цикла.
Джун начинает с того, что учится писать и отлаживать строки, функции и фрагменты кода. Затем - составлять системы из ПО и проводить их через волны изменений и трансформаций.
Социотехнические системы состоят из ПО, инструментов и людей; для их понимания требуется знакомство с взаимодействием между ПО, пользователями, производством, инфраструктурой и непрерывными изменениями с течением времени. Эти системы фантастически сложны и подвержены хаосу и непредсказуемому поведению. Если кто-то утверждает, что понимает систему, которую он разрабатывает и эксплуатирует, то либо система мала, либо (более вероятно) он недостаточно знает, чтобы знать, чего он не знает. Код прост, а системы сложны.
Текущая волна инструментов ИИ сделала многое, чтобы помочь нам быстро генерировать много кода. Простые части становятся ещё проще. Но она не сделала ничего, чтобы помочь в работе по управлению, пониманию или эксплуатации этого кода. Т.е. ИИ только усложнил сложную работу.
Сложно генерировать хороший код
У вас может возникнуть образ инженеров-программистов, весело создающих запросы к ChatGPT или использующих Copilot для генерации тонн кода, а затем отправляющих всё, что получается, в GitHub. Это не похоже на реальность.
Инструменты вроде Copilot больше похожи на причудливую функцию автодополнения или копирования-вставки результатов из Google «Мне повезёт». Эти инструменты лучше всего работают, когда уже есть аналогичный код, и вы хотите просто скопировать-вставить его с небольшими изменениями, или когда вы пишете тесты по шаблону.
Однако вы не можете доверять сгенерированному коду. Он всегда выглядит правдоподобно, но даже когда он как-то «работает», он редко соответствует вашим желаниям и потребностям. ИИ с радостью сгенерирует код, который не скомпилируется, придумает переменные, имена методов, вызовы функций; сгаллюцинирует поля, которых не существует. Код не будет следовать вашим практикам или соглашениям кодирования. Чем важнее, сложнее или значимее фрагмент кода, тем меньше вероятность того, что вы сгенерируете пригодный для использования артефакт с помощью ИИ.
Вы можете сэкономить время, не вводя код, но придётся пройтись по нему строка за строкой, исправляя их по ходу дела, прежде чем вы сможете отправить его в производство. Во многих случаях это займет столько же или даже больше времени, чем написание. Генерация кода, который может компилироваться, выполняться и проходить набор тестов, не так уж и сложна; сложная часть — это создание кодовой базы, на которую последующие поколения команд смогут полагаться и модифицировать в течение многих лет.
Продолжение следует…
Источник: https://stackoverflow.blog/2024/12/31/generative-ai-is-not-going-to-build-your-engineering-team-for-you
ИИ не Заменит Команду Инженеров. Продолжение
1. ПО - индустрия обучения
Нужно перестать каннибализировать наше будущее
Получить первую должность инженера очень сложно. Недостаточно окончить вуз по специальности. Сейчас написано множество статей о том, что начальные должности в различных отраслях заменяются ИИ. Любая работа, которая состоит из рутины, вроде преобразования документа из одного формата в другой, чтение и обобщение кучи текста и т.п., кажется довольно очевидно уязвимой. И это не так уж революционно, это просто часть бума автоматизации.
Однако в последнее время ряд руководителей и «лидеров мнений» в сфере технологий, похоже, убедили себя в том, что ИИ находится на грани замены всей работы, выполняемой джунами. Это говорит о глубоком непонимании того, чем на самом деле занимаются инженеры. Не нанимая и не обучая джунов, мы каннибализируем собственное будущее.
Писать код легко
Написание кода — самая лёгкая часть разработки ПО, и с каждым днём становится проще. Сложная часть — это эксплуатация, понимание, расширение и управление им на протяжении всего его жизненного цикла.
Джун начинает с того, что учится писать и отлаживать строки, функции и фрагменты кода. Затем - составлять системы из ПО и проводить их через волны изменений и трансформаций.
Социотехнические системы состоят из ПО, инструментов и людей; для их понимания требуется знакомство с взаимодействием между ПО, пользователями, производством, инфраструктурой и непрерывными изменениями с течением времени. Эти системы фантастически сложны и подвержены хаосу и непредсказуемому поведению. Если кто-то утверждает, что понимает систему, которую он разрабатывает и эксплуатирует, то либо система мала, либо (более вероятно) он недостаточно знает, чтобы знать, чего он не знает. Код прост, а системы сложны.
Текущая волна инструментов ИИ сделала многое, чтобы помочь нам быстро генерировать много кода. Простые части становятся ещё проще. Но она не сделала ничего, чтобы помочь в работе по управлению, пониманию или эксплуатации этого кода. Т.е. ИИ только усложнил сложную работу.
Сложно генерировать хороший код
У вас может возникнуть образ инженеров-программистов, весело создающих запросы к ChatGPT или использующих Copilot для генерации тонн кода, а затем отправляющих всё, что получается, в GitHub. Это не похоже на реальность.
Инструменты вроде Copilot больше похожи на причудливую функцию автодополнения или копирования-вставки результатов из Google «Мне повезёт». Эти инструменты лучше всего работают, когда уже есть аналогичный код, и вы хотите просто скопировать-вставить его с небольшими изменениями, или когда вы пишете тесты по шаблону.
Однако вы не можете доверять сгенерированному коду. Он всегда выглядит правдоподобно, но даже когда он как-то «работает», он редко соответствует вашим желаниям и потребностям. ИИ с радостью сгенерирует код, который не скомпилируется, придумает переменные, имена методов, вызовы функций; сгаллюцинирует поля, которых не существует. Код не будет следовать вашим практикам или соглашениям кодирования. Чем важнее, сложнее или значимее фрагмент кода, тем меньше вероятность того, что вы сгенерируете пригодный для использования артефакт с помощью ИИ.
Вы можете сэкономить время, не вводя код, но придётся пройтись по нему строка за строкой, исправляя их по ходу дела, прежде чем вы сможете отправить его в производство. Во многих случаях это займет столько же или даже больше времени, чем написание. Генерация кода, который может компилироваться, выполняться и проходить набор тестов, не так уж и сложна; сложная часть — это создание кодовой базы, на которую последующие поколения команд смогут полагаться и модифицировать в течение многих лет.
Продолжение следует…
Источник: https://stackoverflow.blog/2024/12/31/generative-ai-is-not-going-to-build-your-engineering-team-for-you
5👍8
День 2167. #Оффтоп #AI
ИИ не Заменит Команду Инженеров. Продолжение
1. ПО – индустрия обучения
2. Просто писать код, сложно писать хороший код
Как инженеры на самом деле используют ИИ
Вы можете сгенерировать много кода очень быстро, но вы не можете доверять тому, что получится. Однако есть некоторые примеры использования, в которых ИИ неизменно блистает:
1. Часто проще попросить ChatGPT сгенерировать пример кода с использованием незнакомых API, чем читать документацию по API.
2. Создание кода, который раздражает или утомителен для написания, но при этом имеет узкую область действия и легко объясняется. Чем более предсказуем сценарий, тем лучше эти инструменты пишут код за вас.
3. Написание небольших функций, чтобы делать что-то на незнакомых языках или в незнакомых сценариях. Если у вас есть фрагмент кода Python и вы хотите то же самое на Java, но вы не знаете Java, ИИ поможет.
Но, помните: вероятность того, что результат полностью выдуман, составляет 50/50. Всегда придется предполагать, что результаты неверны, пока вы не проверите их вручную.
ИИ немного похож на джуна
ИИ похож на младшего инженера в том, что вы не можете запустить его код в производство. Вы несёте за него ответственность — юридически, этически и практически. Всё равно нужно потратить время, чтобы понять код, протестировать, инструментировать, модифицировать стилистически и тематически, чтобы он соответствовал остальной части кодовой базы, и убедиться, что коллеги также могут его понимать и поддерживать.
Аналогия хорошая, только если ваш код одноразовый и самодостаточный, т.е. не предназначен для интеграции в более крупный объём работы или для выживания и чтения или изменения другими.
И есть такие уголки отрасли, где большая часть — одноразовый код. Есть компании, которые выпускают десятки одноразовых приложений в год, каждое из которых написано для конкретного запуска или маркетингового мероприятия, а затем выбрасывается. Но это не относится к большинству ПО.
Но ИИ не член вашей команды
ИИ похож на джуна, но во всех других отношениях аналогия не работает. В автоматической генерации кода нет обратной связи. Предоставление код-ревью младшему инженеру не похоже на редактирование сгенерированного кода. Это возможность передать уроки, которые вы усвоили в своей карьере. Да и само оформление обратной связи заставляет вас продумывать проблему более строго и помогает вам глубже понять материал. Время, которое вы вкладываете в помощь младшему инженеру в повышении уровня, может окупиться удивительно быстро.
Мы недооцениваем стоимость найма сеньоров и переоцениваем стоимость найма джунов
Люди часто думают, что как только вы нанимаете сеньора, вы можете поместить его в команду, и он сразу же станет продуктивным. Тогда как джун снизит производительность команды навсегда. Ни то, ни другое неверно. Большая часть работы, которую приходится выполнять большинству команд, не так уж сложна, если её разбить на составные части.
Существует множество способов, как человек может внести вклад в общую скорость команды. И множество способов, как он может высасывать энергию из команды или добавлять трения и помехи всем вокруг. Это не всегда коррелирует с уровнем человека.
Каждому нанятому инженеру требуется время на разгон, прежде чем он сможет внести свой вклад, независимо от его уровня. Сколько времени? Зависит от чистоты и организованности кодовой базы, прошлого опыта работы с вашими инструментами и технологиями и многого другого, но, скорее всего, 6-9 месяцев. Да, разгон будет дольше для джуна, и это потребует больше инвестиций от команды. Но не критически больше. Джун должен начать приносить пользу в течение примерно того же периода времени, и джуны развиваются гораздо быстрее, чем более опытные работники.
Продолжение следует…
Источник: https://stackoverflow.blog/2024/12/31/generative-ai-is-not-going-to-build-your-engineering-team-for-you
ИИ не Заменит Команду Инженеров. Продолжение
1. ПО – индустрия обучения
2. Просто писать код, сложно писать хороший код
Как инженеры на самом деле используют ИИ
Вы можете сгенерировать много кода очень быстро, но вы не можете доверять тому, что получится. Однако есть некоторые примеры использования, в которых ИИ неизменно блистает:
1. Часто проще попросить ChatGPT сгенерировать пример кода с использованием незнакомых API, чем читать документацию по API.
2. Создание кода, который раздражает или утомителен для написания, но при этом имеет узкую область действия и легко объясняется. Чем более предсказуем сценарий, тем лучше эти инструменты пишут код за вас.
3. Написание небольших функций, чтобы делать что-то на незнакомых языках или в незнакомых сценариях. Если у вас есть фрагмент кода Python и вы хотите то же самое на Java, но вы не знаете Java, ИИ поможет.
Но, помните: вероятность того, что результат полностью выдуман, составляет 50/50. Всегда придется предполагать, что результаты неверны, пока вы не проверите их вручную.
ИИ немного похож на джуна
ИИ похож на младшего инженера в том, что вы не можете запустить его код в производство. Вы несёте за него ответственность — юридически, этически и практически. Всё равно нужно потратить время, чтобы понять код, протестировать, инструментировать, модифицировать стилистически и тематически, чтобы он соответствовал остальной части кодовой базы, и убедиться, что коллеги также могут его понимать и поддерживать.
Аналогия хорошая, только если ваш код одноразовый и самодостаточный, т.е. не предназначен для интеграции в более крупный объём работы или для выживания и чтения или изменения другими.
И есть такие уголки отрасли, где большая часть — одноразовый код. Есть компании, которые выпускают десятки одноразовых приложений в год, каждое из которых написано для конкретного запуска или маркетингового мероприятия, а затем выбрасывается. Но это не относится к большинству ПО.
Но ИИ не член вашей команды
ИИ похож на джуна, но во всех других отношениях аналогия не работает. В автоматической генерации кода нет обратной связи. Предоставление код-ревью младшему инженеру не похоже на редактирование сгенерированного кода. Это возможность передать уроки, которые вы усвоили в своей карьере. Да и само оформление обратной связи заставляет вас продумывать проблему более строго и помогает вам глубже понять материал. Время, которое вы вкладываете в помощь младшему инженеру в повышении уровня, может окупиться удивительно быстро.
Мы недооцениваем стоимость найма сеньоров и переоцениваем стоимость найма джунов
Люди часто думают, что как только вы нанимаете сеньора, вы можете поместить его в команду, и он сразу же станет продуктивным. Тогда как джун снизит производительность команды навсегда. Ни то, ни другое неверно. Большая часть работы, которую приходится выполнять большинству команд, не так уж сложна, если её разбить на составные части.
Существует множество способов, как человек может внести вклад в общую скорость команды. И множество способов, как он может высасывать энергию из команды или добавлять трения и помехи всем вокруг. Это не всегда коррелирует с уровнем человека.
Каждому нанятому инженеру требуется время на разгон, прежде чем он сможет внести свой вклад, независимо от его уровня. Сколько времени? Зависит от чистоты и организованности кодовой базы, прошлого опыта работы с вашими инструментами и технологиями и многого другого, но, скорее всего, 6-9 месяцев. Да, разгон будет дольше для джуна, и это потребует больше инвестиций от команды. Но не критически больше. Джун должен начать приносить пользу в течение примерно того же периода времени, и джуны развиваются гораздо быстрее, чем более опытные работники.
Продолжение следует…
Источник: https://stackoverflow.blog/2024/12/31/generative-ai-is-not-going-to-build-your-engineering-team-for-you
👍16