Аннотация. Статья является первой (будем надеяться) в цикле, повествующем о тех концептуальных и практических аспектах платформы «1С: Предприятие», которые представляются автору интересными и очень важными, но пока еще не нашедшими четкого отражения в технической публицистике. Автору (который является экспертом по разработке на платформе 1С с более чем двадцатилетним стажем) захотелось заполнить эти лакуны.

В рамках первой статьи цикла будет дан небольшой обзор возможности платформы «1С: Предприятие» говорить сразу на двух языках разработки программного кода. Также будет произведена попытка разобраться, почему было сделано именно так, и какие преимущества нам, как разработчикам, дает такая функциональная возможность, но не обойдется и без пары довольно наглядных примеров.

Вступление будет кратким. Есть миф, и для того, чтобы его сформулировать, много слов не понадобится. А вот на развенчание мифа слов потребуется немало (можно считать маленьким дисклеймером – букв будет много).

Формулировка мифа. Считается, что инженеры, занятые задачами разработки бизнес-приложений на платформе «1С: Предприятие», вынуждены и просто обязаны писать программный код на русском языке. Это первая часть мифа. Вторая часть – программный код на русском – это очень забавно и совсем несерьезно, а самое главное, непонятно – зачем.

Первую часть мифа можно прикончить одним очень коротким и злым словом, но мы проявим инженерную вежливость и возьмем формулировку из лексикона дипломатов – «Это не совсем точные сведения». А именно – с момента своего рождения на свет платформа «1С: Предприятие» позволяла писать программный код на одном из двух языков – на русском и на английском. У встроенного языка есть два полноценных и равноценных наречия.

В качестве аналогии из окружающего нас мира можно посмотреть на Канаду, можно посмотреть на Бельгию, а можно еще на самые разные страны, где в ходу более одного языка. И здесь следует точно знать – наличие английского наречия в языке платформы 1С – это не какие-то усилия по остаточному принципу, паритет двух наречий соблюдается крайне строго, уж поверьте на слово человеку, который не просто работал с этой платформой большую часть сознательной профессиональной жизни, но и видел всю кухню изнутри.

Надеюсь, с вопросом – позволяет ли платформа «1С: Предприятие» программировать на английском – здесь должна наступить полная ясность. Еще как позволяет.

Но нужно пояснить одну очень важную техническую деталь. Да, платформа требует для каждой конкретной конфигурации (термин «Конфигурация» здесь используется в том же значении, что и «Проект» для других языков и сред разработки) явно указать вариант встроенного языка – русский или английский, но это указание вовсе не диктует необходимость написания программного кода только в этой указанной нотации. Свойство «Вариант встроенного языка» используется платформой для некоторых методов и свойств, которые возвращают определенные системные имена (термы) на том языке, который указан в свойствах конфигурации как основной язык разработки.

Здесь следует отдельно пояснить, что у конфигурации существует и другое «Лингвистическое» свойство, определяющее основной язык конфигурации. Но это не язык разработки, а язык интерфейса, то, что в операционных системах называется термином «Локаль». Платформа 1С поддерживает только два языка для написания программного кода, а вот для интерфейса поддерживается множество языков, и при желании можно сконструировать даже свой собственный. То есть, «Интерфейс на валирийском или дотракийском» – это, конечно, шутка, но технически вполне реализуемая.

Вернемся к языку разработки. Вне зависимости от варианта, выбранного для конкретной конфигурации, ее программный код может быть написан как на английском, так и на русском, и более того, интерпретатор языка прекрасно справляется и со смешанной нотацией.

Понятно, что у каждого разработчика существуют свои персональные предпочтения. Например, лично я еще на версии 7.7 в самом конце девяностых и начале нулевых писал строго по-английски. А вот потом, с течением времени, перешел на русскую нотацию. Почему и для чего – об этом чуть ниже. Сперва давайте посмотрим на пример кода.



Программный код здесь синтетический, хотя и похож на промышленный. В промышленном коде уровней стека было бы чуть больше.

Что делает приведенный в этом примере код? Очень простую вещь – получает прокси веб-сервиса сторонней системы, а дальше сперва вызывает метод этого стороннего веб-сервиса, а затем внутренний метод для проверки полученного из внешней системы результата. Можно увидеть, что англоязычную лексему мы пишем там, где обращаемся к системе, умеющей разговаривать только по-английски. Весь остальной код – строго кириллический. И это не требование заказчика, не требование стандарта или регламента, это личный выбор разработчика.

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

И теперь мы переходим к вопросу – если можно выбирать один из двух вариантов языка для написания нашего программного кода, какими критериями мы будем при этом руководствоваться? И существует ли относительно четкая инженерная методика, которая позволяет нам без лишних творческих метаний выбрать между Рус/Eng?

Разумеется, такая методика есть. Первый критерий – что по этому поводу написано в требованиях, регламентах, стандартах, которые мы должны использовать при разработке вот этого конкретного программного кода. Если мы не являемся его владельцем, если существуют внешние факторы, они имеют превалирующее значение над всеми другими.

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



Да, это не язык Шекспира, в том смысле, что мой уровень владения английским, мягко говоря, невысокий. Может хромать даже орфография, а уж грамматика хромает точно, и нет уверенности, что в приведенном выше примере комментарий написан без нарушения правил английского правописания. Но если уж на чистоту, и если подсчитать количество фрагментов, написанных не на языке Шекспира, которые я видел в своей жизни в самых разных языках и средах разработки, я бы давно сбился со счета.

Важно, что написанный нами код (включая комментарий) работает, эффективно решает порученную ему задачу и поддается успешному сопровождению специалистами другой языковой группы. Это был крайний случай, когда решение принимаем не мы самостоятельно, а его диктуют нам внешние факторы. Такие ситуации бывают, но не очень часто.

Вполне естественным образом возникает вопрос, программный код – это всего лишь текст, причем далеко не литературный, а технологический и строго формализованный. Неужели не существует способа выполнить машинный перевод программного кода с одного языка на другой?

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

Ответ, также вполне естественный – среди довольно обширного набора инструментов разработки, доступных программисту, работающему с платформой 1С, такой инструмент есть.
Это называется Language Tool и технически представляет собой плагин к EDT (аббревиатура из профессионального сленга вселенной 1С, «Enterprise Development Tools», среда разработки нового поколения, но рассказ о EDT и других инструментах разработки, включая Language Tool, все же выходит за рамки статьи и требует отдельного обзора, здесь достаточно будет только упомянуть, что инструмент прямого и обратного преобразования программного кода между русской и английской нотацией существует).

Продолжим разбор методики выбора. На месте специалиста, который не просто пишет программный код, но, например, отвечает за общие архитектурные решения, за технологию разработки на проекте, и в конечном итоге за результат разработки в целом – лично я выберу именно русскую нотацию. Почему?

И тоже довольно важный момент – если мы пишем не для внешнего, а для внутреннего рынка, если в наших планах тиражирование программного кода на территории проживания людей, для которых русский является родным – это фактор из категории превалирующих. Специалисты, которые будут сопровождать и развивать наш программный код, должны обладать возможностью общаться с нами без дополнительных переводчиков и связанных с этим ошибок перевода.

Прежде всего мы имеем в виду предметную область. При помощи платформы «1С: Предприятие» мы в первую очередь решаем задачи автоматизации процессов бизнеса. (Но в скобках заметим, что технологические возможности платформы этим кругом задач отнюдь не ограничиваются, но это уже тема немножко другой беседы).

А в задачах автоматизации экономических процессов одним из ключевых факторов успеха является общее для всей команды «Постановщик, разработчик, эксплуатант, пользователь» понимание особенностей предметной области так, чтобы мы могли разговаривать на одном языке.

Пользователь вряд ли когда-нибудь будет читать наш программный код, но он совершенно точно будет читать надписи на формах, пояснения, сообщения и (здесь многие мне не поверят, но это истинная правда) нашу техническую документацию. А вот специалисты, занятые на задачах эксплуатации, поддержки, сопровождения и развития нашего программного кода, читать его будут и очень внимательно.

А теперь давайте произведем небольшой мысленный эксперимент. Возьмем приведенный выше фрагмент наглядного пособия и уберем из него описывающий функцию комментарий. Получится вот так:



Разумеется, это наглядное пособие из серии «Как делать не нужно», потому что в промышленной разработке такие трюки, как неоткомментированный метод программного интерфейса, являются недопустимыми от слова «Совсем». Но именно как наглядное пособие и как пояснение к тезису «Программный код сам себя документирует» подойдет вполне.

И здесь очень важный момент. Термины предметной области, будь она огромной как отрасль или компактной как отдельно взятое предприятие, имеют строго определенное значение – перевод на другой язык, даже близкий и почти родственный, требует квалификации не только инженера-разработчика, но еще и филолога, потому что перевести нужно так, чтобы все остальные поняли.

Страховочным механизмом служит, разумеется, комментирование кода. И вот здесь мы включим абсолютно циничную инженерную истину – если нам помимо собственно программного кода приходится писать вдумчивые и раскрывающие смысл кода комментарии на другом языке, и объем этих комментариев составляет хотя бы тридцать процентов от общего, то простите мой французский, но примерно тридцать процентов нашего рабочего времени мы отправили туда, где всегда требуется бумага (притом что отпечатанный на ней текст совершенно неважен).

Дело здесь вот в чем. Если русскоязычный программист, занимаясь разработкой для русскоязычного рынка, пишет программный код по-английски, пояснять, а возможно даже пересказывать написанный код ему все равно придется на русском. И общий КПД работы над кодом по сравнению с вариантом «Сразу пишем по-русски, и надобность в подробном комментарии-пересказе отпадает сама собой» будет существенно ниже, возможно даже на десятки процентов.

Еще раз вернемся к примеру кода. Каждое слово понятно. Разумеется, непонятную и нечитаемую программу можно написать на любом языке, но если мы пишем на русском – вероятность того, что коллега нас поймет, увеличивается и довольно серьезно.

Спасибо теории вероятностей и другим базовым теориям нашего с вами ремесла. Документация может содержаться в самом коде. Именно та, которая нам самим же потребуется, когда перед нами будет поставлена задача – да вот зачем далеко ходить? Разобраться, почему информационная система работает, скажем вежливо, небыстро. Добавить новую функцию, которой раньше не было, и чтобы при этом ничего не сломалось. Имплементировать существующую систему управления учетом изменения бизнес-схемы, но так, чтобы базовые правила предметной области нашей новой системой не оказались бы нарушены. И – так далее, все те задачи, которые мы с вами решаем каждый день.

Не постесняемся повторить. Термины предметной области должны четко и однозначно трактоваться всеми, кто имеет отношение к жизненному циклу программного кода, оперирующего этими терминами. В некоторых других отраслях для решения подобной задачи пришлось изобретать свой специальный язык. Например, в морском деле (еще в том, настоящем, парусном) все сколько-нибудь значимые термины – это и не английский, и не голландский, а свой специальный морской язык, который был изобретен именно для однозначного общего понимания.

Мы не плаваем по морям, а пишем программный код, но проблема однозначности понимания для нас так же актуальна, как и для парусных матросов. Цена ошибки трактования термина может быть очень высокой. Перевести терминологию предметной области, увязанную, например, с терминологией типового или отраслевого решения, на английский язык так, чтобы это можно было однозначно прочитать «с листа» — задача очень сложная и даже не всегда имеющая решение.

В качестве маленького упражнения – попробуйте перевести на английский (только «на чистых руках», без Google Translate) следующую конструкцию: “Изменение в алгоритме расчета себестоимости производства по схеме переработки давальческого сырья при ее использовании для закрытия функциональных разрывов в учете гарантийных ремонтов”. А потом проверить, кто из коллег каким образом интерпретирует ваш вариант перевода.

Вот здесь мы приходим к понятию «Командная работа». Никто из нас не работает в одиночку, мы всегда работаем командой, а в командной работе очень важно говорить на одном языке, понятным каждому из нас без перевода, без лишних усилий. Под «Говорить» здесь, конечно же, понимается «Писать программный код».

Очень важно понимать, каждый из нас не просто программист-разработчик, творец-мечтатель. Все, что мы делаем, является решением конкретных и понятных нам задач. Мы помогаем нашему заказчику решать его задачи. И вот здесь мы должны четко знать – наши задачи не решаются в одиночку.

Для решения нашей задачи мы должны обладать возможностью общаться с коллегами. И так, чтобы это общение забирало у нас минимальное количество нашего рабочего временного ресурса и позволяло передать большой, максимально большой объем информации в единицу времени. Просто потому, что все наше время, которое мы тратим на наши рабочие задачи – это рабочее время. И наш инженерный принцип гласит – «Рабочее время должно затрачиваться эффективно».

Те инструменты, которые позволяют это делать, мы включаем в свой набор инструментария. Кириллическая русская речь, описывающая предметную область, позволяющая нам понимать друг друга без лишних деталей, лишних слоев, является одним из таких инструментов. И это не теория, это один из тех принципов, которые помогли лично мне не просто написать какую-то программу, но построить несколько систем уровня «Большая и по-настоящему, по-хорошему страшная информационная система».

Синонимом словосочетания «Командная работа» является слово «Взаимодействие» (или же «Collaboration»). Мы помним о том, что можем выбирать любое наречие. Базой взаимодействия в команде является сигнальная система. Мы подаем сигнал и реагируем на поданные нам.

Да, многие термины настолько точны и устоялись, что их проще и правильнее донести до товарищей языком оригинала, но у сигнальных систем есть один общий родовой недостаток. Чтобы обойтись без очень большого количества букв, пример будет крайне нагляден и прямо из моей жизни.

Представим себе взаимодействие в такелажной команде. У нас есть всего три рабочие специальности. Есть механик-водитель – его основная задача уже закончена, и сейчас ему нужно просто удерживать грузовоз в состоянии покоя. Есть крановщик, который очень-очень высоко, его задачей будет при помощи крана перегрузить десять тонн металлической конструкции с грузовоза на складскую площадку. И есть еще два товарища, профессия которых называется «Стропальщик». В их задачу входит организовать взаимодействие металлической конструкции с погрузочным (он же и разгрузочный) краном.

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

И вот здесь происходит сбой. Крановщик принимает строго противоположное решение и читает твой сигнал не так, а по-своему. Он это понимает как «Зацепили плохо, опусти, перетянем». И вместо «Вира» делает «Майна» (а это, соответственно, «Опускай!»), но уже не так медленно, а резким рывком.

Светлые идеи об удивительном мире сигнальных систем у тебя появятся потом, а пока есть какие-то доли секунды, чтобы увернуться от трех тонн падающего на тебя ржавого железа. Если успеваешь – понимание важности правильной трактовки сигналов приходит как будто из космоса.

Далее, разумеется, следуют производственные моменты, разбор ситуации, корректировка сигнальной системы с обязательной тренировкой на безопасном макете, ну – и так далее. Это уже обычная будничная работа.

И вот здесь мы подходим к одному из центральных моментов, ради которых и был написан этот текст. Не так важно, на каком именно языке мы говорим и пишем наш программный код. Гораздо важнее, чтобы мы – в команде, на предприятии, в отрасли – понимали друг друга с минимальными издержками на трансляцию смысла через текст. Тогда, и только тогда наша работа будет эффективной, а количество ситуаций «Что-то пошло не так» будет сведено к минимально возможному. И еще раз огромное спасибо нашей верной подруге по имени Теория Вероятностей.

Нельзя не отметить два очень серьезных преимущества, которые дает технологический стек разработки, умеющий говорить на двух языках. Первое – низкий порог вхождения. Это не является недостатком нашей профессии, это безусловное конкурентное преимущество. Научиться писать небольшие, но реально работающие решения на платформе «1С: Предприятие» может даже школьник. Не в последнюю очередь потому, что писать он будет на родном и полностью понятном ему языке.

О других преимуществах платформы 1С, позволяющих легко войти во вселенную разработки программного обеспечения – возможно, в следующий раз. Это тема отдельной беседы.

И второе – мы помним, что написанием программного кода его жизненный цикл не заканчивается, а только начинается. И если наш программный код ориентирован на тиражирование, возможности сообщить наши идеи и намерения, заложенные в этот код на понятном для наших коллег языке, увеличивают вероятность применения, сопровождения и развития нашего кода даже не кратно, а здесь скорее нужно вести речь о первом или втором порядке. Сопутствующие экономические эффекты мы просто опустим, они очевидны.

И в заключение нельзя не заметить – возможность разговаривать при написании программного кода на русском ни в коем случае не отменяет необходимости знать и понимать профессиональные термины вне зависимости от того, из какого языка они пришли. Что-то – из английского, что-то – из немецкого, что-то – из итальянского, что-то было написано на санскрите, и далее везде. Вопрос о том, какой язык важнее и правильнее, для нашей с вами профессии даже не ставится. Вопрос звучит совершенно иначе – в какой ситуации какой язык будет более эффективным, и сможем ли мы в нужный момент им воспользоваться.

А ответ очень простой – да, знаем, и сможем.