Аннотация.
Статья является первой (надеемся) из серии, в которой рассказывается о тех концептуальных и практических аспектах платформы 1С:Предприятие, которые автор считает интересными и очень важными, но пока не получили должного отражения в технической журналистике.
Автор (эксперт в разработке на платформе 1С с более чем двадцатилетним опытом) захотел восполнить эти пробелы.
В рамках первой статьи цикла будет дан краткий обзор возможностей платформы 1С:Предприятие говорить сразу на двух языках для разработки программного кода.
Также будет попытка разобраться, почему сделано именно так, и какие преимущества дает этот функционал нам, как разработчикам, но без пары достаточно наглядных примеров не обойдется.
Введение будет кратким.
Миф существует, и чтобы его сформулировать, не нужно много слов.
Но для развенчивания мифа понадобится много слов (это можно считать маленькой оговоркой - букв будет много).
Формулировка мифа.
Считается, что инженеры, занимающиеся разработкой бизнес-приложений на платформе «1С:Предприятие», вынуждены и просто обязаны писать программный код на русском языке.
Это первая часть мифа.
Вторая часть - код программы на русском языке - очень забавная и совсем не серьезная, а главное непонятно почему.
Первую часть мифа можно закончить одним очень коротким и гневным словом, но мы проявим инженерную вежливость и возьмем формулировку из словаря дипломатов – «Это не совсем точная информация».
А именно, платформа «1С:Предприятие» с момента своего рождения позволяла писать программный код на одном из двух языков – русском и английском.
Встроенный язык имеет два полных и эквивалентных наречия.
В качестве аналогии с окружающим нас миром вы можете посмотреть на Канаду, на Бельгию, а также на множество стран, где говорят более чем на одном языке.
И здесь следует знать наверняка - наличие английского диалекта в языке платформы 1С - это не какое-то усилие по остаточному принципу, паритет двух диалектов соблюдается предельно строго, поверьте на слово человеку, который не только работал с этой платформой большую часть своей сознательной профессиональной жизни, но и видел всю кухню изнутри.
Надеюсь, что с вопросом - позволяет ли платформа 1С:Предприятие программировать на английском языке - здесь должна быть полная ясность.
Это тоже позволяет. Но нам необходимо уточнить одну очень важную техническую деталь.
Да, платформа требует для каждой конкретной конфигурации (термин «Конфигурация» здесь используется в том же значении, что и «Проект» для других языков и сред разработки) явно указывать вариант встроенного языка — русский или английский.
, но это указание вовсе не диктует необходимость писать программный код только в этой указанной нотации.
Свойство «Опция встроенного языка» используется платформой для некоторых методов и свойств, возвращающих определенные системные имена (термины) на языке, который указан в свойствах конфигурации в качестве основного языка разработки.
Здесь следует отдельно пояснить, что в конфигурации есть еще одно свойство «Лингвистическое», определяющее основной язык конфигурации.
Но это не язык разработки, а язык интерфейса, то, что в операционных системах называется термином «Локаль».
Платформа 1С поддерживает только два языка написания программного кода, но интерфейс поддерживает множество языков, при желании можно даже спроектировать свой.
То есть «Интерфейс на валирийском или дотракийском языке» — это, конечно, шутка, но технически вполне осуществимая.
Вернемся к языку разработки.
Независимо от выбранного варианта для конкретной конфигурации, ее программный код может быть написан как на английском, так и на русском языке, причем языковой интерпретатор хорошо справляется со смешанной системой обозначений.
Понятно, что у каждого разработчика есть свои личные предпочтения.
Я лично, например, писал строго на английском еще в версии 7.7 в самом конце девяностых-начале 2000-х.
Но потом, со временем, я перешёл на русскую нотацию.
Почему и для чего – об этом ниже.
Сначала давайте посмотрим на пример кода.
Программный код здесь синтетический, хотя и похож на промышленный.
В промышленном коде уровней стека было бы немного больше.
Что делает код в этом примере? Очень простая вещь — он получает прокси-веб-сервис сторонней системы, а затем сначала вызывает метод этого стороннего веб-сервиса, а затем внутренний метод для проверки результата, полученного от внешней системы.
Вы можете видеть, что мы пишем английскую лексему, обращаясь к системе, которая может говорить только по-английски.
Весь остальной код строго кириллический.
И это не требование заказчика, не требование стандарта или регламента, это личный выбор разработчика.
Проект заключался в создании компактного, но мощного решения для интеграции нескольких разнородных систем в гетерогенной среде в условиях высокой нагрузки с высокой надежностью, словом, все, что нам нравится.
Пример кода был упрощен для ясности.
И теперь мы подходим к вопросу – если мы сможем выбрать один из двух вариантов языка для написания нашего программного кода, какими критериями мы будем руководствоваться? И существует ли относительно четкая инженерная методология, позволяющая без лишних творческих колебаний выбирать между рус/англ? Конечно, есть такая методика.
Первый критерий – это то, что об этом написано в требованиях, регламентах, стандартах, которые мы должны использовать при разработке данного конкретного программного кода.
Если мы этим не владеем, если есть внешние факторы, они имеют приоритет над всеми остальными.
Например, заказчик нашей интеграционной механики находится и работает в другой стране, довольно далекой от нас.
Специалистам, которые будут заниматься приемкой, внедрением и сопровождением нашего программного кода, будет просто невозможно что-либо понять на кириллице.
Поэтому вот наш безальтернативный выбор: 
Да, это не язык Шекспира, в том смысле, что мой уровень английского мягко говоря низкий.
Даже орфография может быть хромой, а грамматика точно хромает, и нет уверенности, что в приведенном примере комментарий был написан без нарушения правил английской орфографии.
Но если честно, если бы я подсчитал количество фрагментов, написанных не на языке Шекспира, которые я видел в своей жизни в самых разных языках и средах разработки, я бы давно сбился со счета.
Важно, чтобы код, который мы пишем (включая комментарий), работал, эффективно решал возложенную на него задачу и мог успешно сопровождаться специалистами другой языковой группы.
Это был крайний случай, когда решение принимаем не мы сами, а нам его диктуют внешние факторы.
Такие ситуации случаются, но не очень часто.
Вполне закономерно возникает вопрос: программный код — это всего лишь текст, причем далеко не литературный, а технологический и строго формализованный.
Нет ли способа выполнить машинный перевод программного кода с одного языка на другой? Спецификация встроенного языка программирования известна, русско-английских словарей великое множество, а придуманные программистом названия переменных и методов, не имеющие точного перевода, можно преобразовать с помощью банальной транслитерации.
Ответ тоже вполне закономерен – среди достаточно обширного набора средств разработки, доступного программисту, работающему с платформой 1С, есть такой инструмент. Называется он Language Tool и технически является плагином для EDT (аббревиатура от профессионального сленга вселенной 1С, «Инструменты разработки предприятия», среда разработки нового поколения, но история про EDT и другие инструменты разработки, в том числе Language Tool , пока выходит за рамки статьи и требует отдельного рассмотрения, здесь достаточно лишь упомянуть, что существует инструмент для прямого и обратного преобразования программного кода между русской и английской нотацией).
Продолжим анализ методики выбора.
На место специалиста, который не только пишет программный код, но и отвечает, например, за общие архитектурные решения, за технологию разработки по проекту и в конечном итоге за результат разработки в целом, я лично выберу русскую систему обозначений.
Почему? И еще довольно важный момент - если мы пишем не для внешнего, а для внутреннего рынка, если в наших планах тиражирование программного кода в тех местностях, где проживают люди, для которых русский язык является родным - это фактор из преобладающей категории.
.
Специалисты, которые будут поддерживать и развивать наш программный код, должны иметь возможность общаться с нами без дополнительных переводчиков и связанных с ними ошибок перевода.
Прежде всего, мы имеем в виду предметную область.
Используя платформу «1С:Предприятие», мы в первую очередь решаем задачи автоматизации бизнес-процессов.
(Но отметим в скобках, что технологические возможности платформы отнюдь не ограничиваются этим кругом задач, но это тема несколько другого разговора).
А в задачах автоматизации экономических процессов одним из ключевых факторов успеха является общее понимание специфики предметной области для всей команды «Производитель, разработчик, оператор, пользователь», чтобы мы могли говорить на одном языке.
Пользователь вряд ли когда-нибудь прочитает наш программный код, но он обязательно прочитает надписи на формах, пояснения, сообщения и (тут мне многие не поверят, но это правда) нашу техническую документацию.
Но специалисты, занимающиеся задачами эксплуатации, поддержки, сопровождения и развития нашего программного кода, прочитают его очень внимательно.
А теперь давайте проведем небольшой мысленный эксперимент. Возьмем приведенный выше фрагмент наглядного пособия и удалим из него комментарий, описывающий функцию.
Получится вот так: 
Конечно, это наглядное пособие «Как не надо делать», потому что в промышленной разработке такие трюки, как раскомментированные методы API, «вообще не» приемлемы.
Но в качестве наглядного пособия и пояснения к тезису «Программный код документирует сам себя» вполне годится.
И здесь очень важный момент. Термины предметной области, будь она огромной, как отрасль, или компактной, как отдельное предприятие, имеют строго определенное значение – перевод на другой язык, даже близкий и почти родственный, требует квалификации не только инженера-разработчика, но и филолог, потому что это надо так перевести, чтобы все остальные поняли.
Механизм безопасности — это, конечно же, комментирование кода.
И сюда мы включим абсолютно циничную инженерную правду - если нам, помимо собственно программного кода, приходится писать глубокомысленные и разоблачающие комментарии на другом языке, и объем этих комментариев составляет не менее тридцати процентов от общего количества, то простите.
мой французский, но примерно тридцать процентов нашего рабочего времени мы отправляли его туда, где всегда требуется бумага (несмотря на то, что текст, напечатанный на ней, совершенно неважен).
Дело вот в чем.
Если русскоязычный программист, разрабатывая для русскоязычного рынка, пишет код программы на английском языке, ему все равно придется объяснять, а возможно, даже пересказывать написанный код на русском языке.
И общая эффективность работы над кодом по сравнению с вариантом «Мы сразу пишем по-русски, и необходимость подробного комментария-пересказа отпадает сама собой» будет значительно ниже, возможно, даже на десятки процентов.
Давайте еще раз посмотрим на пример кода.
Каждое слово ясно.
Конечно, непонятную и нечитаемую программу можно написать на любом языке, но если мы пишем на русском, вероятность того, что коллега нас поймет, возрастает, причем вполне серьезно.
Благодаря теории вероятностей и другим основным теориям нашего ремесла.
Документация может содержаться в самом коде.
Именно тот, который понадобится нам самим, когда перед нами поставят задачу – но зачем идти далеко? Чтобы понять, почему информационная система работает, скажем вежливо, медленно.
Добавьте новую функцию, которой раньше не было, ничего не нарушив.
Внедрить существующую систему управления учетом изменений в схеме бизнеса, но так, чтобы основные правила предметной области не нарушались нашей новой системой.
И так далее, все те задачи, которые мы с вами решаем каждый день.
Мы без колебаний повторим.
Термины предметной области должны четко и однозначно интерпретироваться всеми участниками жизненного цикла программного кода, оперирующего этими терминами.
Некоторым другим отраслям пришлось изобрести свой особый язык для решения аналогичной проблемы.
Например, в морском деле (даже в реальном парусном деле) все сколько-нибудь значимые термины — не английский и не голландский, а свой особый морской язык, придуманный именно для однозначного общего понимания.
Мы не плаваем по морям, а пишем программный код, но проблема однозначного понимания для нас так же актуальна, как и для моряков.
Цена неправильного толкования термина может быть очень высокой.
Перевести терминологию предметной области, связанную, например, с терминологией стандартного или отраслевого решения, на английский язык так, чтобы ее можно было четко прочитать «с первого взгляда», задача очень сложная и даже не всегда имеет решение.
В качестве небольшого упражнения попробуйте перевести на английский язык (только «чистыми руками», без Google Translate) следующую конструкцию: «Изменение алгоритма расчета себестоимости продукции по схеме переработки сырья, поставляемого заказчиками при ее используется для закрытия функциональных пробелов в учете гарантийного ремонта».
А потом проверьте, кто из коллег как интерпретирует ваш перевод. Здесь мы подходим к понятию «Командная работа».
Никто из нас не работает в одиночку, мы всегда работаем в команде, и в командной работе очень важно говорить на одном языке, понятном каждому из нас без перевода, без лишних усилий.
«Говорить» здесь, конечно, означает «Написать программный код».
Очень важно понимать, что каждый из нас не просто программист-разработчик, творец-мечтатель.
Все, что мы делаем, — это решение конкретных и понятных задач.
Мы помогаем нашим клиентам решить их проблемы.
И здесь мы должны четко знать, что наши задачи невозможно решить в одиночку.
Чтобы решить нашу проблему, мы должны уметь общаться с коллегами.
И чтобы это общение отнимало у нас минимальное количество ресурса нашего рабочего времени и позволяло передавать в единицу времени большое, максимально возможное количество информации.
Просто потому, что все время, которое мы тратим на рабочие задачи, — это рабочее время.
А наш инженерный принцип гласит: «Рабочее время необходимо расходовать эффективно».
Те инструменты, которые позволяют это сделать, мы включаем в наш набор инструментов.
Одним из таких инструментов является кириллическая русская речь, которая описывает предметную область и позволяет понять друг друга без лишних подробностей, ненужных слоев.
И это не теория, это один из тех принципов, которые помогли лично мне не просто написать какую-то программу, а построить несколько систем уровня «Большая и по-настоящему страшная информационная система».
Синонимом словосочетания «Командная работа» является слово «Взаимодействие» (или «Сотрудничество»).
Мы помним, что можем выбрать любое наречие.
Основой командного взаимодействия является сигнальная система.
Мы подаем сигналы и реагируем на данные нам.
Да, многие термины настолько точны и устоялись, что их легче и правильнее передать товарищам на языке оригинала, но системы сигнализации имеют один общий родовой недостаток.
Чтобы избежать очень большого количества букв, пример будет предельно ясным и прямым из моей жизни.
Представим себе взаимодействие в такелажной бригаде.
У нас всего три рабочие специальности.
Водитель есть – его основная задача уже выполнена, и теперь ему осталось только удержать грузовик на месте.
Есть крановщик, который находится очень-очень высоко, его задача будет заключаться в том, чтобы с помощью крана загрузить десять тонн металлоконструкции из грузового автомобиля на склад. И есть еще два товарища, чья профессия называется «Стропальщик».
Их задача – организовать взаимодействие металлоконструкции с погрузочным (в том числе и разгрузочным) краном.
Казалось бы, все просто, как мычать.
Но даже если мы мычим, не очень четко понимая друг друга, то есть вносим в нашу сигнальную систему избыточные и перегружающие части, то получаем примерно следующую картину.
Ты зацепил три тонны и дал сигнал наверх - конечно, не голосом, ты там не сможешь крикнуть, но ты ясно показал "Вира" (на всякий случай, на такелажном языке это означает "Поднять" !»), но крановщик поднимает как-то медленно и грустно.
А когда вот так над головой висят три тонны ржавой трубы, это не очень приятное ощущение, и хочется побыстрее это прекратить.
Поэтому вы подаете повторный сигнал – «Вира».
И здесь все идет не так.
Крановщик принимает прямо противоположное решение и считывает ваш сигнал не так, а по-своему.
Он понимает это так: «Зацепилось плохо, опусти, перетянем».
И вместо «Вира» он делает «Майну» (а это, соответственно, «Опусти!»), но не так медленно, а резким рывком.
Блестящие представления об удивительном мире систем сигнализации у вас появятся позже, а пока у вас есть несколько долей секунды, чтобы увернуться от падающих на вас трех тонн ржавого железа.
Если есть время, понимание важности правильной интерпретации сигналов приходит словно из космоса.
Дальше, конечно, производственные вопросы, анализ ситуации, настройка системы сигнализации с обязательным обучением на безопасном макете и так далее.
Это уже обычная повседневная работа.
И здесь мы подходим к одному из центральных моментов, ради которого был написан этот текст. Не столь важно, на каком языке мы говорим и пишем наш программный код. Гораздо важнее, чтобы мы – как коллектив, на предприятии, в отрасли – понимали друг друга с минимальными затратами на передачу смысла посредством текста.
Тогда, и только тогда, наша работа будет эффективной, а количество ситуаций «Что-то пошло не так» будет сведено к минимуму.
И еще раз огромное спасибо нашему верному другу по имени Теория Вероятностей.
Нельзя не отметить два очень серьезных преимущества, которые дает стек разработки технологий, говорящий на двух языках.
Во-первых, это низкий входной барьер.
Это не недостаток нашей профессии, это абсолютное конкурентное преимущество.
Даже школьник может научиться писать небольшие, но реально работающие решения на платформе 1С:Предприятие.
Хотя бы потому, что он будет писать на своем родном и вполне понятном языке.
О других преимуществах платформы 1С, позволяющих легко войти во вселенную разработки ПО – возможно, в следующий раз.
Это тема для отдельного разговора.
А во-вторых, мы помним, что с написанием кода программы ее жизненный цикл не заканчивается, а только начинается.
И если наш программный код ориентирован на репликацию, то возможность донести наши идеи и намерения, заложенные в этот код, на языке, понятном нашим коллегам, увеличивает вероятность использования, сопровождения и развития нашего кода даже не многократно, а здесь нам скорее понадобится говорить о первом или втором ок.
Мы просто опустим сопутствующие экономические эффекты; они очевидны.
И в заключение нельзя не заметить, что умение говорить при написании программного кода на русском языке никоим образом не отменяет необходимости знать и понимать профессиональные термины, независимо от того, из какого языка они исходят. Что-то было с английского, что-то с немецкого, что-то с итальянского, что-то было написано на санскрите, да и то везде.
Вопрос о том, какой язык важнее и правильный, для нашей профессии даже не ставится.
Вопрос звучит совсем иначе – в какой ситуации какой язык будет более эффективен, и сможем ли мы использовать его в нужный момент. И ответ очень простой – да, мы знаем и можем.
Теги: #программирование #языки программирования #Изучение языков #1с #1с:предприятие #1С #1С #1с предприятие 8 #платформа 1с #1с разработка #российская разработка
-
Праведное Убийство: Месть Как Образ Жизни
19 Oct, 24 -
Динамическое Размытие На Android
19 Oct, 24 -
Поддержим Россиянку!
19 Oct, 24 -
Американцы Не Доверяют Блогам
19 Oct, 24
