home.social

#developer_experience — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #developer_experience, aggregated by home.social.

fetched live
  1. Платформа плагинов в Трекере, или Как мы пустили сторонний код в продукт с 600 000 пользователей

    За последние годы аудитория Трекера выросла до 600 000 пользователей — пропорционально выросло и количество запросов на новые функции. Бэклог разросся до уровня ответов «внесли в список, но обещать ничего не можем». При этом рынок трекеров очень конкурентный, и останавливать развитие core‑продукта ради разбора кастомных запросов нельзя. В какой‑то момент мы пришли к выводу: сколько бы ни увеличивали команду разработки, запросов от пользователей всегда будет больше. Это не проблема планирования, а скорее структурное свойство зрелого продукта с большой аудиторией. Единственный способ масштабироваться в этой точке — не делать всё своими руками. Сегодня мы запустили платформу плагинов — отдельный механизм, который позволяет без навыков кодинга расширять Трекер собственными модулями под специфические задачи. Привет, Хабр! Меня зовут Женя Успенский, я руковожу разработкой фронтенда в Яндекс Трекере и отвечаю за архитектуру платформы плагинов. Со статьёй мне помогал мой коллега Дима Куприк, который отвечает за весь проект целиком. Он расскажет, почему мы вообще решили дать возможность пользователям самим модифицировать Трекер, как плагины помогают решать специфические задачи команд и какие сценарии мы автоматизировали первыми. В технической части я подробно разберу, какие задачи перед нами стояли и как мы их решили: изоляция стороннего кода, разрешения, proxy для внешних API и всё, что позволяет пускать чужой код в B2B‑продукт и спать спокойно.

    habr.com/ru/companies/yandex/a

    #яндекс #трекер #плагины #яндекс_трекер #typescript #developer_experience #yandex_tracker

  2. Почему всё, что мы должны были делать для живых людей, мы в итоге делаем для неживого интеллекта

    Контекст для человеков всегда был важен. На онбординге всегда ломалось много мотивации и employee experience; над передачей знаний и снижением bus factor трудились и тимлиды, и HR-менеджеры, и даже выделенные KM-специалисты. Всё это делалось для людей, и делалось с весьма переменным успехом. Для ИИ-агентов мы делаем ровно то же самое, но с повышенным рвением, скоростью и отдачей. Вливаем максимальный контекст, пишем подробнейший промпт. Строим волты и описываем весь мир в понятном для агента языковом ключе. Некоторые уже всерьёз думают про developer experience, но для агентов. Почему на них хватило того, чего никогда не хватало на людей? Самый напрашивающийся ответ: агент дороже, поэтому его берегут. Я довольно долго на нём стояла и теперь думаю, что он неверен, причём дважды.

    habr.com/ru/articles/1063214/

    #developer_experience #developer_environment #база_знаний #knowledge_management

  3. Дизайнеры не должны договариваться о том, как оформлять макеты. Как мы сформировали дизайн-стандарт

    Привет! Хочу рассказать вам о том, как мы применили продуктовый подход к исследованию опыта разработчиков при работе с Figma, чтобы создать единый стандарт оформления макетов в компании. На Хабре уже есть несколько отличных разборов того, как разные команды наводят порядок в Figma: аннотации, стрелки, сценарии, раскладки макетов и так далее. Я видел материалы Ozon Tech , t2 , Иннотех — это классные справочники правил, можно брать и пользоваться. Но, когда в 2024 году я взялся за задачу подготовки стандарта для нашей компании, то столкнулся с вопросами, о которых нигде ничего не нашел. Как разработать единый подход? Что считать правильным и почему? Как упаковать эту идею и «продать» остальным членам команды, а главное: что делать дальше? В этой статье поделюсь нашим методом поиска ответов на эти вопросы. Избавиться от страха и ненависти

    habr.com/ru/companies/cloud_ru

    #uxдизайн #uxисследования #figma #стандартизация #design_ops #продуктовый_дизайн #developer_experience #внутренние_процессы #продуктовый_подход

  4. Реальный DX: как измерить опыт разработчика и не соврать самому себе

    В прошлый раз я писал про то, что сообщение об ошибке читает уставший человек в два часа ночи. Там была одна простая мысль: ошибка должна сказать, что случилось, почему и что делать дальше. Переписали голое invalid_request в человеческий ответ, и стало лучше. Вот только «стало лучше» — это ощущение. А ощущение нельзя положить в роадмап (или защитить перед руководством), чтобы сравнить через квартал. Улучшить то, что ты не измеряешь, нельзя: можно только верить, что улучшил. Давайте сегодня разберёмся, как DX из набора интуиций превратился в измеримую дисциплину: с исследованиями, метриками и цифрами. И как этим пользоваться, не скатываясь в дашборд ради дашборда.

    habr.com/ru/articles/1048262/

    #dx #api #developer_experience #опыт_разработчика #devex #space #dora #DX_core_4 #ttfhw #когнитивная_нагрузка

  5. Ваше сообщение об ошибке читает уставший человек в два часа ночи

    Два часа ночи, у разработчика горит релиз, он подключает ваш API — и получает в ответ голое «invalid_request». Что не так, почему, что делать — ни слова. Сорок минут гаданий и злое письмо в поддержку. Разбираем, как сделать опыт разработчика (DX) человеческим: как переписать ошибки по стандарту RFC 9457, но для живого человека; почему время до первого успешного вызова — главная метрика онбординга; и отчего предсказуемый, «скучный» API — это комплимент. С готовым шаблоном, который можно прикрутить к себе сегодня.

    habr.com/ru/articles/1042850/

    #api #dx #developer_experience #rest #обработка_ошибок #error_handling #RFC9457 #problem_details #ttfhw #онбординг_разработчиков

  6. 🎉✨ Python's latest shiny toy, 'uv', promises to revolutionize package management by reducing developers' tools to a solitary binary. But surprise, surprise! Once the honeymoon phase ends, you're stuck in CLI hell, desperately trying to untangle the mess it leaves behind. 😂🔧
    loopwerk.io/articles/2026/uv-u #Python #uv #package_management #CLI_tools #developer_experience #tech_news #HackerNews #ngated

  7. 🎉✨ Python's latest shiny toy, 'uv', promises to revolutionize package management by reducing developers' tools to a solitary binary. But surprise, surprise! Once the honeymoon phase ends, you're stuck in CLI hell, desperately trying to untangle the mess it leaves behind. 😂🔧
    loopwerk.io/articles/2026/uv-u #Python #uv #package_management #CLI_tools #developer_experience #tech_news #HackerNews #ngated

  8. Опыт разработчика как экономика внимания

    Привет, Хабр! Почему инженеры хотят делать новое, а неделя уходит на сопровождение, алерты и переключение контекстов? Поводом для этой статьи стали два материала, которые неожиданно сошлись в одной точке: доклад Романа Елизарова про опыт разработчика и отчет Chainguard Engineering Reality Report 2026. Мы сопоставили взгляд сильного практика и международные данные, чтобы понять, куда на самом деле утекает внимание инженерных команд и почему DX сегодня — это уже не про удобство, а про экономику внимания.

    habr.com/ru/companies/axiomjdk

    #Axiom_JDK #axiomjdk #chainguard #java #developer_experience #dx #роман_елизаров #митап #java_rock_star_meetup

  9. ИИ создан не для замены разработчиков, а для ускорения их выгорания

    Мы в Лаборатории прикладной промптологии и производственной тревожности НИИ ИИ второй год следим за тем, как разработчики синхронизируются с генеративными моделями. Уже сформировался новый тип производственного взаимодействия. Это бесконечная серия коротких переговоров, в ходе которых одна сторона просит поправить одну строку, а вторая через 14 секунд возвращается с полностью переписанным кодом. Как будто во всех проектах появился ещё один разработчик, который постоянно косячит, выдаёт старый код за новый, до последнего спорит даже с техлидами, не признаёт очевидных ошибок, нуждается в постоянном ревью и при этом не может быть уволен. Потому что за ним, как нам регулярно объясняют, будущее отрасли, а значит, со временем он «вырастет» и повысит качество кода и точность ответов. Поэтому нам не остаётся ничего другого, кроме как настраивать эту синхронизацию.

    habr.com/ru/companies/X5Tech/a

    #1_апреля #генеративный_ии #aiассистент #генерация_кода #разработка_по #промпты #ревью_кода #юмор_в_it #генерация_кода_llm #developer_experience

  10. Как писать документацию, которую разработчики будут читать

    Большинство документаций к продуктам для разработчиков — плохие. Не потому что авторы не старались, а потому что документацию писал инженер, который знает продукт насквозь, и ему «всё очевидно». А человеку, который видит продукт впервые, — ничего не очевидно.

    habr.com/ru/companies/otus/art

    #DEVREL #документация_для_разработчиков #техническая_документация #справочник_API #developer_experience

  11. Zod: строгая валидация и удобная типизация. Опыт перехода

    Привет, Хабр! Меня зовут Сергей, я фронтенд-инженер в Банки.ру. В этой статье расскажу, как Zod помог нам перестать писать валидацию на уровне полей, подружился с React Hook Form и стал единым источником правды о структуре данных. К Zod мы пришли не сразу. Долгое время типы и валидация у нас жили в разных слоях приложения: TypeScript определял структуру данных во время разработки, а отдельные функции или библиотеки (вроде Yup) проверяли входящие значения в рантайме. Это классическая проблема: дублирование логики и рассинхрон. Типы в interface поменялись, а валидация осталась прежней (или наоборот). Мы пробовали Yup, но он казался громоздким в связке с TS: типы приходилось выводить вручную или мириться с тем, что схемы выглядят непрозрачно. В какой-то момент стало непонятно: зачем тащить отдельную библиотеку, если проще написать if (typeof x === 'string') ? С переходом на Zod всё стало значительно проще: одна схема одновременно является и валидатором, и источником типа данных.

    habr.com/ru/companies/banki/ar

    #zod #typescript #валидация_данных #runtime_валидация #react_hook_form #типизация_данных #frontend_разработка #валидация_форм #developer_experience #валидация

  12. AI без интернета (офлайн) на своем компьютере

    Зачем это обывателю? Кейсов на самом деле не мало, как минимум это бесплатно и дает возможность запускать AI без облака, чтобы ничего не отправлялось в интернет (приватность, скорость), ну и на случай если упадет интернет как например у нас было в Испании когда все электричество пропало, хорошо бы иметь умного ИИ с которым можно будет пообщаться) Еще можно использовать как офлайн переводчик или объяснялку без интернета, помощника по учебе и изучения чего либо.

    habr.com/ru/articles/981290/

    #Сезон_ИИ_в_разработке #программирование #искусственный_интеллект #ai #developer_experience #software_development #ии #ии_чатбот #ииагенты #ииассистент

  13. Что ждет участников Ural Digital Weekend 2025? Раскрываем детали

    Привет! На связи команда Spectr ! 1-2 августа в Перми мы проведем уже традиционную конференцию про разработку и управление в IT-компаниях — Ural Digital Weekend 2025. Сейчас уже готова программа всех секций. Рассказываем, кто выступит в 2025 году. Узнать подробности о программе

    habr.com/ru/articles/919802/

    #backend #мероприятия #разработка #frontend #развитие_карьеры #управление_разработкой #управление_проектами #frontend #devops #developer_experience

  14. Поговорим о DevSecOps и культурной трансформации в мире разработки

    Киберугрозы растут, уязвимости в коде дороже, чем когда-либо, а традиционные подходы к безопасности терпят крах. Почему компании теряют миллионы, игнорируя безопасность до финального этапа разработки? Как DevSecOps меняет правила игры, превращая защиту данных в часть повседневной работы разработчиков? В этой статье вы узнаете: Почему «последняя миля» в тестировании безопасности — это провал : статистика OWASP и NIST о том, как 97% приложений содержат уязвимости, а исправление ошибок после релиза обходится в 6 раз дороже. Как DevSecOps убирает барьеры между командами : интеграция безопасности в CI/CD, автоматизация проверок и сдвиг «влево» (Shift Left) — от теории к реальным кейсам Microsoft, Netflix и Capital One. Почему успех DevSecOps зависит не от инструментов, а от культуры : как руководство может создать среду, где безопасность становится общей ответственностью, а не «чужой заботой». Вызовы внедрения и пути их преодоления : от сопротивления изменениям до обучения разработчиков — шаги, которые сделают вашу команду готовой к цифровым угрозам будущего. Статья подойдёт для разработчиков, руководителей IT-команд, специалистов по кибербезопасности и всем, кто хочет превратить уязвимости в прошлое.

    habr.com/ru/articles/918350/

    #devops #devsecops #development #developer #developer_experience #tools_programming #security

  15. Чистый код — красивая архитектура. А работает ли это?

    Вы пишете код не для компилятора — он съест любую абракадабру, если синтаксис верен. Вы пишете для людей, для того парня из соседнего отдела, который будет разбирать ваш код через полгода. Для себя, когда забудете, о чём думали в момент написания. Для тимлида, у которого нет времени расшифровывать ваши «фичи», замаскированные под техдолг. Грязный код — это про непонятные переменные, запутанные модули и решения «на скорую руку». Вас ждёт после такого потеря во времени и в лучшем случае косые взгляды коллег. К сожалению, непонятный код часто пишут не только из-за спешки, но и из-за неопытности и чрезмерного энтузиазма тех, кто хочет всё переделать. Видели те горящие глаза джунов-зумеров при приеме на работу, думаю в них можно прочитать: «ваш код кривой, пустите меня в прод и сделаю все как надо..» и начинает строить собственные «идеальные» архитектуры. Так что эстетика кода — это не пунктик перфекциониста, это прагматизм, и код нужно писать так, чтобы после него следующий разработчик ставил вам свечку в мыслях. Давайте разберём, как превратить кошмар в конфетку — детали внутри.

    habr.com/ru/companies/ruvds/ar

    #программирование #код #дизайн_кода #архитектура_ПО #code_style #developer_experience #ruvds_статьи

  16. Почему JS (и TS) это плохой язык

    Я знаю, что на эту тему уже было сказано много, но настал мой черед. На JS я пишу больше 10 лет, так что терпел я достаточно. Мы называем это “джаваскрипт”, но под капотом скрываются три разные сущности: EcmaScript, среда исполнения и экосистема. Иногда о них стоит говорить отдельно, но сегодня я хочу обсудить всё сразу и объяснить, почему джаваскрипт — это плохой язык. Не в смысле “не работает”, а в смысле “заставляет страдать”.

    habr.com/ru/articles/905480/

    #JS #JavaScript #TypeScript #TS #Go #Backend #Frontend #React #DX #Developer_Experience

  17. Meta Storm Plugin – еще один плагин для PHPStorm

    Логично ведь, что если ты пишешь функцию, которая должна принимать значение из набора, то нужно показать этот набор. А может еще и свалидировать ошибку. А еще и провалиться внутрь по CTRL+Click. А еще и обратный референс найти. Ну и рефакторинг общий сделать, раз уж разошлись. Ребята делающие плагины под свои технологии молодцы, но как мне сделать то же самое с моим MyClass::readFile('users.csv') ? А если нужно подсказать свойства текущей модели $model->getAttributeLabel('id') ? А если я хочу сделать подсказки в query builder? Да и вообще, зачем мне еще один плагин, PHPStorm ведь и без него справлялся годами? Узнать подробнее

    habr.com/ru/articles/868898/

    #php #intellij #plugin #intellij_platform #developer_experience #phpstorm

  18. Наши стандарты DX

    Имеется некий опыт работы в ключе "Пиши столько кода, чтоб потом писать его меньше" - и, как оказалось, при соблюдении некоторых правил, это работает. Здесь автор пробует формализовать тезисы своего подхода к успешному DX в духе продуктовых Enterprise, исходя из личного опыта. Некоторые из них выглядят как прописные истины, но, зачастую, придя на проект, ловишь себя на мысли "Судя по результату, здесь не было таких правил"...

    habr.com/ru/articles/843396/

    #enterprise #frontend #developer_experience

  19. .NET Aspire — империя дотнета наносит ответный удар

    Когда я первый раз услышал про .NET Aspire , я подумал что это какая-то очередная лажа от Майкрософта, про которую все забудут через неделю. Особенно, учитывая какую дичь часто завозят в шарп (например те же ужасно спроектированные Primary Constructor'ы про которые я писал, или вот прикол-пропозал от самого Тоуба ). Так что ожидания у меня, честно говоря, были ниже нуля. Но попробовав его лично, я был, честно говоря, шокирован. Трепещите, жависты!! Трепещите гошники! Трещепищите питонисты - такого вы еще точно не видели. Я даже представить не мог, что DevEx можно сделать настолько офигительным. Узнать про Aspire без смс и регистрации

    habr.com/ru/articles/818907/

    #dotnet #aspire #csharp #devtools #developer_experience #docker #infrastructure

  20. Личный опыт: переход с Redux на Effector. И при чем тут DX

    Frontend-разработка очень богата различными инструментами. Новые фреймворки и библиотеки выходят чуть ли не каждый день и, к сожалению, не все из них одинаково полезны или могут сделать ваш продукт лучше. Кроме того, они различаются по степени удобства именно для разработчика. Есть такое понятие DX – Developer eXperience – по аналогии с UX. Это то, насколько разработчику удобно, интуитивно понятно пользоваться определенным сервисом. Меня зовут Аня, я frontend-специалист в компании SimbirSoft с опытом в разработке более трех лет. Уже успела поработать со многими инструментами, участвовала в проекте, где переносили огромное приложение на новые библиотеки, в том числе заменяли Redux на Effector. В этой статье хочу поделиться своими мыслями об этих стейтменеджерах с точки зрения DX. Да, их сравнивали много раз, но мой акцент будет на том, как писать код на Effector для привычных кейсов в Redux. Подчеркну, DX — это не про рациональные аргументы, а про комфорт, фэншуй и тому подобные вещи (вы же понимаете, о чем я, правда?…). Забегая вперед, хочу сказать, что Effector мне понравился. И прежде всего своей простотой — да-да, один из наших любимых принципов KISS ). И может быть, что я по поводу Effector испытываю ещё какую-то национальную гордость, потому что это разработка ребят из России.

    habr.com/ru/companies/simbirso

    #frontend #effector #redux #dx #developer_experience

  21. Ещё одна статья про карьеру: 15 убеждений, которые превратились в инсайты

    Сознание начинающего разработчика отличается от сознания его опытного и преисполненного коллеги. Даже у меня были убеждения, которые изменились с приростом опыта. Всего их было 15. Я придерживаюсь их всех и они работают (кроме последнего, с ним прям беда). Я Екатерина Попкова, Java/Kotlin-разработчик в “Альфа-Банке”, готова вам об этом рассказать.

    habr.com/ru/companies/alfa/art

    #software_development #it_career #teamlead #softskills #developer_experience #начало_карьеры #карьера #семья #отдых #выгорание