В заключительный день конференции INFOSTART EVENT 2019 Inception нам удалось пообщаться с ведущим программистом «Первого БИТа» Никитой Грызловым. Никита рассказал, почему необходимо тестировать код, какие инструменты и технологии для этого использовать и насколько важно управлять качеством кода в мире 1С.
Никита, здравствуйте! В который раз вы приезжаете к нам на конференцию?
Четвертый.
Что вас привлекает в нашем мероприятии?
Часто звучит фраза, что Инфостарт – это крупнейшее сообщество 1С-ников. Я с этим согласен. Здесь, действительно, очень много специалистов. И так уж получается, что большинство людей, которые приезжают на Инфостарт – это не стажеры, только вчера вышедшие на работу, а именно люди, которые уже «нюхнули пороху». Это либо уверенные мидл-разработчики, либо ведущие специалисты, которые приезжают сюда обсудить свои проблемы, поделиться своими идеями, своей болью. Каждый мой приезд на конференцию сопровождается узнаванием чего-то нового, зарождением каких-то идей. Часть этих идей я просто принимаю от людей, которые обсуждают здесь то, что уже реализовали на работе, часть рождается прямо в обсуждениях. Буквально сегодня утром, когда обсуждали вчерашний доклад Андрея Крапивина по поводу логирования, родилась идея нового инструмента – как можно автоматизировать расстановку операций для логирования действий пользователя на форме. Сидели за завтраком, общались, и раз – возникла идея инструмента. Оказалось, что часть наработок у Андрея уже есть. Возможно, скоро появится что-то новое и крутое. Это постоянная движуха, постоянные идеи, и мне это очень нравится.
То есть, вас привлекает в первую очередь атмосфера и новые знания?
Да, новых знаний здесь можно получить очень много. Если слушать. На конференции есть люди, которые сидят только в залах – они пришли, сели в уголочек и весь день там сидят – приходят утром, уходят вечером. Это, безусловно, тоже мнение – они пришли посмотреть доклады, послушать, что говорят «умные люди». Но те кулуарные разговоры, которые были в «Колизее» в прошлых годах, продолжаются и здесь – только здесь коридоры пошире. Много знаний получается не только на докладах, но и в коридорах, поэтому я тоже стараюсь не сидеть на одном месте, а как-то перемещаться – то к одной группе людей подойти, то к другой. Везде интересно.
Ваш доклад уже второй год подряд связан с темой тестирования. Насколько вы считаете важной роль тестирования в процессе разработки?
Наверное, тестирование – это следующая по важности тема после собственно добавления или изменения функциональности. Тестировать свою работу – это важно. В моей жизни встречались разработчики, которые вообще не запускали код, который написали. И им было не стыдно передавать сделанное на тестирование сразу заказчику.
Я с таким подходом категорически не согласен. Тестировать нужно сразу же. Я понимаю, что внедрение автотестов на начальном этапе может быть сложным и непонятным. Но в это надо погружаться и этим нужно заниматься.
В прошлом году я был на Java-конференции, куда приезжал один из иностранных докладчиков. В перерыве между докладами вокруг него собралась группа людей, чтобы обсудить постоянное обучение программистов и, конкретно, тему тестирования. В этом разговоре он выразил следующую мысль: если вы сейчас не умеете тестировать и не прикладываете никаких усилий, чтобы этому научиться (или ваш работодатель против того, чтобы вы занимались тестированием), то вы, грубо говоря, сами роете себе могилу, потому что через 10 лет будете неликвидом и не сможете дальше разрабатывать конфигурации. Вы будете никому не нужны, потому что мир развивается, о тестировании говорят все больше, продуктов для автоматизированного тестирования становится все больше. И это – действительно важная тема, которая помогает улучшать качество разрабатываемых решений и гарантировать то, что они, как минимум, работают. Мне кажется, это очень важно.
А какие еще технологические тренды вы считаете перспективными в сфере 1С? Возможно, виртуализация, контейнеризация приложений, подходы DevOps?
Так получается, что в последние годы я работаю не только с 1С, но и с другими системами, которые являются частью решения, предоставляемого заказчику – с ними приходится делать интеграцию. И 1С пока контейнеризируется не очень хорошо, да и, на мой взгляд, загонять сервер 1С в docker – это, скажем так, сомнительное решение. Плюсы не очевидны.
А клиент?
А зачем? Docker обычно используется для двух целей: либо для того, чтобы у разработчика можно было быстро развернуть то же самое окружение, которое работает на production (чтобы контуры разработки, тестирования и production были максимально друг на друга похожи – чтобы все работало в примерно одинаковом окружении). Либо для доставки инструментов разработки. Я знаком с людьми, которые являются веб-разработчиками, но у них на клиенте не установлен Node.js, нет интерпретатора PHP – они все это дело запускают в docker. У них получается максимально легкая и чистая машина, в которой вся их работа, связанная с разработкой программного обеспечения, запускается через команды в docker-контейнере. Это, наверное, удобно для переключения контекста между работой и домом: когда ты погасил docker, и у тебя на машине уже ничего не запустится, потому что физически у тебя инструментария уже нет.
Но в мире 1С, мне кажется, пока потребности в контейнеризации нет. У меня на домашнем компьютере стоит 1С многих версий, начиная от 8.2 – сколько живет компьютер без переустановки операционной системы, столько версий у меня копится. Я работаю из дома, пишу что-то для себя дома. Новый инструментарий на компьютере все равно появляется. И платформа 1С в плане разграничения версий сделана хорошо – у нас все платформы ставятся в разные каталоги, поэтому нет проблем запускать информационную базу под разными версиями 1С. А если мы посмотрим в мир Ruby или Java, то там вопрос по переключению окружения стоит гораздо актуальнее: например, под одной версией Ruby сайт запускается, а под другой – не запускается, и разработчикам приходится постоянно что-то менять в своем окружении для того, чтобы можно было работать. В 1С такой проблемы нет, и спроса на клиентскую контейнеризацию тоже нет.
Если вернуться к использованию docker вне 1С, то да, это действительно удобное решение и для разработки, и, соответственно, для последующего раската на prod. Тот же самый RabbitMQ, какие-то сайты, с которыми вы интегрируетесь, SoapUI для поднятия мок-сервисов в целях тестирования, если вы используете интеграцию через HTTP-сервисы – это все запускается в docker. Все это имеет очень маленькие конфигурационные файлы, которые, если вы знаете, как работает docker, очень легко под себя подтюнить, если у вас какая-то необычная машина или необычная потребность. Это, действительно, ускоряет и погружение в проект, и подготовку самой среды для разработки. Только для этого нужно работать не только в конфигураторе, но и мир вокруг тоже захватывать.
То есть, мир в конфигураторе остается на локальной машине, а все интеграционное окружение можно выносить в контейнеры?
Да, все в docker (смеется).
Вы один из самых активных участников сообщества, который развивает собственные OpenSource-проекты на GitHub. И, насколько я знаю, один из самых обсуждаемых сейчас проектов у вас – инструмент для поддержки языка 1С в различных текстовых редакторах и статического анализа с помощью платформы SonarQube. Этот инструмент упоминался практически в каждом докладе секции «Инструментарий», но конкретного доклада по нему так и не было. Хотелось бы услышать из первых уст, о чем этот инструмент.
Тут два вопроса – про BSL Language Server и про SonarQube. Начну про Language Server.
Когда-то давно, в 2015 году, когда я работал в одном из московских университетов, родилась идея о том, что нужно упростить свою деятельность при выкатке обновлений на prod. У нас во внедрении тогда активно использовались различные внешние обработки – для печатных форм, заполнения табличных частей. Я уже тогда был знаком с Git, и все, что было, пытался в него загнать. В частности, подсел на GitLab – он был у нас развернут внутри.
Тогда у меня появилась идея автоматизировать все по максимуму, используя инструменты, которые применяются в других языках. И, в принципе, я каждый раз одергивал себя от желания зайти на production-сервер, чтобы что-то потрогать руками. Но возникла первая проблема – на чем писать скрипты.
Вначале я посмотрел на bash. Я понял его логику, но через два дня я эту логику забыл. Посмотрел на него снова и понял, что если я буду писать скрипты на bash, они будут неподдерживаемые даже мною самим, потому что я буду постоянно забывать, как они работают.
Писать скрипты на каких-то других языках мне показалось в принципе примерно так же трудозатратно, как на bash, потому что опыта в скриптовых языках у меня было не очень много.
И как-то случайно я наткнулся на проект OneScript – возможно, прочитал статью Андрея Овсянкина на Хабре или послушал его доклад на конференции Инфостарта, где он презентовал этот инструмент. И я, как типовой 1С-ник, который хочет что-то автоматизировать, понял, что действительно могу писать код на 1С, что OneScript будет помогать мне релизиться, собирать внешние обработки и делать то, ради чего он как проект и создавался.
И я наткнулся на то, что изначально у меня нигде не было подсветки языка 1С. Была подсветка для Notepad++, и несколько напускное мое мнение о том, что я этот редактор не очень люблю. На самом деле я его очень уважаю, потому что он принес очень много пользы и продолжает активно развиваться. В какой-то момент он действительно стал стандартом и для администраторов, и для программистов, когда им нужно что-то быстро подставить, а среды разработки под рукой нет. Но я решил, что буду Д’Артаньяном и напишу все свое.
В тот момент в среде скриптописателей было несколько популярных текстовых редакторов для разработки – один из них Sublime Text, который мне тогда очень нравился. Первоначально – просто за счет своей цветовой темы Monokai (как мало надо 1С-нику после конфигуратора). Я тогда увлекался CoffeeScript – это надстройка над JavaScript, язык, который сейчас уже, к сожалению, умер. И мне очень нравилось, как в этом редакторе выглядит код на CoffeeScript – идентификаторы выделялись синеньким, зелененьким, все было понятно и красиво.
В какой-то момент я открыл 1С-ный код, выбрал подсветку CoffeeScript и увидел, что что-то начало раскрашиваться. Какие-то куски кода на английском почему-то стали красненькими, строки начали подсвечиваться желтеньким. «Наверное, это что-то значит!», – подумал я. Стал углубляться в документацию и увидел, что я сам могу сделать подсветку для любого языка. Потом я увидел, что эту же подсветку можно использовать в Atom, который в тот момент очень активно продвигал GitHub. Плюс эта же подсветка заработала и в Visual Studio Code (VSC) – практически без каких-то изменений. Даже если какие-то вещи приходилось тюнить, глобально то, что было написано изначально, заработало везде. И родилась идея собрать единомышленников, которым тоже интересна идея поддержки языка 1С в различных текстовых редакторах.
Тем более, что потребность писать скрипты на OneScript у сообщества была. В конфигураторе писать скрипты практически невозможно, потому что OneScript – это в первую очередь библиотеки, где первая строка содержит директиву #Использовать. При сохранении файла конфигуратор выдаст вам ошибку синтаксиса – работать в таком режиме очень проблематично. EDT тогда еще не было даже в бета-версии – мы знали, что он сейчас разрабатывается, но его, по сути, никто еще не щупал.
В итоге родилось сообщество людей, которым эта тема интересна. Причем не только из России. Подключались участники из Украины, Беларуси, Казахстана. И они стали это дело продвигать – каждый по чуть-чуть вносил свой вклад. Через некоторое время очень мною уважаемый Женя Сосна прислал просто катастрофический по своим объемам пулл-реквест (примерно на пять тысяч строк) с механизмом автодополнения для плагина к Visual Studio Code, на котором мы постепенно начали все больше и больше фокусироваться. Я посмотрел на этот пулл-реквест и понял, что это очень круто, но я не понимаю, как оно работает. И как-то так получилось, что этот проект в основном подхватил даже не я, а люди, которые вместе со мной над этим работали.
Тогда не было какого-то стандартного единого протокола для поддержки различных возможностей в редакторах вроде автодополнения, подсказки по параметрам процедур, каких-то всплывающих окошек. В каждом редакторе все это разрабатывалось параллельно. Когда я увидел объем работ, который был сделан для Visual Studio Code, и количество доработок, которое легло поверх этого ядра, я понял, что портировать это в Atom и в SublimeText практически нереально. Код был неотторгаем. Я попытался произвести работу по его унификации, но максимум, что у меня получилось – это сделать универсальными 5% кода, а 95% все равно остались заточенными под конкретный редактор.
Примерно через полгода Microsoft представила Language Server Protocol (LSP) – это спецификация по тому, как редактор должен общаться с неким отдельно стоящим ядром и получать информацию о том, что можно показать разработчику. Что нужно подставить в систему автодополнения, если разработчик нажимает Ctrl+пробел, и тому подобное. Этот протокол позволял вытащить логику по работе с языком в отдельное ядро, чтобы предоставить универсальный интерфейс к разным редакторам.
Когда я рассмотрел LSP, я наткнулся на две проблемы. Во-первых, я понял, что этот протокол работает совсем не так, как было написано решение, предложенное Женей. Это означало, что нужно будет переписывать все полностью. Во-вторых, в самом протоколе на тот момент было мало возможностей.
Но идея перейти на единый протокол для разных редакторов жила. Она поселилась в моей голове и очень долго «клевала мне мозг» о том, что надо все переписать и сделать по-нормальному. В очередной раз я о ней вспомнил, когда мы с Лешей Сосновым начали разрабатывать плагин для поддержки 1С в IntelliJ IDEA – стало понятно, что перед нами стоит задача повторить все то, что уже написано для Visual Studio Code.
Когда вышла третья версия протокола LSP, я понял, что она уже готова к тому, чтобы ее использовать, что большинство возможностей, которые я бы хотел видеть в редакторе, можно реализовать через нее. Я понял, что вместо написания еще одного неотторгаемого ядра для нового редактора теперь будет лучше вложиться в разработку Language Server для 1С. С одной стороны это позволит добавлять новые фичи в плагин для IDEA, а с другой – постепенно перевести все, что было написано в плагине для VSC, на новый универсальный движок, который бы вообще работал везде, где есть поддержка LSP. Одна из наиболее полных реализаций спецификации LSP написана на Java, а я хотел улучшить свои навыки написания на ней. Это стало отправной точкой для нашего нового проекта BSL LS, который начал разрабатываться отдельно от плагина для IDEA.
В принципе этот движок сейчас еще не дописан. Из тех возможностей, которые есть в Visual Studio Code, поддержано максимум 10 процентов. Но для сообщества изначальная цель, с которой разрабатывался Language Server (предоставить единый опыт для всех редакторов по автодополнению, сигнатурам, всплывашкам и т.д.), несколько сместилась. В нашем новом проекте BSL LS сообщество увидело механизм, в котором оно может писать свои проверки для кода 1С. Это так называемые диагностики, тоже часть протокола LSP. Можно написать 50-100 строк кода, потом открыть 1С-ный модуль в редакторе и увидеть, что у вас что-то подсветилось – здесь ошибка, тут некачественный код. Я не ожидал, что к этой идее подключится столько людей и вообще не ожидал, что есть так много 1С-ников, которым интересно писать на Java.
Произошел определенный перекос – с одной стороны я, вроде бы, хотел разрабатывать ядро, и моей конечной целью было расширение фич редактора, а с другой стороны – народ активно разрабатывает диагностики. Когда мы с Лешей увидели этот интерес, то поняли, что на развитие ядра останемся только мы с ним. А усилия людей, которые вкладываются в развитие диагностик, стоит направить в нужное русло. Здесь практически сразу же мне в голову пришла платформа SonarQube, как инструмент для управления техническим долгом, который хранит в себе информацию по замечаниям, позволяет смотреть в динамике, как они появлялись/удалялись. И в принципе, на это недописанное ядро BSL LS буквально парой строк кода была добавлена функциональность для показа замечаний в SonarQube. Это привлекло еще больше контрибьюторов.
Сейчас плагин для SonarQube – по сути, очень тонкий (как тонкий клиент, который ничего не делает с базой данных, а отдает все серверу). Плагин SonarQube работает примерно так же, как все редакторы работают с этим BSL Language Server. У BSL LS есть точка расширения, которой можно сказать: «Отдай мне диагностики по этому модулю». А плагин для SonarQube лишь складывает результаты в базу данных SonarQube.
Наверное, цель по унификации поддержки языка достигнута. Но каким-то таким странным способом.
Но она пока еще в процессе?
Да, в процессе. Я и Леша дописываем ядро, а оставшаяся часть сообщества в основном дописывает диагностики, причем с очень неожиданными темпами. Находятся люди, которые присылают и доработки «основного» ядра. Я, действительно, удивлен и очень рад, что столько людей присоединилось к разработке.
Это действительно прямо коллективная работа. Каким образом вам удается все это организовывать? Вы используете какие-то специфические инструменты для этого? Или просто общаетесь и заинтересовываете?
В процессе контроля разработки над OpenSource-проектами есть одна простая проблема – человек говорит о том, что берет на себя эту задачку и... пропадает. Это проблема любого OpenSource-проекта, потому что никто никому ничего не должен. Ты вроде обещал, что сделаешь, и тебя потом либо гложет ответственность за обещание, которое ты дал другим людям, которых ты, возможно, даже никогда в жизни не видел, и ты заставишь себя сидеть по выходным, чтобы что-то сделать. Либо ты просто занимаешься своими делами, а потом кто-нибудь через месяц вспоминает о том, что у нас была такая фича, вот тот человек хотел ее сделать, но что-то он молчит, давайте тогда этим займусь я. Это проблема у нас не решается никак. Такие люди периодически появляются и пропадают. Но сейчас у проекта столько задач, что провал по какой-то одной из них практически незаметен в общем облаке всех задач, которые нужно реализовать.
А в плане управления – конкретно на этих проектах у нас применяется достаточно типичная для GitHub практика – раздел Issues. Это задачки, которые создаются на GitHub. Я для себя прорабатываю систему тегирования. Сейчас активно тренируюсь как раз на проекте BSL LS. Когда задачки разделяются по компонентам – о том, что эта задача – про форматирование, эта – про автодополнение, а эта – про диагностики. Это – первый тип категоризации. А второй тип категоризации – это сам тип задачи – это улучшение, ошибка, какой-то провал по производительности. И даже этих двух тегов уже хватает для того, чтобы людей, которые приходят в проект с горящими глазами «я хочу что-то сделать» – быстренько направить. Например, человек хочет пилить диагностики – пусть отбирает задачи в GitHub по диагностикам, и сам уже решает – либо чинить найденные ошибки, либо делать новые диагностики. Кто-то говорит: «Мне не нравится, как форматирование работает, оно не учитывает мои потребности». Вот тебе тег, разбирайся. Когда я начинал работать еще над плагином для Visual Studio Code, я откровенно подсел на плагин к браузеру Chrome – инструмент по работе с задачами под названием ZenHub. Это на тот момент для меня ZenHub показался прорывной штукой, которая добавляла на GitHub что-то типа канбан-доски с возможностью создания колонок – произвольного количества, с быстрым перетаскиванием, с удобными возможностями по управлению задачами. Там можно было делать канбан-доски, состоящие из нескольких проектов. И это было очень удобно за исключением одной большой проблемы – кроме как именно в моем браузере с поставленным расширением я эти задачи в таком виде больше не мог видеть нигде. Я захожу с телефона на доску, а у меня там ничего нет – есть только плоский список замечаний, в котором я уже перестаю ориентироваться.
Мобильного приложения у ZenHub нет?
Возможно, сейчас что-то появилось, я перестал следить за разработкой. Я на нем сидел около двух лет. Они мобильного приложения не добавляли, и планов его добавить вроде как не было.
Сейчас я пользуюсь такой штукой, как Glo. Это – разработка компании Axosoft, которая делает git-клиент GitKraken. Сам git-клиент мне тоже очень нравится, я им тоже пользуюсь. Он бесплатен при разработке открытого программного обеспечения – если вы размещаете свои разработки где-то на GitHub, вы можете использовать для этого GitKraken. А если у вас in-house или Enterprise разработка – то нужно заплатить определенную денежку. Я честный, я плачу, потому использую GitKraken везде – и в OpenSource, и в закрытой разработке. Так вот, Axosoft сделали свой вариант канбан-доски для управления задачами – это как раз Glo. Он тоже сейчас бесплатен для открытых проектов. Я потихоньку стараюсь его настраивать и доводить до того вида, как это было на ZenHub. Приятно, что разработчики Axosoft прислушиваются к мнению сообщества и добавляют возможности, которые у них просят. Несколько запросов на улучшение функциональности им подавал и я. И они действительно их выполняют. Я понимаю, что это я не один такой, видимо, это был популярный запрос от сообщества, но приятно, когда ты с разработчиками инструмента на одной волне. Когда выходит новый релиз, я с интересом читаю чейнджлоги, потому что практически каждый второй релиз появляется фича, про которую я думаю: «О, вот это я хотел! И это они добавили! Здорово, молодцы!». И сейчас для управления задачами я пересаживаюсь на Glo. Это также канбан-доска с колонками, дополнительно помогают вышеозвученные теги. Единственное, там пока не поддерживаются майлстоуны, которые в GitHub используются для релизного управления и планирования. Но, опять-таки, написал на support и они ответили что-то в духе: «Хей, мы добавили ваш голос к этому фиче-реквесту, наши разработчики очень активно на него смотрят!». Приятно, когда у компании, которая разрабатывает продукт, есть поддержка, которая прислушивается к мнению сообщества.
Практически сразу после интервью вышел новый релиз Glo, в котором была добавлена поддержка майлстоунов GitHub.
А этот продукт работает и на мобильном телефоне в том числе?
Да, у них есть, насколько я помню, три варианта работы. Первый – это StandAlone-приложение, которое ставится на компьютер. Оно написано на базе electron, соответственно, работает на Mac, Linux, Windows – без каких-либо проблем, шустренькое. В каждом релизе они его улучшают и ускоряют. Также у них есть веб-версия. На мобильных браузерах эта веб-версия работает, но там есть определенные проблемы с перетаскиванием карточек между колонками. Мне кажется, разработка любого инструмента, в котором нужно реализовать перетаскивание пальцем на маленьком экране – достаточно сложная задача. И в мобильной веб-версии это работает действительно не очень хорошо. Впрочем, у них есть отдельные мобильные приложения для Android и iOS. И там эта проблема решена, там все действительно удобно, красиво и быстро. Рекомендую.
А если вернуться в мир 1С – расскажите, какими решениями вы пользуетесь в своей обычной работе?
У нас в отделе, где я работаю, используется две системы учета задач – это RedMine (на нем сидит большая часть отдела), и GitLab, который продвигаю я. Так получилось, что я пришел в отдел с наработанным стеком инструментов, и части людей, работающих со мной на проектах, приходится пользоваться ими (смеется). В GitLab мы работаем не только с кодом 1С (у нас настроена синхронизация хранилища с помощью gitsync), мы там также ведем задачи. Там есть канбан-доска, задачи приоритезируются, тегируются – разработчики заходят в GitLab, смотрят задачи, берут их себе в работу, говорят о том, когда они их выполнили, передали на тестирование и т.д.
Сейчас, наверное, GitLab – это центр знаний о проектах, которыми я занимаюсь. Там можно посмотреть статусы по задачам, там живут все разработчики, там живу я. Когда какие-то вещи проектирую, описываю, я точно так же создаю новую задачку на GitLab, расписываю детально, что я хочу видеть, потом это можно уже декомпозировать до каких-то подзадач. В платной версии GitLab есть эпики, которые позволяют это дерево как-то визуализировать. У нас используется бесплатная версия, но все равно связи между замечаниями есть, и это тоже один из основных инструментов работы.
В плане контроля качества все ожидаемо – SonarQube.
SonarQube – универсальное решение, которое действительно уже вошло в жизнь 1С-разработчиков, и его можно использовать вовсю?
Я стараюсь популяризировать это мнение. Рад его услышать от кого-то еще, кроме себя. На мой взгляд, это действительно удобный инструмент, который позволяет не только отслеживать качество, но и вести какую-то социализацию. Разработчики могут смотреть не только на свои ошибки, но и на ошибки, которые допускают другие сотрудники. Но конкретно в нашем случае (может быть, это своего рода достижение) – эти разработчики не ругаются друг на друга: «Ты написал плохой код, как ты мог, из-за тебя что-то упало». Нет, более опытные товарищи видят, что у человека проблема по обработке транзакций – они говорят: «У тебя явно что-то не так, почитай статью, вот тебе примеры, подходи, я тебе подскажу, как правильно писать. Да, SonarQube показал ошибку здесь и здесь, но есть еще и вот такие проблемы, через какое-то время они тоже выстрелят».
Это инструмент не только по отслеживанию своего плохого кода, по исправлению каких-то ошибок, но и инструмент обучения сотрудников и передачи знаний от более опытных товарищей к менее опытным. Это, на мой взгляд, неожиданный эффект от платформы по управлению техническим долгом.
Мне кажется, это даже такой инструмент по систематизации знаний.
Да. Каждое правило содержит описание, почему это плохо, и как сделать хорошо. Часть этой информации вытащена с ИТС (со ссылками, конечно же). Часть информации пишем сами. Например, недавно по запросу была разработана диагностика на недопустимость использования тернарного оператора. Человек постоянно сталкивался с проблемами при использовании тернарных операторов при сопровождении систем, при разработке, что в большинстве случаев это приносит больше вреда, чем пользы. Он попросил сделать отдельную диагностику со словами: «Я включу ее только у себя – пускай у всех остальных она будет выключена, но мне очень нужно». Разработали, написали какое-то описание, и теперь этот человек может не просто проверять своих разработчиков и говорить им о том, что не нужно использовать тернарник, но и там будет описание – почему его не нужно использовать, почему это может быть плохо, к каким проблемам это приведет. То есть, такое обучение с передачей знаний тоже постоянно ведется.
Причем, это передача знаний, которая доступна всем, кто скачает этот плагин – все эти правила встроены прямо в него?
Да, это прямо внутри Sonar-плагина. Можно просто открыть список правил, которые уже зашиты в плагине. Можно открыть какой-то модуль, посмотреть, какие замечания там сработали. И там есть кнопочка с тремя точками, на которую можно нажать и увидеть подробное описание сработавшего правила – почему это плохо, и как исправить. Мы стараемся вставлять релевантные ссылки не просто на какие-то авторитетные источники, но и на стандарты разработки – на ИТС есть раздел с методической поддержкой разработчиков, там есть раздел по стандартам.
Я всячески стараюсь всех разработчиков, которые есть в команде, заставить заходить на ИТС, чтобы они его читали. Регулярно слышу фразы: «О, я прочел статью. Оказывается, вот так не надо, потому что потому». И спрашиваю: «А откуда ты узнал?» «Да мне там сонар сказал, я по ссылке перешел, а потом по связанным ссылкам нашел такой стандарт, и я понимаю, что это поможет мне в работе, потому что я с этим сталкиваюсь, в моем коде это “стреляет”».
ИТС, на мой взгляд, очень хороший инструмент для разработчиков, потому что там собрано много методической информации и не только по разработке, но и по конфигурациям. Но в 1С-мире о портале знают, наверное, не все. Кто-то приходит и читает, кто-то считает, что ИТС – это диски надо развозить, никакого отношения к порталу не имеет. Но, тем не менее, если получается разработчика загнать на портал, в какую-то секцию по тому, чем он занимается (не важно, это разработчик или консультант, который умеет программировать), они выносят оттуда что-то новое. И их код, их отношение к работе, их знание какого-то конкретного продукта становится лучше. И эти ссылочки в замечаниях SonarQube – тоже в этом немного помогают (я надеюсь на это).
Действительно, это возможность передавать другим свои знания через такую систему гиперссылок. Давайте теперь немного поговорим про наш сайт – скажите, пользуетесь ли вы сайтом Инфостарт, какими разделами, сервисами?
Да, Инфостартом я пользуюсь давно, я зарегистрировался на нем даже раньше, чем меня официально приняли на работу. Когда я решал стажерские задачки, я краем уха услышал, что есть такой портал, где сидит много-много 1С-ников, и есть много полезной информации. Тогда в 2012 году, когда я пришел в 1С, я его открыл и удивился тому, как много информации, много разработок действительно есть в открытом доступе. Я не помню, была ли тогда система стартмани в том виде, в котором она есть сейчас – что-то у меня получалось скачать, что-то не получалось. Но там было много статей, и большая часть моего рабочего времени заключалась в чтении статей. Даже когда мне ставили какие-то самые простые задачи по разработке – по работе с регистрами сведений, по работе с ролями, с планами обмена – часть информации я читал на ИТС, а часть каких-то живых примеров и опыта людей по работе с теми или иными механизмами я почерпнул с Инфостарта.
Сейчас я тоже регулярно пользуюсь Инфостартом. Мне каждую неделю приходит рассылка о новых публикациях, новых статьях. Какие-то вещи я себе просто помечаю в закладки, чтобы потом почитать – или сразу читаю. Я нахожу там много полезных универсальных обработок. Я не работаю с какими-то известными типовыми конфигурациями, типа Бухгалтерии предприятия или Зарплаты – у нас достаточно узкая отраслевка, о которой на Инфостарте информации нет. И я оттуда могу использовать только универсальные решения. Но, тем не менее, даже то, что выкладывается – полезно и помогает в работе. Из последних открытий для меня стала управляемая консоль отчетов от Евгения Люлюка. Я наткнулся на нее еще когда там была версия 2.7. Очень открытый человек, открытый разработчик. Какие-то ошибки, которые я находил, буквально в течение одного-двух дней исправлял. И таких инструментов с разной степенью поддержки на Инфостарте действительно много, и они помогают в работе. Это действительно, портал, на котором можно найти много готовых решений, которые упростят мою работу, как разработчика.
Также на Инфостарте я периодически пишу статьи – примерно, раз в год. Кажется, время пришло писать следующую статью. И это тоже один из инструментов по передаче знаний от меня сообществу. Я вообще очень люблю рассказывать. Но Инфостарт – это один из ресурсов, когда я могу не на кухне с кем-то общаться и рассказывать о каких-то интересных вещах, о работе каких-то механизмов, но и написать статью, структурировать ее, сопроводить какими-то примерами, поделиться ей с миром, и сделать мир лучше. Я вообще считаю, что делать мир лучше – это самая главная цель в жизни каждого человека. И мой способ сделать мир лучше – это увеличивать знания и компетенции разработчиков. В данном случае, о платформе 1С, о том, как она работает, о том, как лучше писать код, о том, как контролировать качество, как улучшать это качество. И на этой ниве я работаю, и Инфостарт мне в этом очень помогает. Поэтому прекрасный ресурс, я буду продолжать им пользоваться, скачивать обработки и писать статьи.
Тема нашей конференции – это идеи. Вы уже много раз упоминали, что идеи возникают от живого общения, от чтения статей – каким образом вы вдохновляетесь, что вам помогает двигаться в нужном направлении?
Наверное, горящие глаза. Не все идеи рождаются у меня в голове, часть идей, которыми я загораюсь, я черпаю из диалогов с другими людьми. Не всегда это именно программисты, которые могут писать код и эту идею реализовать. Но они приходят ко мне и говорят – слушай, у меня есть такая клевая идея, можно сделать такую-то штуку, она будет делать хорошо. Я думаю над этим и соглашаюсь – правда же, прекрасная штука. И, к сожалению, не на все идеи хватает времени. Часть идей, к сожалению, забывается, хотя, наверное, стоило бы куда-нибудь их записывать и, может быть, кому-то передавать дальше по наследству, чтобы кто-то это в конце концов разработал. Часть же идей оседает в мозгу. Некоторые живут очень-очень долго.
Сейчас получается, что большинство реализованных за прошлый год идей были связаны с OneScript, со средой запуска скриптов, приложений на языке 1С, прошлый год для меня был очень плодотворным на разработанные библиотеки. Разработана библиотека для «заглушек» при использовании модульного тестирования. И, наверное, самая долгоживущая идея в моей голове из OneScript-овых библиотек – это библиотека под названием Entity.
Кто-то мне однажды сказал, что меня покусали джависты. Я тоже считаю, что меня в какой-то момент «покусала Java», мне действительно заходят те идеи, которые предлагаются Java-миром для разработки программных продуктов. И одна из концепций по разработке, которая применяется в Java по работе с базами данных – это так называемое Java Persistence API. Допустим, есть сущность «пользователь», у него есть имя, пароль, массив с правами, еще что-нибудь. Мы можем создать новый класс, обычно очень короткий – буквально 5-10 строк, в которых объявляем, как в структуре, поля класса. Потом через символ @ или, как в 1С, через амперсанд (в расширениях &Перед, &После, &Вместо, &НаКлиенте, &НаСервере) развешиваем специальные аннотации, которыми помечаем, что вот эти поля надо положить в БД в виде колонок, а вот это поле – это массив или таблица с такими-то типами значений. И Java-магия берет описание этого класса, и сама как-то складывает это в базу данных.
Я этой идеей заразился, потому что также в том году активно шел пиар OneScript.Web, как платформы для разработки веб-приложений, а любым веб-приложениям нужно где-то сохранять данные. Конечно, можно писать в текстовый файл или в JSON, но я устал от обработки файлов циклами, строками. Это боль. И хотелось какого-то объектного подхода, потому что в базе данных все равно хранятся сущности. Мы все привыкли работать со справочниками, документами, регистрами. Мы как 1С-ники уже на уровне подсознания думаем о том, что мы не строки в таблицу добавляем, а создаем новый документ, формируем новые проводки, которые потом будут работать в отчетах. Мы не думаем о том, как эти объекты хранятся на уровне СУБД. И эту же идею об ORM (Object Relational Mapping) – механизме связи между объектом и его хранением в реляционной базе, я захотел привнести в мир OneScript.
Эта идея жила у меня в голове порядка полутора лет. Я долго не мог понять, как же это сделать. И тут, опять-таки, помогло сообщество – несколько человек решили развить систему аннотаций, которая была в OneScript, и дали мне определенный толчок к тому, как это можно было бы реализовать. Причем на базе нового и совершенного необкатанного движка аннотаций, который «падал» и не мог обрабатывать все мои пожелания. Я постоянно писал Андрею Овсянкину о том, что у меня еще вот это не работает, а еще я хочу вот так, и этих вот возможностей мне мало.
Когда такие идеи рождаются в голове, и ты пишешь «сам для себя» – они чаще всего убираются в стол. Даже если ты ее реализовал, она тебя больше не радует. А когда идея прорабатывается вместе с сообществом – не важно, вы делаете какую-то новую библиотеку, которую использует несколько человек, или ты делаешь какую-то новую библиотеку для того же OneScript и ею пользуется хотя бы несколько человек в стране (я не говорю, что хотя бы в городе, на улице) – это очень заряжает. И кайф, который ты получаешь от наконец-то реализованной библиотеки, воодушевляет тебя на разработку чего-то нового – на развитие функциональности, которую ты уже заложил в библиотеку, на добавление каких-то новых фич. И на этом порыве воодушевления ты понимаешь, что сейчас есть вот еще такая идея и, о! я, наконец-то придумал, как ее реализовать. Получается бесконечный круг, и ты на этом воодушевлении живешь-живешь-живешь. Это как допинг – что-то сделать, порадоваться, сделать новое, порадоваться.
Идея – это ключевой толчок, который позволяет тебе в это состояние попасть и, что неожиданно, развиваться. Когда ты сидишь в техподдержке, развиваться тяжело. Я ни в коем случае не хочу сказать, что на сопровождении грустно и уныло, хотя, на мой взгляд, там действительно грустно и уныло (смеется). Когда тебе приходят однообразные задачи о том, что нужно разработать какие-то типовые отчеты, которые уже «поперек горла», что нужно как-то обработать данные, их нужно определенным образом представить. О боже, сколько можно!.. В этом лично для меня нет драйва.
Те идеи, которые появляются, чаще всего связаны не с твоей областью знаний, не с той областью разработки, за которую ты ответственен просто на работе. Допустим, ты привык обмениваться с другими системами через файлики. И ты никогда не делал обмен через HTTP. А новая система обменивается не только через файлики, но и через HTTP. Хей, отличная идея – давайте сделаем все по-нормальному.
Идеи позволяют тебе смотреть на мир шире, изучать какие-то новые технологии, смотреть, как похожие идеи делаются в других языках, например. И это в конечном итоге тоже позволяет тебе обучаться, узнавать что-то новое. И твой уровень познаний – и в платформе, как в 1С-платформе, и в окружающих инструментах, тоже повышается – просто за счет того, что тебе в голову приходит что-то новое, оно остается, запоминается и, опять-таки, продолжает тебя продвигать все дальше-дальше-дальше, узнавать что-то новое. Какой-то такой у меня подход ко всему этому.
Какие у вас планы на ближайшее будущее?
Если говорить про OpenSource, то сейчас основные мои усилия прикладываются к развитию BSL Language Server. Причем, я понимаю, что я уже отхожу от разработки диагностик как таковых. Мы разработали ядро, которое могут использовать другие люди, они это ядро подхватили, и на его базе «пилят» новые диагностики. А я хочу вернуться к той изначальной идее, с которой я все это начинал. Конечная моя цель – это чтобы пользователь открыл редактор vim, и у него там заработало автодополнение кода 1С. Я знаю, что есть Language-клиенты для vim, для SublimeText, для Atom. Я уже пробовал запускать BSL Language Server в SublimeText – он там работает, что-то подсвечивает. И пока мне хочется распространить ту степень поддержки языка 1С и OneScript, которая есть в плагине для Visual Studio Code, на максимальное количество редакторов. Я не знаю, зачем мне это – скорее, просто интересно. Это такая идея, которая живет в моей голове, которая двигает меня дальше. И на текущий момент все мои мысли в OpenSource связаны с этим. Когда эта цель будет достигнута, придумаю что-то новое, буду разрабатывать что-то другое.
И заключительный вопрос – что вы посоветуете изучать начинающим разработчикам 1С?
Я, наверное, скажу очень неожиданную для большинства 1С-ников вещь – стажерам нужно учить стандарты разработки. Когда мы говорим про другие языки – про PHP, про Python, про Java – там все разработчики начинают вхождение со стандартов. Их отправляют читать PEP8 для Python, их учат, как программировать не то, что нужно бизнесу, а хотя бы, как программировать правильно. Понятное дело, что есть какие-то совсем базовые вещи – алгоритмы, структуры данных. Это разработчик должен знать в любом случае, даже типовой 1С-ник, который пишет партионный учет, пытается что-то вывести в дерево значений. Ведь он, на самом деле, работает с теми же самыми структурами данных (деревьями и списками), что и программисты на других языках. У него, например, могут быть хитрые правила сортировки по нескольким полям массива или табличной части, когда платформа не сможет сама это сделать правильно с точки зрения прикладной логики. Ему приходится писать сортировку «с нуля», и производительность этого кода у стажеров чаще всего просто катастрофическая, потому что у них этой базы нет. Кроме этого, их код ужасно выглядит, потому что они не знают стандартов разработки.
С чего нужно начинать всем 1С-никам? Зайти на ИТС в раздел «Методическое сопровождение разработчиков» и хотя бы прочитать ветку по стандартам разработки. Не все ляжет в голову – что-то вылетит. Но часть информации останется где-то на «подкорке». И, если старшие коллеги или какие-то автоматизированные инструменты будут постоянно возвращать к теме, как писать качественно, правильно, удобно, чтобы это было поддерживаемо, сопровождаемо, дорабатываемо, то и качество решений, которые будет предоставлять этот начинающий разработчик, будет лучше.
Любой специфике бизнеса, учета можно научить – по бухгалтерии, по управленческому, по финансовому учету есть куча книг. Всегда можно сказать: «На, читай!». И большинство знаний, которые разработчик или консультант получит из этой книги, улягутся у него в голове, он будет применять их в работе. Когда мы говорим про предметную область, подход «читай книги, применяй знания в работе» все считают нормальным. Потому что если мы говорим про консультантов, то как же мы будем внедрять зарплату, если мы не знаем, как зарплата рассчитывается? Мы сначала узнаем, как вообще это делается, какая под это есть правовая нормативная база, какие практики применяются в реальных организациях и т.д. И к программистам почему-то подход точно такой же – руководство говорит: «Вам надо внедрять бухгалтерию, учите бухгалтерию». Или: «Вам надо дорабатывать бухгалтерию – учите бухгалтерию, чтобы вы понимали, что такое план счетов, что такое субконто». Но программисты же в первую очередь программируют, а не ведут учет. Их почему-то не научили программировать!
Поэтому первое, что нужно делать – это изучить то, как правильно программировать на 1С. Помимо ИТС и ветки со стандартами, я рекомендую литературу, которую выпускает компания «1С». Это, в первую очередь, «Практическое пособие разработчика» Максима Радченко. Это книга, с которой я начинал свой путь в 1С, и которая действительно дает очень много информации для входа в профессию. Там как раз не написано о том, как нужно программировать, но там обзорно описаны большинство механизмов, которые есть в платформе, с которыми разработчику приходится сталкиваться.
Следом «Разработка управляемого интерфейса». Я помню неописуемую радость, когда я утром еду в метро, читаю «Разработку управляемого интерфейса» и понимаю, что та задача, которую я вчера делал пять часов, решалась одной галочкой. Если бы я прочел эту страницу буквально на день раньше, я бы сэкономил пять часов разработки. И эти знания кроме как от коллег, кроме как от книг, больше ниоткуда не получить. Либо самому разрабатывать.
И третья книга – это «Разработка сложных отчетов на СКД» Хрусталевой.
Это тот базис, который должен знать любой разработчик 1С, те механизмы, с которыми вы будете сталкиваться каждый день. Потом уже чаще всего идет разделение – кто-то уходит в интеграцию, обмен данными, работу с планами обмена, работу с HTTP-сервисами. Кто-то, действительно, уходит в расчетные задачи по зарплате, по бухгалтерии – и там уже без специфики и понимания учета будет сложно что-то сделать. Но базис – это программирование. Начинать нужно с этого.