[Из песочницы] Почти правильная разработка на 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С и более одного хранилища исходных кодов конфигурации для бизнеса, первые 2 проблемы качества, которые вы захотите решить: привязка изменения кода к задачам, для последующего разбора проблемных ситуаций; возможность быстрого code review, для выявления узких мест, до этапа развертывания у клиента/заказчика/etc. про системы управления задачами Глупо считать, что в среде 1С специалистов нет систем управления задачами. На текущий момент мне известно, что есть прецеденты промышленного использования:1. Jira (Stash, Confluence), TFS20132. OpenProject, Redmine3. Bitbucket, Github, Taiga.ioдаже DevProm, и многое другое.
Как это работает?
C:\Program Files\1cv82\8.2.15.319\bin\1cv8.exe ENTERPRISE /F«C:\Users\admin\.jenkins\workspace\runTest1C\build\ibService» /Nadmin /P1 /DisableStartupMessages /Execute«C:\Users\admin\temp\ВыгрузкаКонфигураций.epf» /C«decompile; pathToCF; C:\1cv8.cf; pathOut; C:\repo\git\src; auto; out; C:\Users\admin\.jenkins\workspace\runTest1C\outExport.txt;» Используя plugin сервера сборок Jenkins в качестве средства мониторинга за файлом хранилища исходных кодов, мы получаем полную реплику истории разработки конфигурации в виде git репозитория.
Теперь «старшие товарищи» всегда видят некачественный код или не учитывающий подходов к правильной разработке
почему кстати Git во-первых — только Git выдерживает объем исходных кодов ERP 2.0а во-вторых — только у 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С, база данных продолжает находится на компьютере формата «под столом» разработчика. Обычно я для аналогии пытаюсь привести пример из мира sqlite — представьте себе, с каким количеством проблем вы столкнетесь, если начнете использовать sqlite в качества средства хранения данных в системе с количеством одновременно работающих пользователей скажем 10 и размером базы от 1 Gb. Для желающих изучить это полезный, но болезненный опыт, начинать следует с того, что конкурентный доступ в таком случае крайне желателен в формате «много читающих — один пишущий». Что касается повышения качества разработки и разработчика, то тут наблюдается эффект синергии, за счет того, что хранилище исходных кодов 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.
где PHP? Обращаю Ваше внимание, что у меня предвзятое отношение к PHP, поэтому я Вам не могу дать ссылки на продукты, работающие с PHP в едином стиле учитывая возможности и 1С, и PHP, объединяя плюсы обоих платформ: моё личное мнение, что PHP — это Personal Home Page tools и не уверяйте меня в обратном.
В качестве заключения В мире 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: Быстро, дёшево и хорошо — выберите любые два и второй тезис Жизнь слишком коротка, чтобы делать что-то вручную.
