Каталог решений - Новичок в TDD

ВНИМАНИЕ: Автор статьи не несёт ответственности за причиненный ущерб Вашим надеждам и/или иным душевным страданиям после прочтения данной публикации. Если Вы человек с тонкой душевной организацией, планирующей применять TDD, Вам лучше отказаться от прочтения или Вам гарантированы знания, которыми Вы можете умело распорядиться. Всем удачи в получении новых знаний! 😉

Всем участникам сообщества мой пламенный привет!

    Будет много букв и требующих вдумчивости и осмысления предложений, налейте приятный для Вас напиток, выберите удобное положение и обязательно оглянитесь!

Оглянуться обязательно, за спиной может быть Руководитель.

Начнём…

1. Вводная часть.

    Не часто, но бывают статьи на «Инфостарт» о том, как правильно вести разработку определенного функционала через тестирование, то есть по промышленным стандартам.

    В основном, это статьи  тех, кто двигает и популяризирует эту тему, тот, кто несёт знамя победы над злом не протестированных автоматически релизов и (или) фич. На текущий момент в арсенале разработчика 1С есть один инструмент, включающий в себя функционал:

1. Cценарного тестирования — Vanessa Behavior;

2. Модульного тестирования — xUnit.

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

Мне всегда нравилось быть на передовой современных технологий в разработке ПО, благо для этого есть масса информации в интернете, да и скорость интернета позволяет, и давно канули в лету времена, когда ты занимал домашний телефон и объяснял своей семье такое нахальство надобностью открыть всего лишь одну страницу из глобальной паутины и почему это важнее звонка Авдотьи Поликарповны.

Сегодня все возможности открыты, было бы желание, а время найдётся.

Но вернёмся всё-таки к нашей теме.

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

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

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

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

Это тема отдельной статьи, не будем об этом, но последствия этого как в ближайшей, так и в долгосрочной перспективе печальны: от демотивации и увольнения, до устоявшегося навсегда мнения — так правильно, я так уже делал.

2. Начинаем изучать.

    Конечно, первое, что приходит на ум — это гуглить, но не тратьте время зря — ничего не будет продуктивного и бесплатно, именно в контексте входа в данную технологию.

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

1. Прежде чем приступить к использованию инструмента мне хочется знать, как именно его применять в той или иной ситуации от начала и до конца. Представьте, если бы Вы учились водить автомобиль так: инструктор запускает двигатель, трогается и предлагает Вам на ходу пересесть, Вы пересели и после того, как доехали, так же на ходу вернулись в своё кресло. Да, Вы научитесь рулить, но не будете знать, как завести и тронуться с места. Это ни в коем случае не камень в огород тех, кто эти инструменты поддерживает и прикручивает новые фичи (ребятам — низкий поклон за их труд) — это конструктивное дополнение. Нужны сквозные примеры от начала и до конца. Сейчас, используя инструментарий, мне, конечно же, в разы легче понимать справку и использовать методы, но сил было затрачено негуманно и неоправданно много, и если мы, как сообщество 1С, хотим поднимать качество разработки, просто необходимо снижать порог для входа;
2. Я совсем не понимал отличия xUnit от Vanessa Behavior от слова СОВСЕМ, а когда не понимаешь, тогда и применяешь глупо — хотелось бы иметь сравнительную таблицу с пояснениями плюсов и минусов использования той или иной возможности;
3. Для применения Vanessa Behavior желательно знать инструментарий Visual Studio Code (VSC) и GitHub, как-то же Вам нужно будет работать и клонировать инструментарий — я, к сожалению, даже краткого описания этого не нашёл и просто не знал, что нужен VSC и это было, поверьте мне, одним из камней преткновения.

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

3. В предвкушении светлого будущего.

    Итак, Вы всё осилили и у Вас даже начинает получаться, Вы чувствуете, как Ваш сон улучшается после каждого очередного «безбагового» релиза.

    Это фичи других разработчиков падают на «продуктиве», но не Ваши, и если тесты написано грамотно, ЭТО ТАК И ЕСТЬ

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

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

    На первоначальном этапе это действительно может быть даже в три раза и более. Инструменты новые, нужно постоянно разбираться, пробовать, оптимально использовать и так далее, со временем скорость, конечно же, будет возрастать, а время на разработку через тестирование уменьшаться, но при всем при этом, если Вы будете разрабатывать без TDD, будет быстрее — это факт.

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

1.  Экономия на количестве циклов «разработка — отладка — тестирование»;
2.  Исключение багов на «продуктиве» и, как следствие, снижение репутационных рисков.

    В итоге, стабильный релиз, все рады, разработчики психологически спокойны, тестировщики в умиротворении, подписанный акт, деньги, отсутствие кассовых разрывов у компании.

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

4. Реалии немного сложнее…

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

А история такая:

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

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

    Несмотря на огромные БД и критичность багов в «продуктиве», на объяснения всех плюсов и временных трудностей, ссылок на доказательство того, что эволюция – это благо, после очередного совещания приходил Руководитель и все необходимо было делать СРОЧНО И ВЧЕРА. И всегда мне приходилось применять технологию «полуподпольно», чтобы хоть как-то соответствовать.

Думать и биться об стену, почему так Вселенная несправедлива, мне не пришлось, так как, имея управленческий опыт, я всегда четко понимал банальные причины этого:

1. Галочка важнее качества. Качество «дофиксим», необходимо оставаться «хорошим» перед Заказчиком, как внутренним, так и внешним;

2. Все новое всегда отрицается, особенно, когда ты это не умеешь делать;

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

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

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

    Скорее, высказывания: зачем нам это надо, и так все более-менее хорошо, динамические обновления за день по пять раз –  это норма, НОРМА — как бы сказала известная телеведущая!

    Но это история про команды, в которых я трудился. Конечно же, мне было очень интересно где же все-таки эта философия прижилась? Я собрал статистику по вакансиям, которые опубликованы на известном всем нам ресурсе.

5. Неужели везде так?

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

Статистика печальна, из 30 команд:

1. В одной есть использование практики TDD, но НЕ описанными выше инструментами;
2. В одной есть понимание и слышали об этом;
3. Остальные — это работа по классике жанра через РМП(с) — разработка через муки пользователя.

Термин РМП(с) придуман мною и введён в словарный запас сразу после знакомства с TDD.

И как же быть? — спрашивал я себя:

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

    И порой от самих программистов 1С я слышу высказывания о том, что 1С –  это нехорошо, зачем я стал одинэсником, тут не все как на жава, сишарп, питон, руби шмуби — специально сохранил написание на русском для придания колорита — но никто при этом не делает усилий в изучении стандартов разработки для того, чтобы код выглядел более лаконично, никто не знает применяемые для 1С инструменты TDD, но зато способны к всеобъемлющей критике — изучайте, дерзайте, применяйте 1С там, где её «конёк», для чего она и была создана и будет Вам внутренняя гармония.

6. Если всё-таки хотите

…разрабатывать в 1С через тестирование:

• Самый правильный вариант — найти команду, пропагандирующее TDD;
• Чуть сложнее чем найти компанию-инкубатор — создать команду самому с нуля в какой-либо растущей компании, или, например, у компании все задачи решались силами внешнего разработчика, выросли, хотят своё подразделение;
• Сложно — «заразить» существующую команду самому или через руководителя.

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

    Очень хорошая статья известного сообществу разработчика. Теоретические азы + обзор инструментов.

    Так же, кому интересна эта философия и есть возможность, купите тематические курсы по промышленной разработке от silver bulleters, они есть на инфостарте (не сочтите за рекламу, только в целях помощи).

Ну что же, думаю достаточно для первого раза.

Всему сообществу 1С добра!