Предпосылки
Год назад наша компания находилась в классическом революционном состоянии, но с точностью до наоборот: верхи не хотели жить по-старому, а низы не могли жить по-новому. И вот я как один из представителей верхов находился в поиске «серебряной пули», которая бы позволила нам перейти из естественного состояния типичного 1С-Франчайзи (когда «неуязвимые чувачки» (C) @zevvssibirix говорят заказчикам: «мы сделали то, что вы от нас хотели, а то, что вам не нравится результат – это не наша проблема», когда о результате изменений в рабочей базе клиента мы узнаём утром от разъяренных менеджеров, у которых недостаточно прав для исполнения их обычных операций и т.д. ) в новое технологичное и управляемое состояние. В итоге мы начали обширную кампанию по организационным и технологическим изменениям в том числе и с привлечением сторонних специалистов, а поскольку нет предела совершенству – то кампания эта продолжается и, я надеюсь, будет продолжаться достаточно долго.
В этой статье я хотел бы рассказать о нашей попытке начать вести разработку на 1С с использованием методики BDD – поскольку данная методика (среди прочих технологических и организационных новаций) взята нами за ориентир, как внутренне присущая DSL-языкам (подробнее об этом здесь).
Немного о BDD для затравки
Что мы знаем про BDD? Знаем, что человек по имени Дэн Норт придумал эту методику, как эволюционное развитие TDD, и есть несколько его статей на эту тему (Введение в BDD и Что за User Story ). Знаем, что есть проект Cucumber, Aslak Helesoy и язык формального описания требований Gherkin, есть многочисленные фреймворки для высокоуровневых языков. С Божьей милостью теперь есть и фреймворк для 1С от проекта «SilverBulleters» - VanessaBehavior. Подробнее о BDD можно почитать на хабре или спросить у гугла – методике уже больше 10-ти лет, так что информации накопилось достаточно.
Чего мы не знаем про BDD? Здесь самое интересное. Дело в том, что когда люди говорят о «методике BDD» - они чаще всего говорят о «мечте-идее о BDD». Это как «коммунизм» в прозе Андрея Платонова: все о нём говорят и к нему стремятся, но имеют весьма смутное представление о том, что же это такое. Постараюсь объяснить, в чём тут сложность. Адепты «бихавиоризма» легко пишут кейсы сценариев для калькуляторов и банкоматов – ну что может быть прозрачнее:
Идеально, не правда ли? Разработка калькуляторов реально вышла на новый уровень…
Dark side of the moon
А теперь давайте перейдём на тёмную сторону луны – поговорим о разработке на 1С. Я какое-то время разрабатывал на 1С, и отчётливо помню, что когда мне было одиноко – я всегда разрабатывал калькуляторы или программировал «змейку» на 1С, и всё время меня мучал вопрос «как это сделать по-правильному?». И как назло от этого увлекательного занятия меня зачем-то отрывали заказчики и требовали странного: каких-то аналитических отчётов, новых документов, изменения существующих документов, сервисных обработок, интеграции и тому подобных «низких» вещей. И я старался поскорее расправиться с этой скукотищей, чтобы вновь с головой погрузиться в загадочный мир калькуляторов и «змеек». Знакомая ситуация? И я понимаю, что мои сотрудники в основном также воспринимают мир. И я должен к ним прийти и сказать: «Ребята, прозрейте! Всё, что вам казалось рутиной и скукотищей, всё что вы делали на скорую руку и сбрасывали тестировать заказчику, всё вот это вот тоже можно делать по-правильному!» Сначала они говорят: «Опять барин на хабре сидел…» Потом видя, что я не отстану: «Сейчас отчётик на компоновке добью – и попробуем». Я им даю мануалы про калькуляторы и банкоматы, они кивают, курят – потом приходят и задают логичные вопросы:
- BDD – прикооольно! Мне тут заказали сделать документ «Отчёт о рабочем времени» в УТ 11, чтобы менеджерам можно было отчитываться о проделанной работе. Как мне это сделать по BDD?
- BDD – крутяк! Мне тут заказали номенклатуру из Excel с картинками загрузить. Как мне это сделать по BDD?
- BDD – отпад! Тут клиентик попросил товары из одного заказа поставщику выборочно перекинуть в другой, причём у него там всё разбито под заказы клиентов, а перебрасывать он хочет сводно по номенклатуре. Как мне это сделать по BDD?
Про товарища, также восхитившегося BDD, и предложившего «обменять УТ 11 с самописным сайтиком одного клиентика», я не буду ничего писать. Просто не буду и всё.
Сценарий «Отчёт о рабочем времени»
Что может быть проще – для начала нужно написать сценарии использования. Это действительно просто (на самом деле - нет). Ну вот возьмём задачу с документом. Начнём!
Хм… Тогда что? По теории сценарии должны воплощать критерии приёмки. То есть какой конкретный результат должен быть у данного действия? Я как программист честно говоря не знаю. На мой взгляд (как программиста) конечный результат – это записанный документ с информацией менеджера. А вот какой результат ожидает менеджер? Кто об этом должен думать? Программист 1С? Отложим этот вопрос до лучших времён, и вдохновившись статьёй Сергея Георгиевича, включим режим бизнес-аналитика. Итак, предположим документ введён. Что будет дальше с ним делать менеджер? Сам ему предложу. Слушай, менеджер, вот ты отчитался за неделю, каждый день вводил эти долбаные отчёты, и вот пятница, потом выходные пролетели в пьяном угаре, и вот понедельник, башка болит, всё в тумане. Что тебе поможет вспомнить всё? Конечно отчёт о прошлой неделе! Это же очевидно. Строим отчёт по дням и вспоминаем, вспоминаем, вспоминаем… Это великолепно!
То есть сценарий должен заканчиваться отчётом. Менеджер вводит документ за документом, чтобы в итоге построить ретроспективный отчёт:
В принципе неплохой прототип сценария… Показываю менеджеру – он счастлив. Как бизнес-аналитик я отработал. Возвращаюсь в режим программиста. Смотрю на сценарий – и он мне не нравится. Он мне не нравится, потому что мне непонятно, что надо делать. Какие должны быть реквизиты у документа, какие из них обязательные, какие нет, какие кнопки должны быть, может нужно какие-то документы привязать (письма, контакты, заказы), про отчёт вообще непонятно. Ну ладно, по ходу додумаю…
Скажу сразу чего не хватает этому сценарию: конкретики. Должен быть конкретный пример, что и в какие поля вбивает менеджер, и какие данные в отчёте он в результате видит.
Cценарий «Загрузка из Excel»
Ну это каждый 1С-ик делал. Сейчас разберёмся. Пишу:
Очень информативно, правда? А что может ещё расписать бизнес-аналитик для такого сценария, если поведение пользователя в системе будем именно таким? Я как программист должен внести исправления в исходный сценарий, чтобы как минимум указать структуру Excel-таблицы, из которой буду загружать данные. Заметьте, что дальше я как программист предпочту выполнить проверку прочитанной из Excel-файла информации. То есть мне нужно сделать некую промежуточную таблицу, в которую загрузится содержимое файла Excel. И таким образом я проверю, что в файле тоже самое, что и в моей промежуточной таблице. Потом я должен создать номенклатуру и проверить её создание. И это всё я должен выразить на декларативном языке описания требований. В этот момент программисты обычно начинаю роптать. Они говорят про самодокументирующийся код, про то, что запрограммировать будет быстрее, чем писать этот сценарий, и так всё понятно, и вообще Gherkin не нужен…
Итак, обработанный программистом набор сценариев:
Первый:
Второй:
Третий:
Четвертый:
Ну вот это уже сценарии для нормальной разработки! Тут и сторонники TDD скажут, что это похоже на тестовые наборы с ассертами, ну и вообще имеет право на жизнь.
Но и тут есть нюансы. Например, я как бизнес-аналитик смотрю на этот сценарий и спрашиваю: «а это вообще о чём?» Что это такое? «Ну как же?» - отвечу я как программист – «это же тот самый сценарий загрузки номенклатуры, только улучшенный!» Но бизнес-аналитик покачает головой и скажет: «мне будет трудно донести это клиенту, слишком много технических подробностей». Ну и я как зануда добавлю: «а в чём здесь собственно поведение? За этими деревьями строк и таблиц совсем не видно бихавиорного леса». То есть фактически это превратилось в тестовые наборы на Gherkin, а совсем не в описание поведения пользователя. Более того, когда бизнес-аналитик договаривался с клиентом – то зафиксировал договоренности в первоначальном сценарии, а в качестве базы для реализации будет применяться совсем другой сценарий. Я как клиент не могу быть уверен, что в ходе трансформации не было утеряно само зерно моей хотелки – и принимая работу, я как клиент буду неприятно удивлён.
Если на претензию об избыточности технических нюансов можно ответить «интегральным сценарием» либо многоуровневым (вложенным) сценарием, то что делать с бихавиорным дуализмом или дуалистичным бихавиором мы ещё для себя не решили.
Интегральный сценарий даёт возможность ссылаться на другие сценарии feature-файла, либо экспортированные сценарии других feature-файлов в той же папке и вложенных в неё:
Многоуровневый (вложенный) сценарий позволяет превратить сценарий в древоводиную структуру с использованием тэга @tree:
В этом случае текст «Чтение данных из файла Excel» и «Проверка прочитанных данных из Excel» - не являются исполнимыми шагами сценариев, а всего лишь узлом дерева – конкретные шаги расположены на уровень ниже.
Вот как это выглядит в VanessaBehavior:
Резюме
Какие вопросы я хотел осветить, а точнее – поднять для обсуждения:
- Внезапно BDD – это не о программировании, а о бизнес-анализе. Кто из ваших сотрудников будет этим заниматься? Программисты, которые мыслят объектами метаданных? Методисты, которые мыслят жёлтыми книжками?
- Какой должна быть степень детализации проработки сценария бизнес-аналитиком, и где та грань, когда сценарий будет уже понятным программисту, но ещё не потеряет своей семантической нагрузки?
- Как бизнес-аналитику писать сценарии, чтобы программист реально ими пользовался, а не выбрасывал их и переписывал на такие, чтобы ему удобно было разрабатывать?
- Как объяснить бизнес-аналитику, что ему больше не надо описывать функционал, а нужно описывать поведение пользователя? Не превращать каждый сценарий в описание внутренней логики программы при нажатии кнопки, а фокусироваться на критериях приёмки.
- Насколько это корректно заставлять человека-непрограммиста описывать требования заказчика с использованием формального языка? Если роли БА и программиста выполняются одним человеком – то проблем нет, а если у нас проект и команда, тогда как?
- Как повлияет на скорость разработки/внедрения составление сценариев бизнес-аналитиком до программирования?
- Как использовать BDD на проектах внедрения, когда львиная доля – это типовой функционал 1С? Обкладывать сценариями типовой функционал?
Темы, которые я хотел бы затронуть в следующих статьях этой серии:
- Как поставить применение BDD на поток в проектах внедрения 1С?
- С чего начинается сценарий? Предварительная работа с требованиями заказчика.
- Как организовать регрессионное тестирование внедряемых типовых конфигураций с использованием сценариев поведения пользователей.
Отдельно хочу поблагодарить за содействие в написании статьи:
@allustin – главный идеолог команды «Серебряная пуля»
@Pr-Mex – автор фреймворка Vanessa-Behavior
Пообщаться со всеми нами на тему "BDD и 1С" можно здесь.
