Почти правильная разработка на 1С, без революций

Знаете ли вы, почему сейчас так модно внедрять Agile/Scrum/Kanban в командах разработки? Если быть совсем и до конца честным, то внедрение гибких методик разработки преследует только одну цель — приблизить команду к пользователям продукта. Сделать так, чтобы разработчики каждые две недели задумывались не о паттернах проектирования, не о том, выбрать ли для реализации нового, интересного алгоритма LinkedList, или всё таки будет достаточно ArrayList, а также не о том, какая крутая технология protobuf или не включить ли вам в проект ZeroMQ; а о том, какая от этого польза будет работающим на предприятии операторам на складе, грузчикам и водителям, токарям в цеху и продавцам-кассирам в магазине. В SCRUM обычно это называется двумя терминами Minimal Valuable Product и Bussiness Value. По большому счету, дело не в моде, а в эффективности, без ущерба комфорту обеих сторон — бизнеса и ИТ команды.

Теоретическая вводная

Прежде чем вы начнете рассказывать свои «истории неуспеха с 1С», попробую немного рассказать про DSL языки. А точнее — про концепцию «проблемно-ориентированных языков».

Domain Specific language, DSL — «предметно-специфичный язык») — язык программирования, специализированный для конкретной области применения, является ключевым понятием языково-ориентированного программирования.

Любой новый язык в мире (будь-то PHP, ruby, python, Erlang, LISP, Closure или 1С) изначально создавался в качестве ответа на проблему. То есть если вы серьезно собираетесь изучать какой-либо язык или «фреймворк», вам необходимо вспомнить, «для чего» автор его создавал, вспомнить, что «не нравилось» автору в других платформах. В этом смысле, например, интересна история, как появился тот же Node.JS. Изначально хотелось сделать простой способ создания масштабируемых сетевых серверов, во что это выродилось в итоге, уважаемое читатели, я думаю, и так знает.

Поэтому я расскажу о проблеме «автоматизации бизнес-процессов» и появлении Business DSL.

Enterprise DSL(eDSL) или Business DSL (bDSL)

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

Много людей, которые формируют множество пожеланий — все хотят автоматизации

select * from * as requirements

. Уходишь писать на C|C++ на три месяца, а они вечно чего-то требуют и не дают спокойно поработать. Вместе с этим большинство бизнес требований во-первых давно известны, во-вторых оперируют конечным количество объектов: «Ввести вводную справочную информацию, зафиксировать чего-нибудь, рассчитать чего-нибудь, вывести отчет о результатах расчета чего-нибудь» и большего как-бы не нужно.

Если, согласно ТРИЗ, идеальная система — это система, которой нет, а функции её выполняются, то идеальный DSL язык для этого казался примерно таким:

Почему на русском, спросите вы? Да потому что так формулирует пользователь (а большинство наших пользователей живут на территории exUSSR). В итоге мы не теряем времени на формулировку требований и преобразование их к стандартам разработки, где разработка ведется на английском языке. Единый словарь — мало затрат на адаптацию. Эффективно же?

Как вы понимаете, в итоге даже сам пользователь может себя немного автоматизировать, если в школе изучал Basic. C таким вот посылом и создавалась обсуждаемая нами платформа, хотя как было в реальности — знают только её авторы. Дальше по тексту я буду называть эту платформу, иногда 1С, а иногда eDSL., чтобы вы привыкли к обоим понятиям и понимали, что я имею ввиду именно платформу, а не юридических лиц.

Повышение качества разработок и уровня разработчика

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

Для того чтобы, ни в коем случае не терять скорость разработки конечных бизнес-систем, и сделать так, чтобы это было лучше (стало хорошо), единственное, что мы можем делать — это начинать делать НЕ дешево. А денег, как вы понимаете, нет, точнее их никто выделять пока не будет на повышение качества «некой» платформы, которая как-бы подразумевает, что в ней и так «всё качественно» (согласно маркетинговым материалам). Поэтому единственное, где мы можем увеличить затраты — это либо в зоне разработки инструментария для 1С платформы, либо в зоне развития навыков специалистов 1С. Собственно, как только мы начинаем задумываться о качестве решений, мы начинаем, как и все ИТ специалисты, пытаться ускорить/упростить наш процесс разработки, не теряя при этом эффективности для бизнеса. Как вы понимаете, такого функционала в платформе для бизнеса не будет — она же платформа для бизнеса, а не для разработчика.

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

Коллекция помощников в работе с исходными кодами

v83unpack (v8unpack-console) — выгрузка в удобном формате текущей разрабатываемой конфигурации

Когда у вас более одного разработчика 1С и более одного хранилища исходных кодов конфигурации для бизнеса ^[6], первые 2 проблемы качества, которые вы захотите решить:

• привязка изменения кода к задачам, для последующего разбора проблемных ситуаций;
• возможность быстрого code review, для выявления узких мест, до этапа развертывания у клиента/заказчика/etc.

Как это работает?

C:Program Files1cv828.2.15.319bin1cv8.exe ENTERPRISE /F"C:Usersadmin.jenkinsworkspacerunTest1CbuildibService" /Nadmin /P1 /DisableStartupMessages /Execute"C:UsersadmintempВыгрузкаКонфигураций.epf" /C"decompile;pathToCF;C:1cv8.cf;pathOut;C:repogitsrc;auto;out;C:Usersadmin.jenkinsworkspacerunTest1CoutExport.txt;"

Используя plugin сервера сборок Jenkins ^[7] в качестве средства мониторинга за файлом хранилища исходных кодов, мы получаем полную реплику истории разработки конфигурации в виде git репозитория.

Теперь «старшие товарищи» всегда видят некачественный код или не учитывающий подходов к правильной разработке ^[8]

precommit1c — фиксация внешних инструментов в git репозитории в виде исходников

Неправильно считать, что работа обычного разработчика идет только с хранилищем 1С, проблема качества в том числе возникает оттого, что большинство разработчиков пишет очень большое количество маленьких утилит в виде внешних файлов, предназначенных для запуска в среде платформы. Когда у вас один разработчик, тогда для версионирования Вас спасает Dropbox/YandexDisk/GoogleDrive/etc, но когда вы работаете в команде — тут опять нас спасает git и внутрикорпоративный или внешний git репозиторий.

Работа идет через клиентские «хуки» git и «внезапно» требует Python (хотя можно и на bash):

git clone ssh://git@dev.example.org/operational-managment/goods-trade ./my-goods-trade
git submodule add https://github.com/xDrivenDevelopment/precommit1c ./my-goods-trade/vendors/precommit1c
cd ./my-goods-trade/vendors/precommit1c
exec copy-to-hook.cmd
cd ../../
mkdir utils && cp /cygdrive/d/epfs/ТолькоЧтоСозданнаяОбработка.epf ./utils
git commit ТолькоЧтоСозданнаяОбработка.epf -m ‘это очень важная обработка’
git push --all

Именно с помощью данного инструмента из обычной утилиты для 1С, это может стать целым проектом на github ^[11]

Tool1CD — утилита для работы с хранилищами платформы без самой платформы

Одна из самых востребованных утилит в 1С мире, наряду с v8unpack-console, позволяет работать с хранилищами данных, как с базой данных, без платформы, в том числе и в консольном режиме. На ХабреДля1Сников ^[12] — эта разработка ^[13] входит в Top-20

Спектр применения данной утилиты широк:

• начинающие специалисты используют ее для починки и просмотра разрушенных баз данных во внутреннем формате платформы;
• а также, если знать что очень многие данные в temp каталогах платформа тоже хранит во внутреннем формате, то и для исследования временных данных платформы.

Что касается повышения качества разработки и разработчика, то тут наблюдается эффект синергии ^[15], за счет того, что хранилище исходных кодов 1С платформы — это тоже хранилище данных, именно с помощью Tool1CD происходит репликация в git репозиторий.

Итак, теперь у нас есть полная история работы всех 1C разработчиков в git репозитории, причем, заметьте, без отрицательного влияния на сам процесс обычного «кодинга» на платформе.

Перерабатываем процесс разработки, без потери скорости выпуска новой функциональности

Дальнейшее необходимо только в следующих случаях:

• Конфигурация 1С решения будет существовать в вашей зоне ответственности длительное время — от месяца и более;
• Вы пытаетесь внедрить у себя автоматизированное тестирование перед сдачей работ/системы внутреннему или внешнему заказчику;
• Вы просто ИТ перфекционист.

Инженеры DevOps очень любят Chef, puppet, но совершенно не любят 1С, поэтому мы начинаем сами автоматизацию собственной деятельности.

1Script — уже известный проект ^[16] на Хабре. Чтобы не повторять статью EvilBeaver ^[17], скажу лишь, что текущий результат в виде DSL языка для автоматизации работы «обычных» 1С специалистов выглядит таким образом:

xUnitFor1C — разработка через тестирование на 1С. Наиболее интересный с точки зрения повышения качества проект — так как дает максимальный эффект. Фактически является реализации спецификации xUnit с учетом специфики 1С, и требует отдельной публикации (которая будет следующей после нынешней). Ключевое, что здесь можно отметить — внедрение разработки через тестирование (TDD на 1С) требует наиболее высоких затрат не первом этапе: эффект наблюдается не ранее чем через 1.5 месяца.

Snegopat — свой ReShaper и не только.

Но для того, чтобы запустить практику использования вышеуказанных инструментов, большинство специалистов 1С начинают с проектов попроще:

v8Reader — помощник объединения при разрешении конфликтов в коллективной разработке ^[19]
v8Viewer — помощник, встраиваемый в том числе в TortoiseGIT, для сравнения версий 1С конфигурации находящейся в git репозитории ^[20]

Такой он, «мир eDSL», где главное автоматизация бизнес-процессов, а всё остальное микросервисы и микроутилиты ^[21], выпускаемый под лицензией Apache Licence 2.0

Чтобы жизнь «малиной не казалась»

Давайте еще расширим свой кругозор в части гетерогенной разработки:

1С+OpenStack — отношение к 1С как к «пакету» для облачной платформы

1С+Docker — отношение к 1С как к «коллекции контейнеров».

Ну и конечно 1C+ logstash/kibana/elasticsearch — кроме просто журналирования, используется в том числе для BI.

В качестве заключения

В мире 1С разработчиков — я очень вас прошу обратить внимание именно на слово «разработка», как альтернативу словам «консультация и внедрение» — давно уже нет чистых специалистов 1С. Это, скажем так, миф из 2000-ых. Большинство программистов, кто профессионально создаёт решения на платформе 1С, «в базе своей» уже имеют один из старших языков: Java, C# или ruby, python — это требование бизнеса и никуда от него не деться, в том числе за счет огромного внутреннего рынка проектов стран СНГ. Ну и, конечно же, за счет очень динамичного развития самой платформы. С другой стороны, проблемы НЕ качественных разработчиков присутствует везде, в не зависимости от языка/платформы, и это уже уводит нас в область психологии и ответа на вопрос «почему люди не развиваются и почему люди в большинстве своём не понимают своего места в ИТ мире». Но это тема другой статьи и других методик/инструментов.

Вместе с этим, как обычно, учитывая открытость лицензий, сообщество github.com/xDrivenDevelopment ^[22] открыто для новых идей и утилит в рамках концепции взвешенного подхода к eDSL платформам — как раз без тех самых революций, о которых сказано в заголовке.

FAQ

Q: Причем здесь Agile?
A: eDSL за счет концепции в принципе «сам по себе Agile» (RAD платформа), в его концепции не заложено ничего про QA (управление качеством продуктов) — поэтому при внедрении гибкости на 1С, следует ключевое внимание обращать не на «демонстрацию заказчику», а больше на внедрение инженерных практик.

Q: Как это всё начать использовать? А то «наши 1С» специалисты @cencored@
A: Скачать, установить сервер сборок (Jenkins|Teamcity), запустить по ночам компиляцию решения («синтаксический контроль кода») с помощью скриптов 1Script. Поделиться с командой наработками. Настроить репликацию исходных кодов 1С в git. Прийти на AgileDays2015 — посмотреть как использовать статические анализаторы кода ^[23].

Q: А сколько денег это стоит?
A: Лучше подумайте сколько это экономит на длинный проектах 1С.

Q: Но это не соответствует стандартам 1С?
A: Эти инструменты автоматизируют стандарты и расширяют их. В большинстве проектов на github вы найдете прямые ссылки на информационно-техническое сопровождение и базу знаний 1С ^[24].

Q: Зачем всё это нужно?
A: Быстро, дёшево и хорошо — выберите любые два и второй тезис Жизнь слишком коротка, чтобы делать что-то вручную.

Автор: alexey-lustin

Источник ^[25]