1C:Запах версия Ё
Ну очень уж не хотелось писать здесь о программировании, но наболело.
Постараюсь не ругаться матом, хоть и очень хочется :)
Примерно лет 20 назад вышло так, что я лично пообщался с разработчиками тогда еще 1С:Бухгалтерии, и из этого общения я сделал для себя вывод, что все, что они могут - это сделать криво работающий большой кусок говна (я не ругаюсь матом :)). Но этот кусок вполне может быть востребован на нашем рынке, так как в то время других кусков особо и не было, а потребность в них была.
Ну а набрав поболее пользователей для подобной системы можно прочно сидеть на пятой точке в рынке, так как бухгалтера довольно консервативный народ - освоив худо-бедно один кусок говна они очень не хотят перебираться на другой кусок даже в том случае, если от него воняет несколько слабее.
Всю свою жизнь я старался держаться от этих запахов подальше, хотя приходилось сталкиваться и с криворукими «программистами 1С», и с их поделками (обработками :)).
Существует городская легенда - «1С хорошая система, но разработчики сторонних конфигураций делают ее кривой и тормозной». Это из разряда городских легенд о том, что геном свиньи ближе к геному человека, чем геном шимпанзе. Кто-то, знающий про тот же инсулин, может и поведется на это, но в действительности эта легенда ложна.
Да, 1С (Предприятие, Управление торговлей и что там еще) изначально кривая и тормозная система, написанная криворукими говнокодерами.
И доказательство тому - CommerceML.
Что это такое? Это типа «стандарт», разработанный криворукими специалистами 1С для обмена коммерческой информацией.
Вот что написано о нем на сайте 1С:
«Первая редакция стандарта CommerceML разработана специалистами фирм "1С" и "Extra.RU" при поддержке технических специалистов представительства Microsoft в России в 2000 году.»
«Вторая редакция стандарта CommerceML разработана с учетом развития отрасли информационных технологий и развития языка XML. XML-схема разработана в соответствии с рекомендациями консорциума W3C, пожеланиями по расширению предыдущей редакции стандарта в части формализации описаний электронных документов и классификации передаваемых данных.
Стандарт принят и введен в действие решением совета директоров Некоммерческого партнерства "Стандарты электронного обмена информацией" 9 декабря 2003 г.»
Сильно?
Я не нашел на сайте Microsoft упоминание об этом «стандарте», поиск сочетания слов CommerceML и Microsoft в гугле не дал ни одной отсылки из первой сотни результатов к доменам, принадлежащим Microsoft.
Ну да ладно. Может сам стандарт хорош? Ага, как бы не так. Большего куска дерьма, который не тянет даже на формат внутреннего обмена, который скрыт от посторонних глаз в виду своей кривости и постоянной изменяемости, придумать сложно. Называть такое стандартом - это нонсенс.
Но давайте разберемся, что же в нем не так.
Первое, что бросается в глаза - название. CommerceML - типа Commerce Markup Language. Назвали по английски, с претензией на международный статус.
Ну назвали бы «ГовноИксЭмЭль для обмена с 1С», я бы и не стал придираться. Это бы полностью соответствовало подходу к программированию в 1С - чисто по русски. И это бы полностью соответствовало содержимому этих ГовноИксЭмЭлев.
Ведь внутри... Внутри тихий ужас - вся схема этих документов русскоязычная.
О каком международном стандарте могла идти речь, если все теги на великом и могучем?
Вот пример открывающего тега - <КоммерческаяИнформация xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="commerceml_2.04.xsd" ВерсияСхемы="2.04" ДатаФормирования="2008-01-09T18:13:34">.
Вопрос - а почему это «стандарт» разработали не на китайском? Было бы еще прикольнее!
Для кого предназначены XML файлы? Вы представляете себе бухгалтеров, который в ручную формируют эти файлы для передачи информации контрагенту? Типа сидят, и пишут теги? Я нет!
XML в подобных системах производят и потребляют программы, которые пишут программисты.
Ну да, говнопрограммисты на 1С привыкли пейсать на великом и могучем, но я не думаю, что им прийдется что-то самим ваять на «ГовноИксЭмЭль для обмена с 1С», так как этот кусок говна производит и потребребляет эти файлы вполне самостоятельно.
С этим форматом будут вынуждены столкнуться другие программисты, которые по тем или иным причинам вынуждены писать код для обмена данными между своими системами и 1С.
И вот тут начинаются разные проблемы.
К примеру, вы пишите на Java.
По счастливой случайности на сайте 1С выложили схему этого ГовноИксЭмЭля. Сейчас там аж две версии - 2.05 и 2.06. К версиям мы еще вернемся, но давайте попробуем взять схему 2.05.
Скачиваем XSD файл схемы, кидаем его в workspace Eclipce, и натравливаем на него JAXB.
И мы благополучно получаем из этой схемы тучу классов, благо(?) Java позволяет использовать русский язык в именовании переменных.
Что бы не ходить далеко, давайте сразу попробуем собрать наш проект.
Если вы, как и я, сидите под Mac OS X, то вас ждет облом. Имея немалый опыт в подобных обломах, я сразу догадался в чем дело.
Вот строчка из файла Свойство.java:
public class Свойство {
Думаете, что все в порядке? Как бы не так!
Вот как слово Свойство выглядит в кодах Unicode в каталоге файловой системы:
\u0421\u0432\u043e\u0438\u0306\u0441\u0442\u0432\u043e
А вот то же слово в нашем файле (то же в схеме XSD):
\u0421\u0432\u043e\u0439\u0441\u0442\u0432\u043e
Заметили разницу?
О да, русские Й и Ё могут быть записаны двумя способами! Как и теги, их содержащие. Есть рекомендации по нормализации (их аж 4 штуки в Unicode), и две из них предписывают писать одним образом, две другим.
Вы все еще считаете хорошей идеей использовать русский язык в наименованиях тегов и аттрибутов xml?
И что делать? Ладно, выход есть. Пишем Свойство в аннотациях через name = "\u0421\u0432\u043e\u0439\u0441\u0442\u0432\u043e", а для имени класса сделаем рефакториг на Своиство.
То же делаем со всеми остальными именами классов, содержащими Й и радуемся тому, что хотя бы многострадальную Ё говноспецы из 1С не догадались использовать.
Давайте попробуем покодировать, но перед этим заглянем на несколько строк ниже в том же файле:
public void setВариантыЗначений(Своиство.ВариантыЗначений value) {
Вот это засада! Да, наши сеттеры и геттеры, как мы и привыкли, начинаются с set и get. И впереди нас ждет ад с лихорадочным переключением раскладок при кодировании.
Ну да, можно пока еще не поздно, во всех созданных классах сделать глобальную замену «set» на «плюх», а get на «бульк». Но переделать при этом все ключевые слова языка и все библиотечные функции на русский у вас не выйдет, и от постоянных задалбывающих переключений раскладок вам никуда не деться, и пунтосвитчер вас не спасет.
Потерпим? И не такое терпели?
Ну ладно, потерпим. Вернемся к «стандарту».
Как я уже говорил, на сайте 1С в данный момент есть 2 схемы 2-й версии 2.05 и 2.06. 5-ю я загрузил, а вот 6-ю... Просто так не пытайтесь - не выйдет. Конечно, если ручками поправите все ошибки, то может быть и выйдет. Но без этого никак.
Как вам такое (один из примеров)...
В 538 строке определяется
А в 1509 строке
Корневой элемент. Содержит Классификатор, Каталог, ПрайсЛист и Документ.
Но, конечно, вы можете допилить это файл вручную, но оно надо? Думаете версия 2.06 вас спасет? Думаете, что «ГовноИксЭмЭль для обмена с 1С» - это «стандарт»?
Ага, щаз!
Вот выдержки из листа изменений к версии 6 (я опущу нововведения):
6. cml:ИдентфикаторГлобальныйТип исправлено на
cml:ИдентификаторГлобальныйТип
11. Изменена группа РеквизитыЮрЛица: элементу Руководитель вместо типа
Контрагент присвоен тип Руководитель
Как вам такое?
Я всегда думал, что стандарты - это то, что долго и упорно разрабатывается, и на что можно полагаться. Стандарт и реализация - разные вещи. Если вы знаете, что что-то там реализует такой-то стандарт в полной мере, то вы можете полагаться на то, что если вы делаете что-то исключительно в рамках стандарта, то у вас проблем не будет. Если стандарт реализован только в какой-то части, вы, опять же, спокойно можете использовать эту часть.
Сама реализация может содержать дополнительные плюшки, и вы можете использовать их на свой страх и риск. Но стандарт - это стандарт. У него не бывает суффиксов .06 и его при второй версии не меняют таким образом, что «17. Изменена длина атрибута ВерсияСхемы в корневом элементе КоммерческаяИнформация с 4 на 5 символов.» (это что, они собираются выпустить не 99 а 999 исправлений второй версии «стандарта»?).
По сути, если вы собрались обмениваться данными с 8-кой 1С, то вам нужно где-то раздобыть версии схемы 04, 03, 02, 01 и, возможно, 00, для каждой из них написать код, и постоянно следить за выходом новых версий (запас сделали не малый по знакам, а судя по кривости схемы для 2.06 и исправлению грамматических ошибок в наименовании тегов, разработчики «стандарта» не очень утруждают себя его тестированием перед публикацией). Ведь эти версии - это, по сути, отдельные "стандарты". Они не совместимы снизу вверх, как вы могли привыкнуть. У вас не получится просто игнорировать новые теги (и с ними какую-то новую, но пока еще ненужную вам информацию), так как в новых версиях нужная вам информация переезжает в эти новые теги.
И не надейтесь, что вы договоритесь с 1С о версии обмена, при соединении она вас спросит лишь о куке, поддержке зип, и сколько мегабайт вы готовы проглотить.
А потом вам сунет XML той версии, которую сочтет нужной ей. А вы уже крутитесь, как хотите. Ждите, что скоро к вам прийдет 7-я версия «стандарта» и JAXB плюнет вам в рот эксепшеном, получив от 1С теги, которых нет в 6-й «версии» 2-й «редакции» этого «стандарта». Возвращайтесь обратно в DOM или SAX, и пилите, Шура, пилите.
А если вы решили поработать с 7-кой 1С, то вас ждут чудеса на виражах первой версии этого «стандарта», который отличается от второй не только по структуре, но и по принципам обработки информации.
Как это все вяжется с пафосными заявлениями о том, что совместно с Microsoft, что якобы «стандарт» и прочим бла-бла-бла - я не знаю. По мне - так никак. 1С как была, так и остается самым большим куском дерьма на рынке. И будет оставаться.
Хотя в продуктах 1С есть определенный плюс для говнопрограммистов. Написав что-то, что окажется полезным для некоторого числа пользователей этого куска говна, они могут больше ничего нового не делать, а спокойно сидеть на пятой точке, получая пожизненно бабло за допиливание своей поделки под очередное обновление 1С. При этом не нужно даже заботиться о том, что бы как-то улучшить свою поделку, развить. Это другие программисты выпускают новые версии, в которых не только устранены старые ошибки (ну и добавлены новые :)), но и расширяется функционал, улучшается производительность.
Ничего этого не надо, достаточно «адаптировать» под новые «стандарты» 1С.
Но это все не по мне.
ЗЫ: Требую от 1С переименвание "стандарта" CommerceML в "Никак Не Стандартизированный ГовноИксЭмЭль для обмена с 1С", так как его нельзя даже назвать "неудачным стандартом" в виду того, что он в принципе не является стандартом, так как по сути это лишь сильно зависящий от версии (и установленных обновлений 1С) не совместимый даже со своими предыдущими версиями формат обмена данными с 1С.