Никита Арипов | 1С, DevExp

Ссылки из выступления про ИИ 1. Код-ревью 1С - Тренажер по поиску ошибок в коде 2. AI dev в Яндексе: стали ли мы продуктивнее за год? 3. Как Яндекс, Avito, Ozon ИИ-агентов используют для разработки 4. ИИ замедляет опытных разработчиков 5. Миф о продуктивности генеративного ИИ 6. Падения вайбкондинга (агрегатор) 7. Больше 40% проектов с агенстким ИИ отменят к 2027 году 8. 95% пилотов с использование ИИ проваливаются 9. ИИ слишком рисковый для страхования 10. Эпоха LLM трещит по швам: со-основатель OpenAI и глава ИИ в *Meta объяснили, что будет дальше 11. ЧатГПТ делает нас глупее? 12. Врачи стали меньше определять рак после использования ИИ 13. Помощь ИИ снижает настойчивость и ухудшает самостоятельные результаты 14. Тяжелая правда о программировании с использованием ИИ Бонус: 15. Итоги внедрения ИИ в бизнесе 2025 16. ИИ уничтожает продуктивность 17. Microsoft назвала 40 профессий, которые вскоре могут быть уничтожены ИИ Ссылки на работы, которые использовались в презентации. В основном они на английском, но нейросеть поможет вам перевести :)

Преимущества и недостатки работы в платформенной команде Читаю книгу Гергели Орош - Разработчик ПО. И внезапно встретил описание платформенных команд разработки и того, чем они отличаются от продуктовых команд, например, разработчиков конфигураций. С удовольствием пересказываю. Преимущества платформенных команд: - Техническая сложность Они решают самые сложные технические задачи. Нужно учитывать масштабирование, разные среды выполнения и много других факторов - Широкое влияние Работа платформенной команды не ограничивается одним продуктом. Она оказывает существенное, хоть и косвенное, влияние на все продукты, использующие платформу - Больше свободы для разработчиков В таких командах часто нет продакт-менеджеров. Поэтому программисты могут сами влиять на процессы, заниматься техническим долгом и внедрять новые технологические идеи - Меньше давление в повседневной работе Платформенные команды обычно дальше от конечных пользователей, поэтому на них меньше давят сроки выпуска новых фич. Это позволяет больше думать о долгосрочных решениях и качестве архитектуры - Уровень сотрудников В платформенных командах часто работают разработчики уровня сеньор и выше, потому что такие задачи требуют большого опыта Недостатки работы в платформенной команде: - Сложнее оценить влияние своей работы на дела компании Продуктовая команда может легко показать результат своей работы. Например, рост дохода или приток новых пользователей благодаря новой функции. Платформенным командам сложнее связать свою работу с понятными бизнес-метриками - Часто считаются центрами затрат Из-за того, что платформенным командам сложнее показать прямую пользу для бизнеса, их чаще воспринимают как центр затрат. Поэтому им бывает труднее обосновать расширение команды, а при сокращении расходов такие команды могут пострадать сильнее продуктовых - Отдалены от пользователей Платформенные команды часто находятся далеко от конечных пользователей продукта. Из-за этого можно потерять понимание реальных потребностей пользователей, начать неверно расставлять приоритеты и чаще конфликтовать с продуктовыми командами

День рождения Сегодня у меня день рождения - 38 лет 🎂 Спасибо всем, кто поздравил и написал тёплые слова - это правда очень приятно ❤️ 🎵 Cаундтрек дня: 2rbina 2rista - Самый лучший парень Если вдруг захочется сделать мне приятное чуть более материально — вот ссылка на boosty Но это вообще по желанию, без ожиданий 🙏

Эволюция доверия Делюсь потрясающей игрой-иллюстрацией об эволюции или кризисе доверия - https://notdotteam.github.io/trust/ Она займет минут 30, но очень рекомендую ее посмотреть. Можно даже с телефона. Игра в ненавязчивой форме рассказывает и иллюстрирует стоит или не стоит доверять людям в долгосрочной перспективе. Единственное, что там придется относительно много читать. Для самых нетерпеливых: Доверять - выгодно, прощать выгодно один раз

📣 Приглашаем на вебинар «Итоги исследования пользовательского опыта работы с 1С:EDT»! 📅 26 мая в 19:00 (время московское) 💡 В программе вебинара мы разберём: Результаты исследования: 🔸 Что пользователи думают о 1С:EDT 🔸 Наиболее востребованный функционал 🔸 Основные сложности в работе Планы развития: 🔸 Приоритетные направления доработки 🔸 Динамика результатов ➡️ Встречаемся здесь: https://1c.vkurse.ru/id/465954352 ✅ Присоединяйтесь — будет полезно! Ответим на ваши вопросы в прямом эфире!

Какая твоя самая важная задача? Помню, на испытательном сроке в 1С этот вопрос мне часто задавал руководитель: «Какая у тебя сейчас самая важная задача?» Этот вопрос меня пугал до жути. Сразу начинаешь думать, а вдруг я что-то делаю не то? Вдруг трачу время неправильно? А задач действительно было много, и все вокруг казалось непонятным. Подзадачи, код-ревью, письма, на которые нужно отвлекаться, встречи, изучение подходов и стандартов… Список можно продолжать бесконечно. Но этот вопрос сразу как-то отметал все лишнее, и ты фокусировался на действительно важном. Поэтому я очень благодарен руководителю за такие своевременные уточнения. С тех пор я и сам задаю себе этот вопрос, когда чувствую себя перегруженным и понимаю, что даже работая вечерами и ночами, задач меньше не становится. Попробуйте и вы! Спросите себя: «А какая моя самая важная задача сейчас?» Нет, правда, подумайте: если бы на этой неделе можно было выполнить только одну задачу, какую бы вы выбрали? Ответьте себе на этот вопрос. Так вы поймете, какая задача является вашим приоритетом номер один. Сфокусируйтесь на ней и выполните ее к дедлайну.

🎉 Каналу — 2 года! Очень рад каждого здесь видеть! Честно, не ожидал, что из небольшого эксперимента это превратится в такой крутой проект. В который на протяжении 730 дней стараюсь добавлять что-то новое и интересное. Но на самом деле это не мой праздник, а ваш! Потому что если бы никто не читал мои посты, никто не ставил лайки и не комментировал, то это все скорее всего бы уже закончилось. А так, ВЫ настоящие герои этого канала! Благодаря вам и каналу познакомился с небывало интереснейшими людьми, осмелился на новые проекты и вызовы. Это мотивирует двигаться дальше и вперед. Спасибо вам! С днем рождения нас! 🎵 Cаундтрек дня: Заточка - С горы Если хотите поддержать развитие канала материально - вот ссылка на boosty. Но это вообще по желанию, без ожиданий 🙏

Проектирование интерфейса При разработке 1С:Бухгалтерии мы очень внимательно относимся к проектированию интерфейса. Продумываем его еще до того, как написана первая строчка кода, потому что важно заранее понять как все будет выглядеть для пользователя. Инструментов для проектирования много - как платных, так и бесплатных: Figma, UXPin, Penpot, Mockups или MakerStudio Мы исторически используем Mockplus. В нем можно быстро собрать форму из готовых элементов и описать простую логику. Например, нажали на кнопку Создать - открылась новая форма, нажали на кнопку Закрыть - форма закрылась. Пример такого интерфейса на картинке. Чем такой подход полезен: 1. Ранее выявление проблем. Можно заметить неудобные или непонятные места в логике или навигации еще до того, как написан код 2. Снижение стоимости изменений. Исправить макет обычно дешевле и быстрее, чем переделывать готовую реализацию 3. Быстрая проверка идей. Можно сравнить несколько вариантов интерфейса, выбрать лучший или объединить удачные решения в одно 4. Прояснение требований. Прототип делает идею наглядной, поэтому команде и заказчику проще договориться о том, что именно нужно реализовывать 5. Его не жалко выбросить. На создание такой формы вместе с логикой ушло пару минут

Видео: Один день из жизни разработчика 1С:Бухгалтерии Ссылка на VK Video Ссылка на YouTube Все видео с 1C:DevCon.6 доступны на developer.1c.ru

А у вас в команде проводятся встречи 1 на 1? Как оцениваете эту практику? Полезно? Вредно? Нужно? Не нужно?

Призы всем отправлены! Ура!

Когда проводить рефакторинг? Никогда, если: - Код не будет меняться. Например, в одноразовых обработках или устаревшем механизме - Изменение ничего нового не дадут. Рефакторинг ради рефакторинга бесполезен. Важно, чтобы появлялось новое качество. Например, масштабирование станет проще или снизится сложность будущего изменения Позже, если: - Предстоит много работы без мгновенного эффекта. Например, если даже все поменять сложность останется высокой - Рефакторинг окупится не сразу. Например, изменения в этом месте происходят редко и стоимость понимания кода не высока - Его можно делать постепенно и небольшими частями Сразу после, если: - Ожидание следующего удобного случая обойдется дороже. Например, одно и то же изменение нужно внести в несколько мест. Откладывание увеличит риск ошибок и стоимость следующих правок - Без этого вы не чувствуете, что работа завершена До, если: - Рефакторинг даст быстрый результат. Например, код станет понятнее или его будет проще менять - Вы точно понимаете, что и как нужно сделать.