ВНИМАНИЕ: Автор статьи не несёт ответственности за причиненный ущерб Вашим надеждам и/или иным душевным страданиям после прочтения данной публикации. Если Вы человек с тонкой душевной организацией, планирующей применять TDD, Вам лучше отказаться от прочтения или Вам гарантированы знания, которыми Вы можете умело распорядиться. Всем удачи в получении новых знаний! ;-)
Всем участникам сообщества мой пламенный привет!
Будет много букв и требующих вдумчивости и осмысления предложений, налейте приятный для Вас напиток, выберите удобное положение и обязательно оглянитесь!
Оглянуться обязательно, за спиной может быть Руководитель.
Начнём...
1. Вводная часть.
Не часто, но бывают статьи на «Инфостарт» о том, как правильно вести разработку определенного функционала через тестирование, то есть по промышленным стандартам.
В основном, это статьи тех, кто двигает и популяризирует эту тему, тот, кто несёт знамя победы над злом не протестированных автоматически релизов и (или) фич. На текущий момент в арсенале разработчика 1С есть один инструмент, включающий в себя функционал:
1. Cценарного тестирования - Vanessa Behavior;
2. Модульного тестирования - xUnit.
Для тех, кто не в теме, до определенного момента эти два инструмента развивались каждый сам по себе, а с текущего года - объединились в один проект, что абсолютно закономерно, с моей точки зрения.
Мне всегда нравилось быть на передовой современных технологий в разработке ПО, благо для этого есть масса информации в интернете, да и скорость интернета позволяет, и давно канули в лету времена, когда ты занимал домашний телефон и объяснял своей семье такое нахальство надобностью открыть всего лишь одну страницу из глобальной паутины и почему это важнее звонка Авдотьи Поликарповны.
Сегодня все возможности открыты, было бы желание, а время найдётся.
Но вернёмся всё-таки к нашей теме.
Итак, не обошёл стороной и я данный инструментарий и в дальнейшем на протяжении всей статьи понемногу я буду использовать аналогии, так нередко применяющиеся в разработке ПО, чтобы через призму простых житейских вопросов донести свой посыл.
Начнём с того, чтобы применять какой-либо инструментарий нужно учиться, учиться и, самое главное, наконец-таки научиться и не абы как, а методически правильно, ведь мы не садимся на автомобиль и не едем задним ходом от дома до работы, хотя если кто-то в этом признается наконец-то сам себе или открыто в комментариях, респект миру неординарных личностей, Вас мало, но Вы интересны.
Казалось бы, использовали функционал автомобиля, доехали, но как-то необычно что ли: вспотели, затекла шея, решил побольше поставить зеркало заднего вида, долго думал о том, как бы удобнее развернуть сиденье, но в итоге остановился на том, что лучше общественный транспорт, чем этот неудобный и малопригодный для применения автомобиль. Да, в общественном транспорте, бывает, и на ногу наступят, и в двери не залезешь, и сломается на середине пути - но зато все так делают и более-менее гарантированно получишь качественный итог поездки, да и напрягаться не нужно, рулить самому, обдумывать, учиться и так далее, испытывая на себе все прелести владения новым инструментом доставки до работы.
Многие руководители/управленцы грешат тем, что бросают новичка в омут создания новой фичи не рассказывая, как, с помощью чего и, главное, методически правильно применить тот или иной метод, инструментарий или функционал.
Это тема отдельной статьи, не будем об этом, но последствия этого как в ближайшей, так и в долгосрочной перспективе печальны: от демотивации и увольнения, до устоявшегося навсегда мнения - так правильно, я так уже делал.
2. Начинаем изучать.
Конечно, первое, что приходит на ум - это гуглить, но не тратьте время зря - ничего не будет продуктивного и бесплатно, именно в контексте входа в данную технологию.
Есть описание и справка инструментов на GitHub, но для меня взять нахрапом было сложно по нескольким причинам, надеюсь, разработчики услышат меня:
- Прежде чем приступить к использованию инструмента мне хочется знать, как именно его применять в той или иной ситуации от начала и до конца. Представьте, если бы Вы учились водить автомобиль так: инструктор запускает двигатель, трогается и предлагает Вам на ходу пересесть, Вы пересели и после того, как доехали, так же на ходу вернулись в своё кресло. Да, Вы научитесь рулить, но не будете знать, как завести и тронуться с места. Это ни в коем случае не камень в огород тех, кто эти инструменты поддерживает и прикручивает новые фичи (ребятам - низкий поклон за их труд) - это конструктивное дополнение. Нужны сквозные примеры от начала и до конца. Сейчас, используя инструментарий, мне, конечно же, в разы легче понимать справку и использовать методы, но сил было затрачено негуманно и неоправданно много, и если мы, как сообщество 1С, хотим поднимать качество разработки, просто необходимо снижать порог для входа;
- Я совсем не понимал отличия xUnit от Vanessa Behavior от слова СОВСЕМ, а когда не понимаешь, тогда и применяешь глупо - хотелось бы иметь сравнительную таблицу с пояснениями плюсов и минусов использования той или иной возможности;
- Для применения Vanessa Behavior желательно знать инструментарий Visual Studio Code (VSC) и GitHub, как-то же Вам нужно будет работать и клонировать инструментарий - я, к сожалению, даже краткого описания этого не нашёл и просто не знал, что нужен VSC и это было, поверьте мне, одним из камней преткновения.
Конечно, я четко понимаю, что когда ты обладаешь системным знанием: как подготовить окружение, для чего и как использовать - это уже уровень, при котором такие нюансы кажутся элементарными, но для новичков это тернистый путь, которые проходят далеко не все.
3. В предвкушении светлого будущего.
Итак, Вы всё осилили и у Вас даже начинает получаться, Вы чувствуете, как Ваш сон улучшается после каждого очередного «безбагового» релиза.
Это фичи других разработчиков падают на «продуктиве», но не Ваши, и если тесты написано грамотно, ЭТО ТАК И ЕСТЬ
- я рассуждаю не как теоретик, вдохновлённый прочитанными книгами о промышленной разработке и насмотревшийся видео, а как практик, хоть и делающий в этом направлении не первый, но уже уверенно второй шаг.
И вот Вы, почувствовавший блаженство, вдруг начинаете ловить сначала косые взгляды сотрудников, а затем и претензии руководителя, почему разработка затягивается в два, а то и в три раза.
На первоначальном этапе это действительно может быть даже в три раза и более. Инструменты новые, нужно постоянно разбираться, пробовать, оптимально использовать и так далее, со временем скорость, конечно же, будет возрастать, а время на разработку через тестирование уменьшаться, но при всем при этом, если Вы будете разрабатывать без TDD, будет быстрее - это факт.
И тут самое главное непонимание многими, где же профит, а профит системный и на поверхности: если компания крупная, дорожит своей репутацией, умеет считать деньги за часы работы тестировщиков и разработчиков, то все очень просто:
- Экономия на количестве циклов «разработка - отладка - тестирование»;
- Исключение багов на «продуктиве» и, как следствие, снижение репутационных рисков.
В итоге, стабильный релиз, все рады, разработчики психологически спокойны, тестировщики в умиротворении, подписанный акт, деньги, отсутствие кассовых разрывов у компании.
Но это если в розовых очках, теперь расскажу Вам опыт тех компаний, где мне посчастливилось работать и приобрести этот ценный и разносторонний опыт.
4. Реалии немного сложнее...
Я намеренно не буду раскладывать все нумерованным списком с пояснением нюансов разработки и характеристикой конфигураций конкретной компании именно потому, что не хочется хоть как-то персонализировать и задеть самолюбие моих прошлых руководителей.
А история такая:
Это были три достойно крупных региональных компании и компания-франчайзи. Думаю про «франч» писать не стоит - Вы сами понимаете, а вот в крупных компаниях ещё интереснее:
Никому, ни одному руководителю не нужна была эта технология именно из-за увеличения локальных сроков разработки.
Несмотря на огромные БД и критичность багов в «продуктиве», на объяснения всех плюсов и временных трудностей, ссылок на доказательство того, что эволюция – это благо, после очередного совещания приходил Руководитель и все необходимо было делать СРОЧНО И ВЧЕРА. И всегда мне приходилось применять технологию «полуподпольно», чтобы хоть как-то соответствовать.
Думать и биться об стену, почему так Вселенная несправедлива, мне не пришлось, так как, имея управленческий опыт, я всегда четко понимал банальные причины этого:
1. Галочка важнее качества. Качество «дофиксим», необходимо оставаться «хорошим» перед Заказчиком, как внутренним, так и внешним;
2. Все новое всегда отрицается, особенно, когда ты это не умеешь делать;
3. Отсутствие желания учиться новому, а зачем? Есть зона комфорта, все хорошо в матрице этого человека и, возможно, даже он считает себя специалистом с большой буквы;
4. Ну и психологию никто не отменял, умнее, значит, конкурент, а высокооплачиваемое место терять никому не хочется в наше неспокойное время и век ипотеки, хотя никогда никого не «подсиживал» и целей таких не имею.
Ещё один интересный момент заключается в том, что многие разработчики вообще не проявляли инициативы изучить инструмент, даже работая со мной в одной компании. Казалось бы, мне пришлось пройти нелегкий путь в изучении, а тут рядом, под боком, спрашивай - расскажу и покажу, но нет. Абсолютно.
Скорее, высказывания: зачем нам это надо, и так все более-менее хорошо, динамические обновления за день по пять раз – это норма, НОРМА - как бы сказала известная телеведущая!
Но это история про команды, в которых я трудился. Конечно же, мне было очень интересно где же все-таки эта философия прижилась? Я собрал статистику по вакансиям, которые опубликованы на известном всем нам ресурсе.
5. Неужели везде так?
Так вот, я сделал небольшой опросник работодателей, которые меня приглашали на собеседование или откликался я сам для того, чтобы выяснить, применяет ли команда данный стек технологий.
Статистика печальна, из 30 команд:
- В одной есть использование практики TDD, но НЕ описанными выше инструментами;
- В одной есть понимание и слышали об этом;
- Остальные - это работа по классике жанра через РМП(с) - разработка через муки пользователя.
Термин РМП(с) придуман мною и введён в словарный запас сразу после знакомства с TDD.
И как же быть? - спрашивал я себя:
только системное мышление, только ИТ-директор, собственник ИТ-компании, возможно, сможет это продавливать в коллективах собственным ли опытом, опытом инициативного коллеги, устраивать разборы полетов, почему статистика багов по «фичам» через тестирование в разы меньше, но это должно быть, ибо шаг вперёд – это развитие и эволюция, а не повседневная рутина, которую также можно и нужно разнообразить.
И порой от самих программистов 1С я слышу высказывания о том, что 1С – это нехорошо, зачем я стал одинэсником, тут не все как на жава, сишарп, питон, руби шмуби - специально сохранил написание на русском для придания колорита - но никто при этом не делает усилий в изучении стандартов разработки для того, чтобы код выглядел более лаконично, никто не знает применяемые для 1С инструменты TDD, но зато способны к всеобъемлющей критике - изучайте, дерзайте, применяйте 1С там, где её «конёк», для чего она и была создана и будет Вам внутренняя гармония.
6. Если всё-таки хотите
...разрабатывать в 1С через тестирование:
- Самый правильный вариант - найти команду, пропагандирующее TDD;
- Чуть сложнее чем найти компанию-инкубатор - создать команду самому с нуля в какой-либо растущей компании, или, например, у компании все задачи решались силами внешнего разработчика, выросли, хотят своё подразделение;
- Сложно - «заразить» существующую команду самому или через руководителя.
В заключение хотелось бы ещё раз выразить огромную благодарность всем тем, кто помогал мне в освоении данного инструмента, низкий поклон и искреннее уважение тем, кто придумал, разработал, довёл до логического и работающего состояния и также занимается поддержкой xUnit и VanBe.
Очень хорошая статья известного сообществу разработчика. Теоретические азы + обзор инструментов.
Так же, кому интересна эта философия и есть возможность, купите тематические курсы по промышленной разработке от silver bulleters, они есть на инфостарте (не сочтите за рекламу, только в целях помощи).
Ну что же, думаю достаточно для первого раза.
Всему сообществу 1С добра!
