Developer Experience: убираем ерунду из процесса разработки

Меня зовут Никита Арипов. Я расскажу о вещах, которые на первый взгляд кажутся пустяковыми. О ерунде.

«Ерунда» – это, кстати, вполне литературное слово. Этимология его до конца не установлена, но одна из версий гласит, что оно произошло от латинского слова gerundium – «герундий». В XVII веке студенты семинарий обязательно изучали латынь, и всё, что им было непонятно, они называли «герундием».

А что такое герундий в латыни? Это отглагольное существительное, обозначающее действие как процесс – «написание», «говорение» или «движение». И всё, что не укладывалось в голове, семинаристы называли герундием. Со временем буква «г» отпала: «герундий» стал «ерундием», а потом и вовсе превратился в привычное нам «ерунда».

В этой статье мы поговорим про «ерунду» в процессе разработки.

Этапы разработки и где может возникнуть «ерунда»

Я понимаю, что кто-то из разработчиков работает во франчайзи, кто-то как фрилансер, кто-то разрабатывает тиражные решения – вариантов много. Мы все разные, но у каждого из нас есть похожие этапы в работе. Где-то процессы сложнее, где-то проще, но в целом у любого разработчика путь примерно одинаков.

• Сначала берется задача из бэклога: из Jira, СППР, Bitrix или другой системы.

• Потом начинается разработка: пишем код, реализуем функциональность.

• Затем задачу нужно проверить – самостоятельно или передать на контроль коллеге/пользователю. В любом случае должен быть выходной контроль – проверка перед релизом.

• И только после этого задача отправляется в релиз, она выпускается и доходит до конечного пользователя.

На каждом из этих этапов можно столкнуться с ерундой – мелкими, но раздражающими и тормозящими моментами, которые снижают эффективность и отнимают время.

Давайте посмотрим какие трудности могут возникать на каждом этапе.

Проблемы на этапе получения задачи

Разработчик заходит в бэклог и видит там задачу: «Улучшить работу с файлами». Что он делает в первую очередь после того, как взял ее? Правильно – идет выяснять, а что конкретно нужно сделать. Потому что «улучшить работу с файлами» – это не задача. Он может открыть ее, сказать, что все и так хорошо, и пойти сдавать. Значит, придется уточнять.

В итоге задача переформулируется в «Добавить загрузку чеков в документ». Уже понятнее: ясно, что именно нужно реализовать.

Если бы изначально задача была так сформулирована, разработчику не пришлось бы тратить время на уточнения у аналитика, бухгалтера или того, кто ее поставил.

Если пойти дальше и уточнить сценарий по этой задаче, выяснится, что чеки нужно загружать не просто так, а для того, чтобы потом сформировать отчет для регулятора. Из этого становится понятно как проверять задачу, ведь помимо загрузки в документ мы еще должны подготовить отчет.

Теперь задача выглядит полноценно: разработчик может взять ее и сразу приступить к работе, не уточняя детали и не бегая по коллегам.

Такое описание задачи можно разбить на три ключевых маркера:

1. Что должно получиться в конце? – Добавить загрузку чеков в документ.

2. Зачем делаем? Каков пользовательский сценарий? В нашем случае – отчетность перед регулятором.

3. Для кого делаем? Если указан конкретный пользователь, то с ним проще договориться, быстрее согласовать и получить обратную связь.

Если задача сформулирована по этим критериям – это уже убирает «ерунду»: меньше вопросов, меньше задержек и выше эффективность.

Старайтесь избегать расплывчатых формулировок вроде «развитие», «улучшение» или «новая версия» – из них непонятно, что требуется. Первое, что приходится делать с такой задачей – идти и выяснять, а что вообще от тебя хотят.

Где и как разрабатывать: рутинные трудности

Мы взяли задачу, уточнили, что нужно сделать и начинаем разрабатывать.

Где разрабатывать? У нас есть несколько вариантов:

• Мы можем работать сразу в информационной базе – просто открываем конфигурацию, вносим правки без контроля версий и сразу отдаем пользователю;

• Или использовать Хранилище, где уже есть контроль версий;

• Либо применять EDT, чтобы использовать Git и другие возможности.

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

Возьмем работу с хранилищами. Допустим, мы используем рекомендованную 1С технологию разветвленной разработки: у нас есть основное хранилище и проектное. Как поступает разработчик, когда начинает новую задачу?

1. Сначала он получает информационную базу – скачивает и разворачивает на своем компьютере. Это займет минут 10.

2. Потом ищет и загружает файл конфигурации. Для этого нужно либо выгрузить его из основной поставки, либо взять из папки с дистрибутивами – это требует времени, допустим тоже 10 минут.

3. Далее – подключается к Хранилищу. Процесс не самый быстрый и зависит от многих факторов, но на среднем компьютере это занимает минимум 30 минут.

Уже прошло около 50 минут, а ни строчки кода еще не написано.

4. Потом нужно подключиться к хранилищу (5 минут).

5. Затем создать пользователя – например, «Только чтение», «Администратор» или «Тимлид», который будет делать код-ревью (5 минут).

Каждое действие – это отдельный клик. В итоге – уже 60 минут впустую. И это в идеальном случае! А если разработчик отвлекся попить чай, ответить на сообщение или посмотреть мемы – легко можно потерять еще 30 минут. То есть за полтора часа мы ничего не сделали, кроме подготовки к работе.
Как это можно исправить? Очень просто! Автоматизировать.

На OneScript уже есть готовый фреймворк для работы с Хранилищами. С его помощью весь процесс от копирования базы до подключения и настройки пользователя можно свести к одному клику. Нажал и все разворачивается автоматически. За это время разработчик может спокойно попить чай – он уже не потеряет время на промежуточных этапах. Это гораздо удобнее, комфортнее и эффективнее.

И неважно в чем вы разрабатываете (конфигуратор или EDT), просто смотрите как можно сделать вашу работу лучше.

Проверка кода: автоматизация и ревью

После того, как разработали проект, его нужно проверить.

Проверка тоже состоит из нескольких этапов. Условно можно выделить три:

1. Автоматический анализ кода,

2. Code-review,

3. Тестирование.

Начнем с автоматического анализа. Сейчас уже почти все команды используют инструменты для статического анализа кода и все знают про SonarQube. Когда он только появился, это было настоящей «вау-фичей», сейчас же он воспринимается как технологический минимум. Те, кто еще не использует, как минимум, стремятся его подключить. SonarQube помогает автоматически находить ошибки, нарушения стиля и потенциальные баги – все, что можно поймать до ручной проверки.

Но даже этот инструмент постепенно уходит в тень. Его начинают дополнять и вытеснять новые технологии – в первую очередь, нейросети. Например, есть такие решения, как CodeRabbit: они могут анализировать pull request или merge request, проверять код с помощью ИИ и выдавать либо конкретные замечания, либо просто summary – краткое описание того, что было изменено. Это делает процессе проще и удобнее.

Можно и просто «скормить» свой код ChatGPT и спросить: «Представь, что ты опытный тимлид. Что бы ты отметил в этом коде?» Сеть выдаст вполне осмысленные рекомендации, которые можно отработать. Мы еще никого не подключили, а просто поговорили с нейросетью, и она уже помогла нам сделать наш код лучше до того, как мы отдали его другим разработчикам.

Более детально можно ознакомиться с Code-review с помощью ИИ в этой статье.

Только после такой предварительной работы можно переходить к следующему этапу – ручному код-ревью, то есть передаче кода на проверку конкретному человеку.

Если в команде используется код-ревью, важно, чтобы каждый разработчик понимал три вещи:

1. Где это нужно сделать?

• Мы можем проверять CF и замечания писать в текстовый документ.

• Можем проверять pull/merge request и замечания писать там.

• У вас могут быть и отдельные инструменты для проведения код-ревью.

Но всегда должно быть понятно, где нужно делать эту проверку. Помните, что новичок может не знать процесс, если он нигде не описан.

2. К кому обратиться?

Чаще всего ревью выполняет тимлид, но бывает, что этим занимаются другие разработчики. Важно знать, кто именно, и к кому обратиться за ревью.

3. Сколько ждать ревью?

Бывает, что код отправил, неделю ничего не происходит и разработчик начинает переживать. А вдруг просто принято так – ждать? Если сроки не прописаны, это создает напряжение и снижает скорость работы.

Если эти моменты четко зафиксированы – процесс становится прозрачным и предсказуемым. Это сильно упрощает жизнь разработчику и убирает ерунду из этого процесса.

Карта компетенций и распределение ответственности

Как еще можно упростить и улучшить процесс? Здесь поможет такой инструмент, как карта компетенций или матрица ответственности. С его помощью можно наглядно отобразить, как устроена работа в команде и кто за что отвечает.

По горизонтали – зоны ответственности: например, «Производство», «Взаиморасчеты», «НДС», «Зарплата» – все, что есть и используется в вашем проекте. По вертикали – разработчики, аналитики или тимлиды – все кто участвует в процессе.

Каждая ячейка показывает уровень вовлеченности:

• Зеленым выделяем того, кто полностью отвечает за зону. Такой человек всегда должен быть один. Он не обязательно самый умный, но он – единственный, к которому всё стекается и от которого всё исходит.

• Желтым – тех, кто ему помогает, может замещать, но не несет основной ответственности.

Такой подход помогает повысить «фактор автобуса» – метрику, которая отвечает на вопрос: «Сколько человек должно попасть под автобус, чтобы проект остановился?» Чем выше эта метрика, чем больше людей вовлечено в проект, тем устойчивее команда.

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

А если у вас небольшая команда и не хватает людей в подчинении – карта компетенций помогает понять, кого именно нужно добрать.

Тестирование: автоматизированное и ручное

Проверили код и теперь передаем его на тестирование. Я намеренно опущу ручное тестирование. Если оно у вас есть – отлично, это хороший сигнал. Если нет, не беда – не у всех команд есть на это ресурсы, да и не всегда оно необходимо.

Перейдем сразу к автоматизированному тестированию. Здесь тоже есть выбор инструментов. Например, Vanessa и 1С:Тестировщик.

Vanessa, думаю, многим знакома – она уже стала своего рода стандартом автоматизированного тестирования.

1С:Тестировщик и 1С:Сценарное тестирование – это продукты фирмы 1С. Они, как и Vanessa, предназначены для создания и запуска сценарных тестов, разрабатывается той же командой, которая работает над 1С:Бухгалтерией. Мы активно его продвигаем, потому что видим в нем потенциал. Надеюсь, со временем о нем узнает больше людей и он станет такой же привычной частью процесса, как и другие инструменты.

Vanessa и 1С:Тестировщик по функционалу близки. Выбирайте то, что подходит именно вам.

Выпуск продукта и работа с ошибками

После этого задача переходит на следующий этап – выпуск продукта. Если речь идет о простой доработке в виде расширения, то здесь ничего сложного: передали файл и готово. Но если это полноценная разработка, выходящая за рамки мелкого патча, тут уже возникают важные вопросы.

В какой релиз попадет задача? Это важно, потому что если мы внедряем свой функционал параллельно с двумя другими задачами в той же области, то есть риск конфликта и все может сломаться. Поэтому состав релиза должен быть прозрачным: все участники процесса должны понимать, что в него входит, и не конфликтует ли новая функциональность с другими изменениями.

Когда будет этот релиз? Знание сроков помогает правильно планировать. Например, если вы долго работали над крупным проектом и хотите «впихнуть» его в ближайший релиз в последний момент – это рискованно. Лучше не торопиться, а дождаться следующего релиза и успеть качественно проверить после встраивания.

И самое страшное для любого разработчика: что делать, если будет ошибка?
Представим ситуацию: пользователь нашел ошибку и прислал нам конфигурацию. Что разработчику нужно сделать? Правильно открыть эту информационную базу, чтобы воспроизвести проблему.

1. Чтобы просто создать новую информационную базу, нужно минимум 7 кликов

2. Открыть конфигуратор – 1 клик

3. Открыть конфигурацию – 2 клика

4. Загрузить конфигурацию из файла – 4 клика

5. Начать работу – 1 клик

Итого – 15 кликов. А если учесть, что разработчик любит отвлекаться, то времени уйдет еще больше.

Как это упростить? Очень просто – использовать скрипты! Существует специальный скрипт, который позволяет по двойному клику открыть .cf, .dt или любой другой файл 1С – и сразу попасть в эту базу. Это выглядит как магия. Когда я впервые увидел это, честно, был поражен – сразу захотел себе такую штуку.

На самом деле это обычный .bat-файл, который прописывается в ассоциации с платформой. Если вы из моей статьи возьмете что-то одно – пусть это будет именно этот скрипт.

Как находить «ерунду» в повседневной работе

Мы кратко рассмотрели процесс разработки. На каждом этапе нашлась хотя бы одна мелочь, которая мешает, тормозит или раздражает. Но что делать дальше? Как искать эту самую ерунду в своей повседневной работе?

К сожалению, просветление само не придет. Придется поработать. Есть несколько простых способов, которые помогают увидеть то, что раньше было незаметно.

Первое – смотреть свежими глазами.
Попробуйте поменять перспективу. Если вы разработчик, то взгляните на процесс со стороны аналитика, пользователя или новичка. Это помогает по-новому увидеть привычные вещи.

И задавайте вопросы:

– А зачем мы это делаем?

– Почему именно так?

– Это вообще нужно?

Например, чтобы получить доступ к дистрибутивам, нужно отправить пять писем. Почему именно пять? Может быть достаточно одного?

Мы в своем проекте когда-то сделали несколько этапов согласований. Со временем поняли: одно из них – бесполезное. Убрали и стало проще.

И смотрите по сторонам. Наблюдайте, как работают другие. Если вы работаете в большой компании, загляните в соседние отделы и группы, вдруг у них есть какие-то лайфхаки и фичи, которые можно использовать у себя. Если в небольшой, то участвуйте в конференциях или митапах.

Второе – идти путем джуна.
Опытный разработчик знает, где пригнуться, где кликнуть «вслепую», чтобы все заработало. Новичок – нет. Он сразу упирается во все: не может найти дистрибутив, не понимает где регламенты, не может получить доступы.

Здесь и нужно быть рядом с ним. Идти следом, смотреть где он застревает, фиксировать такие моменты. По итогам подготовьте чек-лист: какие доступы нужны, какие шаги пройти, где что лежит. Один раз прошли с новичком – составили чек-лист – и в следующий раз уже будет куда быстрее.

И обязательно назначайте наставника. Пусть проведет нового разработчика по встречам, покажет процессы, расскажет, к кому можно обратиться и по каким вопросам. А не просто бросит: «Вот, работай». Такое отношение убивает мотивацию и создает барьеры.

Третье – ставить зарубки.

Этот прием пришел из жизни. Идете по коридору, ударяетесь об угол – ставите засечку «я тут ударился». Так делает каждый. Через какое-то время смотрим, ударился ли кто-то еще. Если засечек много, то угол стоит убрать – он мешает. А если только ваша – возможно, вы просто невнимательны.

То же самое в работе. Считаете, что давно не было ретроспективы? Спросите коллег: «Кто-то еще считает, что это проблема?» Если поднимают руки – проблема массовая и ее стоит решать. Если нет – это ваш частный случай, его можно отложить.

Для таких засечек можно завести общий файл, куда каждый будет делать записи. Кто-то столкнулся с проблемой – фиксирует. Потом анализируем, когда в последний раз она возникала и насколько массовая.

Искать «ерунду» – вполне решаемая задача, если использовать простые, но системные подходы.

Человек обычно плохо может описать, когда ему хорошо. Зато отлично чувствует, когда что-то не так. Мы точно знаем, когда нам что-то не нравится, когда что-то болит или чего-то не хватает.

То же самое и в работе. Ерунду мы находим там, где нам плохо. Нашли мелочь – убрали, стало чуть лучше. Со временем эти маленькие улучшения накапливаются. И в определенный момент вы понимаете, что работать стало комфортнее.

Как бороться с «ерундой»: инструменты и подходы

Что делать с найденной ерундой? Я выделяю четыре основных способа: правильные инструменты, автоматизация, работа с процессами, регламенты и чек-листы.

1. Правильные инструменты

Использование современных инструментов – CI/CD, DevOps, систем контроля версий, автоматизированных тестов мотивирует разработчика. А если обработки все еще хранятся на Google Диске с названиями вроде v1.2.3_финал_финал_честно_последний.zip, то это не просто устаревший подход, это серьезный удар по мотивации.

Как понять, какие инструменты хорошие? Честный ответ – только методом проб и ошибок. Я собрал на GitHub подборку технологий, актуальных для 1С-разработчиков:

https://github.com/Oxotka/StackTechnologies1C

Там – все, что может пригодиться.

2. Автоматизация

Здесь помимо универсальных языков (Python, Go и других) можно использовать 1С-подобные языки: OneScript или 1С:Исполнитель, которые автоматизируют рутину и убирают то, что мешает.

Но автоматизацию нужно применять с умом. Нелогично потратить 6 часов на автоматизацию задачи, которую делаете раз в месяц по 10 минут. Математически вы окупитесь только через три года.

Однако есть нюанс: перед тем как сделать эту самую десятиминутную задачу, вы тратите еще 20 минут на то, чтобы вспомнить, как ее делать. Автоматизация экономит не только время выполнения, но и время включения в процесс.

Тем не менее, не все нужно автоматизировать. Иногда простой чек-лист решает проблему быстрее и проще.

3. Работа с процессами

Я считаю, что процессы важнее инструментов. Настроив правильные процессы, мы легко подберем подходящие инструменты – а какие-то, возможно, вообще не понадобятся.
О наших процессах при разработке 1С:Бухгалтерии я уже писал на Инфостарте: //infostart.ru/pm/2097867/

Можете посмотреть, возможно, найдете что-то полезное.

4. Регламенты и чек-листы

Чек-листы – универсальный инструмент. Их можно делать буквально на все.

Вот пример, который используется у нас в работе – чек-лист шаблонов новых объектов. Например, мы добавляем новый справочник или документ. Чтобы не забыть разнести его по всем подпискам, обменам, типам, есть чек-лист.

Допустим, мы добавили новый регистр сведений, открываем чек-лист и смотрим, что нужно сделать: какой код вставить, какие моменты не забыть отработать. Все собрано в этом файле https://github.com/Oxotka/TemplatesNewObject1C – можете пользоваться.

То же самое нужно сделать и с доступами. Приходит новый разработчик – есть чек-лист. Открыл – сделал – все готово. Никаких «А где это взять?», «А у кого спросить?».

И регламенты. Да, в основном они ассоциируются с бюрократией, но в крупных командах без них никуда. Регламент постановки задач, регламент проверки кода, регламент выпуска релиза – все это снижает шум, упрощает онбординг и делает процесс предсказуемым.

Developer Experience: зачем это все нужно

Чтобы бороться с ерундой, придется поработать – не получится, что все в одно мгновение станет хорошо. Начните с небольших понятных шагов. Не нужно сразу замахиваться на глобальные изменения – это редко заканчивается чем-то хорошим.

Все, о чем я рассказал, называется Developer Experience – удобство использования для разработчиков. Ближайшее понятие – User Experience (UX): когда мы делаем продукт удобный для пользователя. Здесь же мы стараемся сделать процесс удобным для разработчика.

Почему это важно?
Во-первых, Developer Experience улучшает качество продукта. Когда мы убираем «ерунду» из процесса, исчезают и места, где легко ошибиться. Меньше хаоса = меньше багов.

Во-вторых, растет мотивация и снижается выгорание. Гораздо приятнее работать в команде, где все налажено, используются современные инструменты и выстроены понятные процессы. Это не просто «удобно» – это интересно и драйвово.

И, в-третьих, мы быстрее выпускаем продукт. Отлаженные регламенты, чек-листы, автоматизация – все это сокращает время на рутину.

Занимаясь Developer Experience, мы на самом деле работаем на продукт. Да, в фокусе должен быть пользователь. Но именно разработчики делают так, чтобы продукт жил, развивался и радовал!

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.