Знаете ли вы, почему сейчас так модно внедрять 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С и более одного хранилища исходных кодов конфигурации для бизнеса, первые 2 проблемы качества, которые вы захотите решить:
- привязка изменения кода к задачам, для последующего разбора проблемных ситуаций;
- возможность быстрого code review, для выявления узких мест, до этапа развертывания у клиента/заказчика/etc.
1. Jira (Stash, Confluence), TFS2013
2. OpenProject, Redmine
3. Bitbucket, Github, Taiga.io
даже DevProm, и многое другое.
Как это работает?
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 в качестве средства мониторинга за файлом хранилища исходных кодов, мы получаем полную реплику истории разработки конфигурации в виде git репозитория.
а во-вторых — только у Git есть удобная концепция коллективной работы над множеством «контекстов» задач GitFlow, что для 1С специалиста является критичным, так как это позволяет управлять «хаосом требований от пользователя», не внося хаос в код.
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
0. Мы получаем текущие исходники конфигурации «для автоматизации торговли товарами» с нашего сервера исходных кодов git (полученный с помощью v83unpack);
1. Мы берем инструмент с проекта на github где ведётся его разработка и подключаем его в качестве дополнительного модуля git;
2. Копируем необходимые утилиты в сервисный каталог .git/hooks;
3. Копируем разработанную в 1С: Конфигураторе обработку в каталог с утилитами;
4. Помещаем в репозиторий и отправляем на сервер;
5. В репозиторий также автоматически помещается и исходный код утилиты.
Именно с помощью данного инструмента из обычной утилиты для 1С, это может стать целым проектом на github
Tool1CD — утилита для работы с хранилищами платформы без самой платформы
Одна из самых востребованных утилит в 1С мире, наряду с v8unpack-console, позволяет работать с хранилищами данных, как с базой данных, без платформы, в том числе и в консольном режиме. На ХабреДля1Сников — эта разработка входит в Top-20
Спектр применения данной утилиты широк:
- начинающие специалисты используют ее для починки и просмотра разрушенных баз данных во внутреннем формате платформы;
- а также, если знать что очень многие данные в temp каталогах платформа тоже хранит во внутреннем формате, то и для исследования временных данных платформы.
Что касается повышения качества разработки и разработчика, то тут наблюдается эффект синергии, за счет того, что хранилище исходных кодов 1С платформы — это тоже хранилище данных, именно с помощью Tool1CD происходит репликация в git репозиторий.
Итак, теперь у нас есть полная история работы всех 1C разработчиков в git репозитории, причем, заметьте, без отрицательного влияния на сам процесс обычного «кодинга» на платформе.
Перерабатываем процесс разработки, без потери скорости выпуска новой функциональности
Дальнейшее необходимо только в следующих случаях:
- Конфигурация 1С решения будет существовать в вашей зоне ответственности длительное время — от месяца и более;
- Вы пытаетесь внедрить у себя автоматизированное тестирование перед сдачей работ/системы внутреннему или внешнему заказчику;
- Вы просто ИТ перфекционист.
Инженеры DevOps очень любят Chef, puppet, но совершенно не любят 1С, поэтому мы начинаем сами автоматизацию собственной деятельности.
1Script — уже известный проект на Хабре. Чтобы не повторять статью EvilBeaver, скажу лишь, что текущий результат в виде DSL языка для автоматизации работы «обычных» 1С специалистов выглядит таким образом:
xUnitFor1C — разработка через тестирование на 1С. Наиболее интересный с точки зрения повышения качества проект — так как дает максимальный эффект. Фактически является реализации спецификации xUnit с учетом специфики 1С, и требует отдельной публикации (которая будет следующей после нынешней). Ключевое, что здесь можно отметить — внедрение разработки через тестирование (TDD на 1С) требует наиболее высоких затрат не первом этапе: эффект наблюдается не ранее чем через 1.5 месяца.
Snegopat — свой ReShaper и не только.
Но для того, чтобы запустить практику использования вышеуказанных инструментов, большинство специалистов 1С начинают с проектов попроще:
v8Reader — помощник объединения при разрешении конфликтов в коллективной разработке
v8Viewer — помощник, встраиваемый в том числе в TortoiseGIT, для сравнения версий 1С конфигурации находящейся в git репозитории
Такой он, «мир eDSL», где главное автоматизация бизнес-процессов, а всё остальное микросервисы и микроутилиты, выпускаемый под лицензией 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 открыто для новых идей и утилит в рамках концепции взвешенного подхода к eDSL платформам — как раз без тех самых революций, о которых сказано в заголовке.
FAQ
Q: Причем здесь Agile?
A: eDSL за счет концепции в принципе «сам по себе Agile» (RAD платформа), в его концепции не заложено ничего про QA (управление качеством продуктов) — поэтому при внедрении гибкости на 1С, следует ключевое внимание обращать не на «демонстрацию заказчику», а больше на внедрение инженерных практик.
Q: Как это всё начать использовать? А то «наши 1С» специалисты @cencored@
A: Скачать, установить сервер сборок (Jenkins|Teamcity), запустить по ночам компиляцию решения («синтаксический контроль кода») с помощью скриптов 1Script. Поделиться с командой наработками. Настроить репликацию исходных кодов 1С в git. Прийти на AgileDays2015 — посмотреть как использовать статические анализаторы кода.
Q: А сколько денег это стоит?
A: Лучше подумайте сколько это экономит на длинный проектах 1С.
Q: Но это не соответствует стандартам 1С?
A: Эти инструменты автоматизируют стандарты и расширяют их. В большинстве проектов на github вы найдете прямые ссылки на информационно-техническое сопровождение и базу знаний 1С.
Q: Зачем всё это нужно?
A: Быстро, дёшево и хорошо — выберите любые два и второй тезис Жизнь слишком коротка, чтобы делать что-то вручную.
Автор: alexey-lustin
