...

пятница, 23 января 2015 г.

[Из песочницы] Почти правильная разработка на 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), TFS2013

2. OpenProject, Redmine

3. 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 http://ift.tt/1CJkSwP ./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 — это требование бизнеса и никуда от него не деться, в том числе за счет огромного внутреннего рынка проектов стран СНГ. Ну и, конечно же, за счет очень динамичного развития самой платформы. С другой стороны, проблемы НЕ качественных разработчиков присутствует везде, в не зависимости от языка/платформы, и это уже уводит нас в область психологии и ответа на вопрос «почему люди не развиваются и почему люди в большинстве своём не понимают своего места в ИТ мире». Но это тема другой статьи и других методик/инструментов.

Вместе с этим, как обычно, учитывая открытость лицензий, сообщество http://ift.tt/1CJkVIY открыто для новых идей и утилит в рамках концепции взвешенного подхода к 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: Быстро, дёшево и хорошо — выберите любые два и второй тезис Жизнь слишком коротка, чтобы делать что-то вручную.


Recommended article: Chomsky: We Are All – Fill in the Blank.

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.


Комментариев нет:

Отправить комментарий