Комментарии 135
Стаж в 1С — 20 лет. На Хабре недавно. Очень интересно понаблюдать за развитием комментариев в такой ветке :))
Заодно, возможно, пойму, имеет ли смысл писать на Хабр более менее развернутую аргументированную статью на тему, за что я люблю 1С
Извините, не могу претендовать за всех, но я бы почитал, тема то живая и 1с програмистов много, значит будет отклик.
Пока я настроен написать, главное, чтобы еще хватило времени
Реально занятно - действительно другой мир. В "обычном" программировании доступ к полям структур, включая вложенные, делается обычно через точку. При этом всё вот это находится в памяти, причём если это какой-нибудь C, то там РеализацияТоваровУслуг.Заказ.Контрагент.Партнер.КонтактноеЛицо.Телефон
заменяется компилятором на доступ по указателю со смещением (какое-то число, определяемое на этапе компиляции). Вне зависимости от вложенности.
Поэтому напишите, пожалуйста.
Такое в 1С тоже есть - например, можно через точку обратиться к полю коллекции.
Но также 1С придумала такой способ обращения через точку, чтобы заменять вложенные запросы.
Например, в БД есть таблица А. В ней есть колонка "Подчинённый", там хранится ссылка на строку таблицы Б. Чтобы получить какое-то поле из таблицы А и сразу поле из таблицы Б по ссылке из "Подчинённый", в любом другом языке программирования нужно было бы написать запрос, где выбираем из таблицы А, связываем с таблицей Б. В 1С же можно просто обратиться прямо из кода без запроса:
А.Подчинённый
И получим значение из таблицы Б.
Т.е. форма синтаксического сахара.
Но проблема в том, что под капотом это даёт кучу проблем (которые хорошо описали здесь в комментариях). А ректальные программисты видят только простоту использования такой конструкции, не желая знать о побочных эффектах.
Да ладно, "другой мир". Почти никаких отличий от того, что делает любая ORM в режиме ленивой подгрузки.
О, а что там не так с "через точку"? Что значит "не учитываются права" - а они там в какой должны момент учитываться, когда запрос пишешь? С 1С уже лет 20 не работаю, просто любопытно)
Через точку не так то, что так можно делать только в запросе, потому что в этом случае sql выбирает ровно то, что ты просишь, потому что ты сам в явном виде указал системе, что тебе нужно.
То есть в примере из статьи "РеализацияТоваровУслуг.Заказ.Контрагент.Партнер.КонтактноеЛицо.Телефон" построится план запроса, в котором в результате выбирается только телефон.
Если же выбирать через точку из объекта или ссылки на реализацию, то в итоге логика системы будет другой.
Поскольку система не знает, не начнешь ли ты сейчас в следующем коде кроме телефона выбирать еще десяток полей из того же контактного лица, то она на всякий случай при первом обращении к какому-либо полю объекта получает объект целиком.
В результате будут получены полностью заказ, контрагент, партнер и т. д.
Особенно феерично получается, если в каком-нибудь объекте полсотни плюс реквизитов, может быть всякие двоичные данные и пр.
Ну то есть, несмотря на соблазн обращаться к реквизитам объектов через точку без запроса, делать так нельзя, нужно получать через запрос.
В той же БСП (библиотека стандартных подсистем) для этого есть специальная функция, упрощающая это действие.
Нет не так. Не получает объект целиком. А в терминах 1с вообще объект не получает, А только ссылку. Проблема в том, что каждая точка это отдельный запрос, вместо того, чтобы выполнить один.
И ещё если ссылка пустая, то такой код:
А = МояСсылка.Наименование;
Присвоит А пустую строку, а запросом получим пустую выборку.
Про реквизит через несколько точек не уверен до конца, что будут получены все промежуточные объекты целиком.
Про одну точку точно так.
По поводу каждая точка — это отдельный запрос наверное да, так и есть.
По поводу наименования пустой ссылки да, это нужно обрабатывать кодом.
Может быть получен объект целиком. Зафиксированы случаи. См. "1С: Настольная книга эксперта"
там еще и в модуле объекта могут действия выполняться при этом
По поводу не учета прав ситуация такая.
Если обращаться через точку к объекту, то можно получить нарушение прав, да.
Это еще одна причина, почему нужно использовать запрос.
Если же использовать запрос, то в нем нужно писать ключевое слово "разрешенные", в этом случае будет учитываться RLS (Record Level Security) и ошибки не будет.
Ошибка будет только если нет прав на таблицу целиком.
Правда и данные могут не получиться, если нет прав, ну так а как иначе, это нужно обрабатывать в логике.
Хотя 1С все это дело конечно пытается кэшировать, а разработчики платформы 1С регулярно такие вещи оптимизируют…
Прикрутите опрос, кто сколько пунктов набрал за последний месяц. У меня всего один, но это не потому что я не сторонник данной парадигмы.
Поддерживаю!
Приятно узнать, что хоть кто-то не относится к 1С с усмешкой.
Все верно, только 1С это не "любой CRM на Java". Во-первых потому, что не совсем CRM, во-вторых, потому что не на Java.
Это не java как минимум потому что нет ООП что делает поддержку крупных проектов практически не возможной, и местами героической.
Вторым важным отличием является отсутствие типизации, компилятор вам редко когда что то может подсказать или как то иначе помочь. Надежда только на себя и свою память.
Представьте java без ООП (У вас есть только процедуры и функции) в котором перемешаны SQL запросы, всё это в 350 модулях в одном каталоге (иерархия хранения модулей не поддерживается) каждый модуль от 1000 до 20 000 строк (иначе модулей было бы не 350), эти модули сильно между собой зависимы и по факту просто содержат процедуры и функции, нет интерфейсов, контрактов, каких либо других описаний, ты просто должен всё это помнить сам.
Есть пара стандартов на бумаге где и что размещать но всё это абсолютно не поддерживается средой разработки и языком, иногда складывается впечатление что платформу разрабатывает не крупнейшая в РФ корпорация а просто open source сообщество.
С другой стороны понятно что бейсик (а по факту 1С это и есть бейсик только с фреймворком в виде платформы) не предназначен для всего того куда сейчас платформу продвигают.
1С отличная система с низким порогом входа пока у вас небольшая конфигурация (что редко) или пока вы правите какие то редкие куски большой конфигурации или делаете отчеты/обработки (чем занимается 90% франчей).
В Java перебравшись через порог новичок идет по ступенькам с перилами (ООП, IDE, Code Review, Патерны, Тесты). В 1С за порогом тебя ждет плато на горизонте которого находится отвесная стена, по которой нужно карабкаться дальше.
На мой взгляд людям которые создали ERP, БСП 3.0 при жизни нужно памятник ставить, настолько титанический труд. Страшно подумать каких бы высот они достигли имея дело с современными промышленными языками.
По факту всё что во всем мире является плохим стилем, в 1С норма по определению. Да у 1С есть стандарты разработки, но они на "бумаге" а не в IDE и следовать им это значит ещё сильнее нагрузить свой мозг борьбой с 1С а не решением проблем.
Да и быстродействие 1С это грусть печаль, если JVM оптимизируют всем миром, то виртуальная машина 1С написана в соответствии с первым постулатом "Главное, чтобы работало".
Для примера: Массив из 33 000 000 машинных номеров.
1С:
Формирование массива: 901 156 мс (Цикл + генератор случайных чисел+массив.Добавить(Значение)).
Поиск в массиве не существующего элемента средствами платформы: 19164мс. (Массив.Найти(Значение))
Занимает 2.7 гб RAM.
Java (такой же код на той же системе):
Формирование массива: 52651.3931 мс
Поиск в массиве не существующего элемента : 190.6821 мс (arr.contains(Value))
В памяти точно не помню, по моему около 300 мб.
Вообще там такой багаж проблем (стоимость и вообще необходимость лицензий, ORM ограниченная только урезанным Select которая мощнейшие СУБД с их возможностями использует как замену DBF файлов).
Отдельная боль это гигантомания и монолитизация всего, базы по 2-3 TB на крупных проектах это норма. Когда спрашиваешь у разработчиков PG совета как бы заставить этого монстра работать, в ответ всегда получаешь:
- "Зачем вам такая база?" Разбейте на 10-20 поменьше, выделите сервисы, какие то данные перекиньте в архив и.т.п).
После упоминания что это 1С обычно разговор заканчивается, потому что говорить тут просто не о чем.
напишет какой-нибудь groovy enginer класс
Так и родилась 1С!
Именно так всё и есть, программист = аналитик, принимать задачу будет человек, который продаёт/производит/складирует товар и это его главная задача, а разбираться "что вы там говорите на вашем птичьем языке" он не будет в принципе. Кроме 1С, похожая ситуация с говнокодом часто бывает на фронте, по этой же причине.
Если бы это только к 1С относилось :)
Если взять например проект ruDALL-E, про который недавно писали на хабре, то уже на этапе загрузки можно увидеть, что оно поднимает сразу два дублирующих друг друга фреймворка — pytorch и tensorflow. Это хорошо ещё разработчики про JAX не знают, а то бы они и его туда добавили для комплекта. А первый же пулл-реквест, который они получили после выкладывания проекта на GitHub, ускорил генерацию изображений в 10 раз.
В общем, это типичный академический код, по сути сырой прототип. Проблема лишь в том, что в мире ML сделать из такого прототипа нормальный продукт практически невозможно — обучение таких громадных нейронок очень дорого. Поэтому у разработчиков сервисов на основе нейронок нет другого выхода, кроме как брать всю эту конструкцию из говна и палок как она есть, целиком, и как-то встраивать в собственный код, который после этого уже не может быть настолько хорош, как хотелось бы.
В копилку:
Передача параметров в методы через запись/чтение базы данных
https://geniy1s.ru/nekanonicheskij-sposob-spuskaniya-parametra-nizhestoyashhim-proczeduram/
Ректальное программирование
1с
Возможно я слишком испорчен или это опыт от взаимодействия с 1с, но кроме улыбки ничего не вызвало)
С уважением)
Как одинэсник с 2003 года, люто плюсую, всё так и есть ;))))
Ой, я в 1С залезаю (как и в любой другой эксплуатируемый код) очень редко и неохотно, но вот такое в 1С встречаю с завидной регулярностью:
ЭтоСклад = (Найти(НРег(Организация.Наименование), "складо") > 0);
ЭтоТрансп = (Найти(НРег(Организация.Наименование), "транс") > 0);
ЭтоПРР = СокрЛП(Организация.ИНН) = "3211135524";
Если ЭтоСклад Тогда
ПеременнаяДлинаНомера = 3;
Префикс = "С";
ИначеЕсли ЭтоТрансп Тогда
ПеременнаяДлинаНомера = 3;
Префикс = "Т";
ИначеЕсли ЭтоПРР Тогда
ПеременнаяДлинаНомера = 3;
Префикс = "П";
Иначе
ПеременнаяДлинаНомера = 4;
Префикс = "";
КонецЕсли;Вот за что мне такое в эксплуатации? И это ещё не самое страшное место.
Да даже в скриптиках, призванных раз в день проверять корректность выгруженных на внешнюю площадку бэкапов, таких волосодыбательных мест не встречал...
Говнокод вам написали, бывает.
И не только на 1С, кстати.
Такое есть везде. Проблема говнокода в 1С встречается чаще из за более низкого порога и сжатых сроков т.к. 80% разработки 1С это разработка по часам. Это примерно как ожидать от продажной женщины за 1500р в час такого же отношения и внимания как от жены.
Но на самом деле проблема такого говнокода это все же проблема того кто пишет и команды (правда в 1С опять же 70% работает без команды). Но никак не платформы и не языка.
Вначале было смешно, потом грустно потому что вспомнилось то же самое на тех проектах, где работаю сейчас и в прошлом и это не 1С
И я тоже так делаю. В смысле кода это наиболее лаконичное решение.
Проблема в архитектуре самих классов: для того чтобы "вылить" данные из результата запроса в табличную часть, Вы должны использовать промежуточный контейнер - таблицу значений, хотя в принципе он не нужен. Либо вы "руками пишите" цикл обходы выборки запроса и заполняете построчно табличную часть.
Даже если будет миллиард строк, то больше времени потратится в другом месте, а не в загрузить-выгрузить. Например, при выполнении запроса или записи объекта. Просто кто-то занимается ерундой и оптимизирует что-то локально вместо оптимизации системы в целом.
Комментарии в коде и правда не нужны. Это признак непонятно написанного кода или обычно пишут очевидные вещи.
Тут еще друга беда есть. Исторически в 1С контроль версий реализован в виде системы "хранилища". И беда хранилища в первую очередь не в том, что там нет возможности ветвления, а в том, что нельзя быстро поднять историю а-ля blame или log в гите.
В итоге все доработки окружаются комментариями с указанием даты, ответственного за изменения, описания задачи по которой было сделано изменения.
Страшный рак в итоге получается и при этом никаким другим образом не передать информацию зачем и когда что-то меняли.
Сейчас у 1С есть плановая программа по переходу в GIT с EDT, вот только переход на новые рельсы очень уж тяжел после N лет работы в "Конфигураторе"
этой плановой программе уже лет 5
и учитывая что ЕДТ не поддерживает (и не будет) старый функционал типа "толстого" клиента - программе по переходу еще много лет впереди
ну и интерфейс ЕДТ это конечно огонь, когда даже по видео-инструкции хрен разберешь что и как должно работать. Привет 1С
Даже такие "комментарии" с авторством уже много лет как неактуальны, ибо есть gitsync.
Как гитсинк может помочь в сравнении-объединении конфигурации? Однажды пришлось сравнивать-объединять конфу, где куча доработок с одной стороны (эталон), куча доработок с другой стороны (надо накатить), при этом вторая ещё и более новая по обновлениям. Хотел бы пожелать делать эту работу в аду хотя бы лет тысячу всем, кто не ставит комменты авторства доработок.
А как комментарии помогут в этом? Всё равно нужно вникать в код. И делать это намного проще без мусорных комментов. При желании можно и нужно смотреть в историю в гите, там больше информации чем в комментах. Странно из-за "однажды" продолжать работать по-старинке.
Не обижайтесь, но у меня впечатление, что вы чисто теоретизируете, без практического реального применения теории. Вы правда не понимаете, что, имея сотню конфликтов (возьмём такое скромненькое сравнение-объединение, даже без десятков тысяч конфликтов), можно по комментам исполнителя пройтись и проставить флажки за час, а можно на каждый конфликт ходить и смотреть историю гита и потратить неделю? А ведь бывают и совсем интересные случаи, когда один кусок менялся несколько раз, а в источнике - какая-то версия из середины. Или когда кусок кода удалили по ошибке. Или когда кусок кода удалили не по ошибке. И в любом из этих случаев надо понять, что произошло. И можно это понять вот прямо здесь и сейчас, по комменту, а можно ходить по историям.
Наверное, в какой-то волшебной стране, где добрые мудрые программисты под управлением доброго мудрого РП начинали проект на гитах и вели его по конвенциям, и возможны какие-то свершения (хотя я до сих пор не видел ничего удобнее для решений конфликтов в коде 1С, чем сравнялка-объединялка от 1С), но в реальной жизни ваш проект может начаться, например, с того, что вам просто не дадут поставить гит (тру стори).
Смотря что считать конфликтом. Для меня это когда оно автоматически не мерджится. Таких случаев бывает очень мало, уж никак не "сотни". Тут ни истории, ни комментов как правило не нужно. Когда же возникает реальный конфликт объединения, то без истории никак не разобраться. В ситуации когда на просмотр истории гита тратится неделя (в разбирательствах что почему и как) флажки за час можно проставить разве что от балды.
P.S: стандартная "сравнялка-объединялка" вещь весьма убогая, не зря добавили поддержку внешних программ типа kdiff3.
Во-первых, сравнение-объединение имеет несколько хороших специфических инструментов. Всё-таки очень удобно, когда методы показаны и сопоставлены как методы и можно поставить флажок сразу на метод, а не на каждый конфликт внутри него. Про формы и макеты я вообще не говорю - простой реквизит или обработчик события может выйти в десятки строк XML. Теоретически, конечно, всё возможно, но попробуйте практически как-нибудь сравнить-объединить две конфы с конфликтами.
Во-вторых, гит ещё нужно поставить. Мне удавалось добиться разворачивания гита в одном из пяти проектов. В остальных никакие аргументы не действовали - вот вам конфигуратор, вперёд и с песней, какие ещё гиты?
Однако доже без них git вполне может справиться с этой задачей самостоятельно.
А вот, то что git для кучи не только 1С-ников, но и зачастую для их руководителей ругательное слово это, конечно, печально.
Тут важно не путать инструменты и цели. Очень часто бывают проекты, где набрать побольше "супер-модных" инструментов с "крутыми" английскими названиями и сделать максимально не как у всех - становится целью проекта.
Поэтому использовать гит ради использования гита ещё более тупо, чем не использовать его там, где он реально может пригодиться.
Если сравнить-объединить проще всего через конфигуратор, не понимаю, зачем бы я использовал гит и окологитовые инструменты для этого.
Сам я использую гит там, где надо постоянно лезть в историю, где много веток с одновременной разработкой. В этих вопросах гит в разы удобнее 1Сных инструментов (у меня как-то история по объекту формировалась час, а создать версию конфы из истории заняло день!). Но сравнивать-объединять я предпочитаю через 1С.
Eclipse, на базе которого делается EDT, почти канул в небытие за это долгое время. :(
Сейчас лучше IDE делают на базе открытой платформы idea https://www.jetbrains.com/ru-ru/opensource/idea/ . Я получаю очень много позитивных эмоций от работы в IDE PyCharm от jetbrains после многих лет работы в конфигураторе. Интуитивный, быстрый, всегда подсвечивает где у тебя какие ошибки (или проблемные места) в коде, удобные горячие клавиши, позволяет использовать много крутых фич git`а без консоли и т.д.
Комментарий в коде должен говорить не о том, что этот код делает, а о том ЗАЧЕМ этот код это делает.
Они не нужны там где ты можешь выделить отдельные классы с методами, разместить их в соответствующих каталогах и.т.п. В 1С когда у тебя в одном модуле размещены 95 процедур и 129 функций при этом все они так или иначе вызывают процедуры и функции из других модулей с таким же названием но с другой инструкцией (ПовтИсп, ВызовСервера и.т.п.) комментарии с описанием что это, какие у него параметры жизненно необходимы.
0.Комментарии в хранилище
не нужны. Ибо кому придёт в голову копаться в прошлом? Живи сегодняшним коммитом!
"РеализацияТоваровУслуг.Заказ.Контрагент.Партнер.КонтактноеЛицо.Телефон" в запросе.
Комментарий 1С:
Если в запросе используется получение значения через точку от поля составного ссылочного типа, то при выполнении этого запроса будет выполняться соединение со всеми таблицами объектов, входящими в этот составной тип. В результате SQL текст запроса чрезвычайно усложняется, и при его выполнении оптимизатор СУБД может выбрать неоптимальный план. Это может привести к серьезным проблемам производительности.
Мой комментарий:
Каждый программист, при написании кода, стоит перед выбором: повысить производительность или читаемость кода. Каждый случай индивидуален.
Тут два момента.
Производительность - это цель, а читаемость - это средство. Не совсем корректно их сравнивать. При этом сразу обращу внимание, что я считаю читаемость очень важным параметром кода. Но не единственным и далеко не всегда главным.
Написание запроса для выбора подподподвложенного поля совсем не означает, что код сразу становится совершенно нечитаемым.
На самом деле то что 1С позволяет такое писать не проблема 1С, любая ORM с ленивым чтением будет делать то же самое.
Писать так или нет тоже зависит от задачи, ну и для справедливости прям так никто не пишет, это большая редкость. Чаще просто получают через 1-2 точки и это нормально если ты дальше что то делаешь с этим объектом и если у тебя не HiLoad блок а что то что выполняется раз в месяц.
И чаще всего в разыменовываемых объектах не лежат огромные хранилища значений.
При этом СУБД нет особой разницы прочитать один реквизит или прочитать всю строку. Поэтому я бы не стал в большинстве случаев на это обращать внимание.
Нужно просто понимать что ты и для чего делаешь.
При получении через точку в коде, а не в запросе, да, есть много нюансов: 1С будет загружать в себя все промежуточные объекты, а если встретится какой-нибудь документ с большой табличной частью, то это явно скажется на производительности. В общих модулях для этого даже есть функция получения реквизита (или нескольких реквизитов), которая как раз строит запрос на основании метаданных только к нужному реквизиту. И это намного быстрее, чем получать объект, хотя и кажется, что кода написано немало.
В случае же необходимости получения через «несколько точек» от полей составных типов, кроме как написания запроса, причем с явным указанием типов промежуточных полей (т.е. через ВЫРАЗИТЬ...), не получится сделать оптимального кода.
Но по большому счету, достаточно просто однажды понять структуру того, как устроено все в базе, и вопросов по этим пунктам больше не возникает.
Лично мне больше доставляют не запросы на чтение - эти куски могут быть отпрофилированы и переписаны в соответствии с хБуками, а способ организации апдейта объектов. Когда, например, нужна групповое изменение атрибута справочника. С одной стороны понятно, что механизм платформы обеспечивает целостность объектов, но когда понимаешь, сколько под ним лежит ерзанья по таблицам...
Простите, а Вы не можете развернуть свой пример подробнее? В скольких случаях Вы используете в запросе своё многоточие? В каком контексте? И какую задачу, вообще, решаете?
Если у вас есть доступ к ИТС, то тут много примеров:
https://its.1c.ru/db/metod8dev/content/2662/hdoc
Пример поиска ошибок в заполнении ставки НДС для не резидентов.
ВЫБРАТЬ
РеализацияТоваровУслугТовары.Ссылка КАК ДокументПродажи,
РеализацияТоваровУслугТовары.Номенклатура,
РеализацияТоваровУслугТовары.СтавкаНДС,
РеализацияТоваровУслугТовары.НомерСтроки
ИЗ
Документ.РеализацияТоваровУслуг.Товары КАК РеализацияТоваровУслугТовары
ГДЕ
НЕ РеализацияТоваровУслугТовары.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС0)
И РеализацияТоваровУслугТовары.Ссылка.Контрагент.НеЯвляетсяРезидентом ВЫБРАТЬ
РеализацияТоваровУслугТовары.Ссылка КАК ДокументПродажи,
РеализацияТоваровУслугТовары.Номенклатура,
РеализацияТоваровУслугТовары.СтавкаНДС,
РеализацияТоваровУслугТовары.НомерСтроки
ИЗ
Документ.РеализацияТоваровУслуг КАК РеализацияТоваровУслуг
ВНУТРЕННЕЕ СОЕДИНЕНИЕ Справочник.Контрагенты КАК Контрагенты
ПО РеализацияТоваровУслуг.Контрагент = Контрагенты.Ссылка
И Контрагенты.НеЯвляетсяРезидентом
ВНУТРЕННЕЕ СОЕДИНЕНИЕ Документ.РеализацияТоваровУслуг.Товары КАК РеализацияТоваровУслугТовары
ПО РеализацияТоваровУслуг.Ссылка= РеализацияТоваровУслугТовары.Ссылка
ГДЕ
НЕ РеализацияТоваровУслугТовары.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС0)
Совсем было бы хорошо, предвыбрать все ставки НДС и добавить вместо отрицательного условия еще одно внутреннее соединение.
Что касается скорости:
1. Есть ли индекс у НеЯвляетсяРезидентом
2. Убрать НЕ в условии СтавкаНДС
Теоретически внутреннее соединение должно быть быстрее, но на практике получается или одинаково (одинаковый план запроса) или левое соединение быстрее
Примеров - полный гугл
Убрал НЕ, ничего не изменилось, абсолютно то же самое время выполнения, причем даже откинув статистику SQL (для чистоты в копии базы проверил).
Для чего эта оптимизация ради оптимизации? Ну генерируется левое, а не внутреннее соединение, не вижу ничего плохого. Как уже написали, вполне возможно, что план запроса вообще будет одинаковым.
Для чего эта оптимизация ради оптимизации
Недавно проходил вебинар/мастер-класс по оптимизации запросов для 1С, где конкретная компания рассказывала о своих внутренних стандартах. В частности - про замену "Не..." на внутренние соединения, которая (возможно, но сама компания не проверяла) в определенных условиях, дают прирост, а может быть и не дают, но "так заведено" (что нормально для внутренних стандартов). После чего астрологи объявили неделю карго-культа по оптимизации и переписыванию запросов.
Собственно, замена НЕ на внутренние соединения у нас работает просто отлично.
Не проверяли практически же мы разницу «ЕСТЬ НЕ NULL» vs «НЕ ЕСТЬ NULL».
Это наша компания, да
Значит, я угадал.
На нашей скромной базе в 7,8 ТБ это работает
"У меня такая же нога, но не болит". Это я к тому, что у вас работает - замечательно, но наверное не стоит свои внутренние стандарты продавливать в массы, тем более в обсуждении, которое к оптимизации запроса вообще не имело отношения.
А теперь сравните читаемость запросов.
Ответьте себе честно..."сколько секунд вам нужно, что бы понять что делает запрос первый и второй?"
Автор статьи внезапно попал из своего уютного мирка "правильной разработки" в мир "кровавого интырпрайза".
вокруг стоят три кольца оцепления с пулеметами чтобы случайно не пропустить в индустриую того, кто не готов следовать этим годами сложившимся традициям
Эта традиция называется "результат должен быть вчера!". И сначала в авральном режиме задача решается "в лоб", а через пару месяцев вспоминается присказка "работает - не трогай!".
Обговнять можно любой инструмент (не только язык программирования. Например молоток: в "кривых" руках бьет не по шляпке гвоздя, а по пальцу. В особо запущенных случаях - еще и по лбу).
Не подумайте, что я ярый поклонник, но 1С прекрасно решает свою прикладную задачу. Менеджеру и бухгалтеру пофигу насколько прекрасен код: его волнует только то, что он написан вовремя, выдает нужный результат и за приемлемый срок. Для остального есть площадки, на которых программисты меряются алгоритмами.
Если рассматривать эту статью как предновогоднее/пятничное чтиво то ловите в копилку
Мы обращались в фирму 1С с предложением ввести в язык (речь идет о версии 6.0) следующие конструкции : ПОЧЕМУ БЫ И НЕ — проверяет условие еще раз (самый частый глюк старой 1С) НЕПРЕМЕННО — выполняет оператор без сбоев и зависаний ОТНЫНЕ — присваивает значение переменной так, чтобы оно там действительно оказалось. (присвоить переменной вида, к примеру, «Справочник» значение в языке 1С — порой очень непростая задача, иногда требующая конструкции аж из 4-х операций) ВО ЧТО БЫ ТО НИ СТАЛО — выводит текст отчета который без этого оператора выводится через раз. НЕ СПАТЬ — отключает внутренний глюкогенератор Я СКАЗАЛ — выполняет команду до тех пор, пока она не выполнится. ИМЕТЬ СОВЕСТЬ — приостановить выполнение команды при её зависании.
- Предлагаю в 1С внедрить новую директиву: &НаКлиентеНоЕслиЧоТоИНаСервере
- лучше сразу: &ИменемБорисаНуралиеваВыполнисьГдеБыНиБыл
Почему-то фирма не прислушалась к нашему мнению..
А если серьезно, то язык и вся инфосистема развивается в достаточно правильном направлении, не надо впадать в отчаяние
1С это в любом случае быстрое программирование, потому что там результат нужен вчера
Так же как и в быстрых шахматах приходится жертвовать красотой ради результата но не всегда
Главное - это понимать, что и зачем пишешь конкретно ты. Это уже половина дела.
"Наличие знаний не гарантирует адекватного их применения" - вот что хочется сказать за и против использования указанных шаблонов и действий.
На все можно посмотреть с других сторон:
Писать в комментарии описание к задаче может быть единственным ключиком для понимания происходящего при отсутствии документации или устаревших версиях (как очень часто бывает). Кусок кода может сам по себе может ровным счетом ничего не сказать о причине его написания, и даже запутать. А времени на что, чтобы разобраться во всех взаимосвязях может уйти неприлично много.
Поскольку негативные результаты использования конструкции "через точку" описаны, обозначу варианты когда же все-таки можно допустить использование: если нам нужно разово обратится к нужным данным и сделать это нужно максимально быстро. Если в процессе интерактивного взаимодействия нам не нужно брать из базы многократно одни и те же данные, что использование данной конструкции не влияет на получение результата с точки зрения использования, но повышает читаемость и понимание происходящего. Зачем тратить время на создание громоздкого запроса к базе, который будет использован для получения всего одной строки? Опять же область применения такой конструкции сужается, важно понимание что мы не будем нагружать базу таким методом, т.е мы должны быть уверены что данных в таблицах, к которым обращаемся, должно быть немного.
-
-
Безусловно правильно проектирование конфигурации и базы данных с минимально необходимым количеством объектов. Но есть варианты, когда действительно важно разделить модули по разделам использования, особенно если доработки ведут разные поставщики услуг.
"God object" - вы описываете извращенное понимание и применение таблицы или базы для хранения настроек, шаблонов и повторно используемых значений. Считаю что такие таблицы должны быть для удобства, причем должна быть возможность менять данные настроек интерактивно. Опять же, для каждой задачи нужно придумать свою структуру во избежание излишней гибкости, так и во избежание ограничений по хранению нужных данных.
Для того чтобы определить, использовать ли "Try", нужно все же попытаться найти причину возникновения исключений. Большинство явно не горит желанием разобраться и потому действительно используют не по назначению. Но как всегда, есть исключения, в основном это обработка внешних событий.
Про метод Выгрузить() как-будто немного зависти есть только потому что такой метод существует :) Все методы нужно применять с пониманием, когда это можно использовать и это оптимальный вариант. Когда структура идентична. Почему нет? У Вас есть сведения что метод работает некорректно? Зачем в очередной раз изобретать велосипед если для этого и сделаны такие методы. Или может зачем использовать фреймворки? Тру программисты только на ассемблере пишут.
Причиной этому является в основном непонимание заказчиком потребностей и неспособность задать правильные вопросы на начальных этапах разработки. В итоге достаточно часто интерфейсы выглядят монструозными :) после внесения кучи правок и фич. Изначально все стремятся достичь совершенства в соответствии с собственным пониманием и опытом, но потом одна уступка за другой... и приходится все перепроектировать...
-
-
Если честно, я не очень понял суть Вашего комментария. Вы не поняли, что статья - сарказм, или Вы говорите о том, что это всё не должно быть сарказмом, а должно быть написано в реальных руководствах для программистов 1С?
Ну почему-бы не объяснить для не-1Сников, что на самом деле всё не так просто? Добавлю туда же:
1) 1С, к сожалению, не сделала в обычном конфигураторе ничего для сохранения комментариев в запросе, из-за чего у вас есть возможность писать комментарии перед ним (что для запросов в 2000+ строк зачастую не очень осмысленно), либо писать внутри и бережно, вручную потом восстанавливать после конструктора (либо редактировать запрос вручную).
...
3) Та же БСП настолько велика и всеобъемлюща, что поиск нужной функции в ней может в разы превзойти время написания своей. И ещё не факт, что эта функция потом не изменится...
4) В этом месте вспоминаем, что, например, цикл в одну строку работает быстрее "красивого цикла".
5) Зачастую при первоначальном программировании не очень понятно, куда именно пойдет данная функция/процедура (ну кроме очевидных сервер/клиент). По идее после окончания прототипирования хорошо бы отрефакторить, но на это не всегда есть время и деньги.
...
7) Попытки не всегда используются в критичных местах кода, иногда можно просто что-то попробовать сделать и идти дальше.
...
...
...
Вообще, у 1С (да, наверное, не только у 1С) есть определенная специфика — волшебная фраза "надо вчера". Зачастую такие обработки/отчеты/решения нужны на один раз. В таких случаях обычно не важно, насколько красиво/оптимально сделано — а важна именно скорость выполнения. К сожалению, иногда такие решения живут значительно дольше, чем ожидалось. Ну так исправление этого — ваша (наша) же работа, о чём тут ныть?
Просто когда шутят над тем, что ты используешь каждый день и при этом называют твой труд "ректальным" - немного обидно.
В целом я поддерживаю Grigorenkovic во всех пунктах его комментария, кроме 9, в ней автор статьи просто наступили на больной мозоль.
Сразу вспомнил эту миниатюру из Большой разницы - Мы Гестапо, делать больно - это наша профессия)
Чтобы не было больно, можно, например, перестать использовать методики из этой статьи, и начать работать менее ... ректально;)
Не делайте так!
Как же не делать, если функция НАЙТИ вместо запроса, которую тут "заклеймили ректальной", единственная функция в языке 1С которая позволяет вести поиск данных с учетом различий в регистре.
Вот и приходится делать сразу два "ректальных" решений в одном куске кода (ВЫГРУЗИТЬ И НАЙТИ):
Запрос = Новый Запрос("ВЫБРАТЬ
| РеализацияТоваровУслугИТ_КодыМаркировок.Ссылка
| РеализацияТоваровУслугИТ_КодыМаркировок.СерийныйНомер
|ИЗ
| Документ.РеализацияТоваровУслуг.ИТ_КодыМаркировок КАК РеализацияТоваровУслугИТ_КодыМаркировок
|ГДЕ
| РеализацияТоваровУслугИТ_КодыМаркировок.СерийныйНомер = &КодМаркировки");
Запрос.УстановитьПараметр("КодМаркировки",ИскомыйКМ);
ТаблицаНайденныхКодов = Запрос.Выполнить().Выгрузить();
//а теперь ищем еще раз, уже через регистрозависимый способ поиска
НайденныеСтроки = ТаблицаНайденныхКодов.НайтиСтроки(Новый Структура("СерийныйНомер",ИскомыйКМ);
Если НайденныеСтроки.Количество() Тогда
//Действительно найденны КМ именно те
КонецЕсли;
Заклеймили не саму функцию Найти(). Заклеймили только её необдуманное использование. Более того, весь сарказм статьи направлен на необдуманность. На то, что людb знают способ решения проблемы, но не задумываются над тем, как всё устроено под капотом, как всё написанное будет ложиться в парадигмы и в последующую жизнь системы и т.п. Многие знают, что найти что-то можно через Найти - и им больше ничего неинтересно. Они используют Найти не потому, что регистрозависимое, а потому что им и неинтересно что-то ещё знать.
А ведь это и есть то самое, что отличает недомиддлов от миддлов и сеньоров. Но в сфере 1С (да и не только, будем откровенны) очень много недомиддлов стоят на должности миддлов, сеньоров, архитекторов, РП и т.п.
В 8.3.20 в язык запросов добавили функции
ВРег(Upper) – преобразует все символы строки в верхний регистр.
НРег(Lower) – преобразует все символы строки в нижний регистр.
Так что Вы сможете всё проверки делать в запросе.
UPPER и LOWER предназначены для другого и добавляет SQL дополнительную работу.
Для поиска правильно использовать COLLATE.
Но в нашем примере новые функции не спасут отца демократии, поскольку изначально база 1С создана в рекомендуемом режиме сортировки: CYRILLIC_GENERAL_CI_AS (Порядок словаря, без учета регистра).
Вот если бы 1C предложила в язык запросов такое: "ПОДОБНО_С_РЕГИСТРОМ"
SELECT * FROM myTable WHERE myField = 'sOmeVal'
COLLATE CYRILLIC_GENERAL_CS_AS10) Я бы написал:
Если Найти("Справочники,Документы,Планы видов характеристик,Планы счетов,Планы счетов,Задачи,Бизнес-процессы,Планы обмена",ЭтаФорма["ДеревоМетаданных"].НайтиПоИдентификатору(ТекСтрока).ПредставлениеОбъекта)>0 Тогдано не факт, что это было бы оптимально. Потому что то, что выглядит оптимально в коде - не всегда оптимально по факту. Вот, например, мой старый комментарий:
// В текущей версии 1С "Найти" работает быстрее даже сравнения ПрефиксСтроки="SUBJECT:"
Если Найти(ПрефиксСтроки,"SUBJECT:")>0 Тогда
СтрокаДаты = ТекСтрокаКонвертаСокрЛП; Плюс 1С обычно имеет историю разработки, и, зачастую, всё начиналось с одной строки в "если", на двух строках оптимизировать было ещё рано, а на трёх — уже поздно. Причём в 1С тоже действует святой принцип "работает - не трожь", так что рефакторинг будет производится только когда это место всех достанет.
Если бы статья была на инфостарте, я бы даже еще несколько пунктов добавил, но здесь большинство сарказма не увидели :) типа в очередной раз убедились какие 1сники недопрограммисты
Ведь кто ещё смог бы научить его определять по звуку вентилятора охлаждения процессора, что операция, которая висела в 1С 40 минут, уже завершилась?
Лучшая шутка в статье.
Вот уж действительно — вредный совет… ) Во-первых, зависит от задачи: если вы работаете с единичными объектами: заполняете программно новый объект/запись, либо формируете какую-нибудь печатную форму — получение значений полей через точку вполне оправданно, хотя бы даже просто в плане громоздкости/читаемости кода… А во-вторых — запрос запросу рознь! Тут в комментариях уже были примеры, но на мой взгляд не достаточно сильно в них акцентировали внимание на ключевой момент: получение значений через точку В ЗАПРОСЕ гораздо опаснее, чем получение значения через точку в коде! ;) Потому, что в коде это точно единичный объект, а в запросе это неявное левое соединение. Причем в определенных случаях (Регистратор.Номер) — не одно, а десятки!
У вас получается что через точку в коде нельзя, а запросом можно. В то время как на самом деле нельзя (по крайней мере, не желательно) именно комбо: в запросе через точку! )
Дело в том, что в 1С много встроенных прямо в язык штуковин, облегчающих написание кода. При том совершенно не обязательно эти штуковины оптимальны и не сказываются на производительности.
Аналоги? Ну представьте, что у вас есть библиотека, а ней есть метод, который превращает дерево в плоский массив. Понятное дело, что эта функция имеет место быть и вполне может использоваться для каких-то задач. Но ректальный программист использует её, например, для того, чтобы потом обойти этот массив и вывести сообщение. Т.е. ему лень писать рекурсию для обхода дерева. Поэтому он вначале использует функцию для преобразования дерева в массив, а потом уже этот массив в цикле обходит и по каждому элементу выводит сообщение. Т.е. две циклические операции вместо одной - и всё это просто потому, что ему лень написать метод на пару строк длиннее. При том, что размер дерева может быть практически любой.
ТЧ.Загрузить(Запрос.Выполнить().Выгрузить());
Пример вне 1С:
Cначала сразу загружаем в память текстовый файл на много Гб. Потом используем процедуру, чтобы распарсить весь этот файл разом (допустим в каждой строке файла хранится отдельный json) и получим очень большой массив словарей [{id: 1, value: 100}, {id: 2, value: 200}, ..., {id: 999999999, value: 1024}].
Чтобы в итоге как-то обработать полученную информацию:
if record.value > 300:
return record.id
или
for record in line:
sum = sum + record.value
return sum
Это конечно же пример того как делать не надо :) Вместо этого следует построчно считывать и обрабатывать информацию в цикле. Потому что оперативная память не резиновая. И еще не факт, что потребуется обработать всю информацию целиком.
Самое главное не сказали: а собственно,почему ректальное программирование в моде в мире 1с? Тут все просто: порог входа на столько низкий, что доморощенных одинэснегов стало пруд пруди. Профессионал он и на 1С будет писать как профессионал. Недучке что не дай - родит качественный говнокод. И GOD-object ни фига не в 1С придумано и Hibernate к месту и не к месту тоже.
У 1С ужасно много недостатков. Это так. Но у нее есть и несколько неоспоримых достоинств:
1) только 1С покрывает все нужды бизнеса в автоматизации с 0 до, скажем, 1000 человек.
2) 1С - это экосистема. Если бизнес берет тиражное решение на 1С (или бог с ним - даже заказывает самописку на 1С), то он никогда не останется с этим творением 1 на 1. Всегда есть возможность сменить тупого/наглого/ленивого исполнителя на другого и продолжать бодаться.
3) С точки зрения мониторинга законодательства тоже мало альтернатив. Именно благодаря 1Ске сейчас один бухгалтер в состоянии вести 3-4небольших конторы, в то время как еще лет 20 назад вполне нормой было даже в маленькой шаражке по десятку бухов держать.
4) С момента задумки некой киллер-фичи, до процесса ее вывода в пром может пройти крайне низкое время. Надо хитрозадую систему скидок? 1 прогер не торопясь за месяц родит полноценную систему и она будет работать (даже если там внутри будет говнокод, ага).
Кстати, именно специфика области применения и рождет говнокодеров. Запрос в цикле? По фиг. У вас в табличной части максимум 100 строк. а в конторе 10 рабочих мест. Кроме душевных терзаний профессионалов такой говнокод не будет иметь никаких последствий с точки зрения производительности. Понятно, что если такой гений придет в контору покрупнее, то уже нужно живительный ректальный криптоанализ применять, для выпрямления рук. Но в ШаражМонтажКонторе - и так сойдет.
Постоянно слышу какой-то комплекс неполноценности от 1С-ников. Статья ведь совсем не о том, что 1С плох. Она о том, как ректальные 1С-программисты (которых там много, но далеко не подавляющее большинство) не хотят ничего знать и ни о чём думать.
Но упорно натыкаюсь на комменты, где пытаются оправдать 1С. Зачем? Она разве нуждается в оправдании? Почему вы чувствуете неуверенность в себе, занимаясь 1С? 1С, как и вообще любой язык, фреймворк и среда - это просто инструмент достижения цели проекта. Обычно холивары на тему "труЪ" устраивают джуны с тремя днями опыта, которые и "свой" язык не знают, не то, что могут сравнить его с 1С.
Поэтому, думаю, вам надо перестать беспокоиться и оправдывать 1С - это не нужно. 1С - это просто одна из технологий в мире технологий, с плюсами и минусами.
«Есть всего два типа языков программирования: те, на которые люди всё время ругаются, и те, которые никто не использует.»
Bjarne Stroustrup.
https://habr.com/ru/post/144632/
Я вот не 1С програмист, но как и многие "тру" кодеры зачеркнуто програмисты, увидел в статье очень многое из того что видел. Такой вот калабур ;-)
Как видите статья зашла, я же говорил вас много тема живая и актуальная.
1С - это просто одна из технологий в мире технологий, с плюсами и минусами.
Я ровно это и хочу показать своими комментариями.
По поводу комплексов - их нет. А вот негативное отношение к 1С со стороны хабрасообщества - есть (скорее всего, среди той части, которая джуны без 3 дней опыта).
Да, среди 1сников просто огромное море говнонедокодеров, но ситуация проста: порог входа. Теперь любая кухарка может управлять 1ской.
А вот негативное отношение к 1С со стороны хабрасообщества - есть
Почему вас это беспокоит? Кстати, ни одного холивара здесь в комментариях от неодинэсников не было. А вот комплекса неполноценности от одинэсников, почему-то, очень много. Что очень странно для меня. Во-первых, зачем вообще переживать от того, что кто-то думает? Во-вторых, если вообще хочется чем-то меряться, то ни одной прямой линейки нет, зато есть много косвенных. В 1С вполне средняя по ИТ зарплата, средняя по ИТ занятость, средний по ИТ спрос и т.п. Не понимаю, зачем писать портянки оправданий 1С, тем более там, где никто 1С даже ни в чём не обвинял.
Повторюсь, 1С - это просто одна из технологий в мире технологий, с плюсами и минусами.
Да, среди 1сников просто огромное море говнонедокодеров, но ситуация проста: порог входа. Теперь любая кухарка может управлять 1ской.
Порог входа постоянно повышается. Говнокодеров везде много. Собсна, потому я и сделал приписку, что многие узнают эти методики, даже ни дня не работая в 1С. И, как показали
Бывают случаи, когда используется только платформа — наблюдал БД, пересаженную с Delphi/Paradox сотрудником по собственной инициативе, просто потому что мог. В итоге он ушёл, а организация осталась с новой лицензией и совершенно уникальной конфигурацией.
Бывают случаи, когда используется только платформа — наблюдал БД, пересаженную с Delphi/Paradox сотрудником по собственной инициативе, просто потому что мог
Бывает, да. Я допустим так работаю ("совершенно уникальные конфигурации" в смысле, а не "перевел на 1С потому что мог"). О рисках всегда предупреждаю заранее. В чем вы видите проблему?
Та БД к бухгалтериии не имела ни малейшего отношения, т.е. вся стандартная конфигурация была просто выброшена
90% решений на 1С тоже к бухгалтерии отношения не имеют, в общем-то. При этом стоимость именно готовых решений на 1С - копеечная. Вопросы скорее в стоимости пользовательских / серверных лицензий. И внедрении/адаптации.
Перенести можно было на любую платформу, человек сделал на том чем владел, ни с кем не согласовав. Позже руководство было вынуждено приобрести лицензию на платформу.
Какой-то 1С-ниндзя, который незаметно для руководства переписывает все на 1С, а руководство это замечает только когда он уволился =)
А к простой БД с исходниками приложения добавился необъятный монолит, который придётся допиливать у соответствующих специалистов. КМК получился не самый оптимальный вариант для пары табличек и пары формочек.
А монолит-то необъятный откуда появился, если исходная система была из пары табличек и пары формочек? Все-таки либо 1С-ник взял что-то готовое (допустим, была база из двух табличек по расходу материалов на производстве, а 1С-ник развернул ERP) или руководство "забыло упомянуть", как этот монолитный монстр вырос из их же "хотелок" на этапе замены Delphi на 1С. Так-то небольшую базу из пары табличек на 1С напилить и сопровождать будет скорее всего дешевле, чем на Delphi (если там и правда была пара табличек) - любой студент справится.
Таки да. Ну а что такого — данные вводятся, выборки делаются. А потом внезапно инвентаризация ПО.
Под монолитом имел в виду собственно платформу. К запорожцу гусеницы прилипли. Вы бы к примеру взялись сконвертировать уникальное приложение обратно в Delphi или любой другой язык за цену лицензии?
Вы бы к примеру взялись сконвертировать уникальное приложение обратно в Delphi или любой другой язык за цену лицензии?
Лично я - вряд ли, мой опыт хождения по граблям в основном ограничивается 1С, поэтому не взялся бы.
Сама платформа никакой "монолитности" не добавляет, если решение и правда из двух табличек. Да, скорее всего будет работать медленнее, чем нативное, но серьезного оверхеда не будет.
Если абстрактный пример - то упрется все в наличие ТЗ (или наличие человека, который разбирается в 1С и может по конфигурации это ТЗ написать).
P.S. Цена лицензии - тоже понятие растяжимое. Может быть и правда дешевле все переписать, хоть на Delphi, хоть на, прости господи, Access'е, чем покупать лицензии. Но так-то на Delphi искать разработчиков в 2021 году, мне кажется, сложнее, чем на 1С.
Все так и есть, 1С это действительно доступно и всерьез.
Единственное в чем я с вами не согласен так это в масштабе до 1000 человек. Проблем не будет с типовыми решениям до 200-300 пользователей.
Дальше уже начинаются сложности, нужны эксперты которые за этим будут следить. Но даже для 300 человек сложно найти не допиленную типовую, и вот дальше у платформы появляются проблемы:
Неквалифицированные кадры (низкий порог входа, низкие ЗП)
Запредельная сложность крупных конфигураций (Отсутствия ООП, Типизации, Какой либо структуры хранения модулей)
Сложность прикладной части (это отдельная боль).
Отвратительная производительность платформы (тут ниже есть мой пример сравнения с java)
Игнорирование прогресса в разработке СУБД начиная с 92 года. (Газпром вынужден тратить миллиард на сервера СУБД под 1С потому что у 1С есть файловый вариант для ларька который дережит Арсен, и все возможности платформы по работе с СУБД ограниченны этим вариантом).
Жесткий монолит (тут без коментариев, достаточно посмотреть как реализована бесшовная интеграция с документооборотом, я когда смотрю всегда восхищаюсь тем сколько сил и труда было вложено в то что в WEB разработке идет бесплатно).
Сжатые сроки + бизнес на первом месте, а отдел автоматизации где то между завхозом и гаражом, прибыли не приносит, сидят там одни дармоеды и вот это все...)
Причем эти пункты нужно не складывать а перемножать. И
1) только 1С покрывает все нужды бизнеса в автоматизации с 0 до, скажем, 1000 человек.
Не только. Есть OfBiz. Как система для операционной деятельности более-менее вменяемой фирмы - самое оно. Классом выше, чем все, что я видел и ковырял в 1С и подобных продуктах.
Вся соль 1С как раз в том, что нужда бизнеса - особенно бизнеса маленького - в автоматизации в первую очередь касается как раз не операционной деятельности, а регламентированного учета, сдачи отчетности, взаимодействия с разнообразными государственными информационными системами и т.д. А тут у 1С в РФ просто нет достойной альтернативы как ни крути, потому что ни один OpenSource или стартап не будет так же тщательно следить за каждым чихом наших регуляторов и реагировать во вменяемые сроки.
А вся организация именно операционной деятельности бизнеса до, скажем, 100-200 человек вполне реализуется в понятном каждому экселе или гугл таблицах. Если грамотно наладить процессы, то и больше можно. А когда компания дорастает до того, что ей реально надо автоматизировать операционную деятельность, то она обычно к этому времени уже обросла продуктами 1С для регламентированного учета, поэтому использует то, что знакомо.
И при всей моей любви к 1С это печальная на самом деле ситуация, так как отсутствует конкуренция. Но честно говоря, единственный выход, который видится, находится вне возможностей как самой 1С, так и сообщества или потенциальных её конкурентов. Это прекратить регулировать бизнес с такой скоростью, чтобы поддерживать отчетность можно было только поддерживая целый штат достаточно грамотных и от этого очень дорогостоящих технических специалистов.
а регламентированного учета, сдачи отчетности, взаимодействия с разнообразными государственными информационными системами и т.д.
Все зависит от организационной схемы бизнеса. Например, пекарня. Которая производит 10-12 продуктов, 3-4 человека персонал. Юридически это может быть какой-нибудь ИП с упрощенным налогообложением (или типа патента, не знаю как это сейчас называется). То есть юридически - почти учета не надо. Но нужно быстро, качественно и с минимальными усилиями получить MRP/ERP/CRM и потом со всякими иными приблудами (типа электронной коммерции). Тут Ofbiz гораздо интереснее 1С. Я много лет использовал 1С, с самых ранних версий, и до новейших. Все там неплохо, в определенной логике бизнеса - все работает.
Но когда столкнулся с реальным производством, реальными иными требованиями к бизнесу (в Польше), то понял, насколько же в 1С все криво, косо и устарело. По сравнению с тем же Ofbiz. Ну и открытость проекта, плюс его работа на Linux перевесила все плюшки от 1С.
Если же нужен "бухучет" - то да, 1С - прелестно.
Дело в том, что решение о внедрении продукта - очень мультифакторно. То, что есть какая-то сферическая идеальная система совсем не означает, что выберут её. Вот несколько параметров только навскидку:
Количество экспертизы на рынке. Если купить 1С, то щелчком пальца можно найти и программистов, и аналитиков, и обучаторов и большие команды внедрения и т.п. Насколько бы офигенной не была система, она не нужна, если я не смогу себе найти аналитика, чтобы мне поставил учёт в этой система пять минут назад.
Количество кадров на рынке. Оператора 1С, бухгалтера 1С, РП 1С, программиста 1С найти несложно. Насколько сложно найти мне в штат оператора вот этого Офбиз (не чванство, просто действительно первый раз слышу о такой программе)?
Из п. 1 неизбежно вытекает стоимость и возможность доработок. Когда мне нужна будет печатная форма с моим гербом или отчёт продаж с учётом погоды на день продажи, я могу это всё купить занедорого - 1С позволяет дорабатывать, а на рынке много рабочей силы. Как с этим у офбиз? Смогу ли я найти программиста? По какой цене? Где?
Гениальность 1С вообще не в качестве продукта. У них вот буквально лет пять как вообще о каком-то качестве можно говорить, до этого ёжики плакали и кололись, все, кто работал с 1С, её ненавидели, особенно пользователи. Гениальность в том, что они смогли создать дешёвый продукт, выполняющий задачу, создать сеть распространителей "от тайги до британских морей" и создать огромный вал рабочей силы любого качества в этой сфере.
Любопытства ради, а что конкретно, по сравнению с OfBiz "криво, косо и устарело" (может где-то можно покрутить демку, сравнить, не перелопачивая наугад всю документацию и тыкаясь в кнопки)? Вы про платформу или про конкретные решения на платформах?
Там же можно скачать полную версию, с демо базой данных. Там же есть и линк на демку, работающую он-лайн.
а что конкретно
Трудно коротко ответить, самое точное - почти все. Я не супер-специалист в OFbiz, могу не точно формулировать, по попробую.
Прежде всего, общий подход: взяты стандартные инструменты, на них все сделано. Может быть поэтому и нет инструкций и документации к Ofbiz в каком-то более-менее приемлемом виде. Есть инструмент, указано какой, все его описание есть в доках самого инструмента.
Опять же, OFbiz - это фреймворк, не готовое решение, его надо допиливать. По моим ощущениям - не меньше, чем 1С 8.
Структура данных и основные подходы - взята модель из книги The Data Model Resource Book Revised Edition Volume 1 A Library of Universal Data Models for All Enterprises Len Silverston. Читаете книгу - понимаете что, как зачем и почему реализовано в Ofbiz.
Бизнес логика - Java, Java EE, XML and SOAP. Еще что-то, я пока не разбирался.
Система управления базами данных - почти все равно какие, что понравится.
Локализация - стандартные методы i18n.
Разработка, допиливание под себя - тоже все стандартно IDE (Eclipse...), Git. Сборка - Gradle. Понятно, что все стандартные методы отладки - все это есть.
Отчеты - на BIRT.
Конкретнее:
Все изначально работает под Linux. И занимает совсем немного места - от 40 до 300 Мб. Сейчас у меня с базой работы за год, со всеми картинками продуктов - под 600 мегабайт. Больше всего занимают именно картинки.
Работает под JVM, не быстро, но и не тормозит.
Иной подход ко всем объектам "системы" в целом. Сначала создаются элементы системы, потом - связи между ними. Причем связи могут быть разных типов, "один ко многим", "один к одному". Что позволяет, например, реализовать многомерную классификацию продуктов. Продукт может быть в разных "категориях" и "каталогах" одновременно.
Иная модель данных. Не все там привычно, но в ней есть смысл. Особенно там интересно реализована работа с разными единицами измерений: штуки, килограммы, упаковки, ведра, емкости для одного продукта, плюс пересчет этого зоопарка во время работы.
Система "ролей", на ней построена не только безопасность, но и логика работы системы.
Основное - события в системе. Они так или иначе интерпретируются для целей бухгалтерского учета. Сам учет - только малозначительный "довесок" для представления информации в определенном виде для бухгалтеров.
ERP/MRP/CRM и еще куча всего - реализованы по стандартным правилам, ничего особо не выдумывали. Типа брали best practices и описания из книжек - и реализовали.
Локализация. Да какая угодно может быть. Мне нужна польская - сижу делаю, часть заказал на стороне. Знакомые сделали полную локализацию на русском, больше, чем сейчас есть в проде самого Ofbiz. Но не поняли еще как коммитить, разберутся - будет у всех полная локализация на русский, "из коробки".
Можно вести "управленческий учет" от имени любого количества фирм с консолидацией балансов, по международным системам учета (IAS), по разным планам счетов.
Разные производственные функции - все что нужно есть и даже иногда работает.
Все это вроде как есть в каждом нормальном продукте, но уровень реализации - разный. 1С со своим "наследием" выглядит хуже. Трудно все это описывать, проще самому попробовать немного поработать просто с каталогом продуктов. И все становится уже видно. Ну или с контрагентами, там тоже весело.
И да, Ofbiz вовсе не идеал. Глюков - куча. Но мне больше нравится.
Все это выглядит гораздо худшим решением, чем 1с для мелкого и среднего бизнеса. Странно это упоминать как хорошее решение для пекарни в 10-12 человек. Готового решения нет, документации нет, работает под linux в котором обычные люди мало работают и даже простые задачи им делать будет сложно, размер базы что 400мб, что 10 гигов никого волновать особо не будет при размере современных дисков. И в той же хорека, если захочется интегрироваться с r-keeper или storehouse в 1с просто можно взять готовое решение, то в OFbiz придется писать решение для интеграции. 1с может обслуживать то еще удовольствие бывает, но зато из коробки может решить кучу проблем. Если нужно решать уникальные задачи делать это не на 1с разумно, но для обычных небольших бизнесов явно проще взять коробку с 1с.
Для оператора может и всё равно, хотя банально остатки вывести из мелкой базы будет побыстрее, а для генерации отчётов на базе покрупнее вполне может потребоваться распределённая база с синхронизацией, ну или генерировать отчёты по ночам.
Полностью согласен. Единственный кейс, который я бы видел для этого офбиза - это команда с кучей внедрений, которая даёт клиенту в два-три раза меньшую цену за внедрение, чем за 1С, причём под ключ. В остальном - больше похоже на автомобиль, который забираешь не со стоянки, а с конвейера завода, разобранным до винтика, а винтики ещё и с правой резьбой, а гайки не 13, 17, а 18.4 и 22.6, и вообще многое ещё надо паять и варить. И всё это - без документации.
И всё это - без документации.
но зато из коробки может решить кучу проблем. Если нужно решать уникальные задачи делать это не на 1с разумно, но для обычных небольших бизнесов явно проще взять коробку с 1с.
Все вроде бы верно... Но только на первый взгляд. Я сначала тоже точно так же решил, поставлю 1С, все в ней буду вести. Мне же нужен не сам бухучет, а именно учет типа "контроллинг", "управленческий учет". Еще раз: это не Россия, все нужно было в Польше. Местный софт - хуже 1С намного. И опять же, все заточено именно на "бухгалтерский учет".
В этот момент делали несколько проектов, в том числе и пекарню.
Попробовал разные варианты, и местные локальные, и 1С (благо опыт был немалый), и разные легковесные и средние MRP/ERP. Плюс у меня был какой-никакой опыт внедрения тяжелого софта, типа ACCPAC (теперь типа Sage 300 ERP).
В это же время разбирался с методологием GERAM-TOGAF, стандартами IEC 61512 , IEC 62264. В них описаны интересные модели организации бизнеса. Да, они выглядят сложными, типа такое для малого бизнеса не нужно и т. п.
Но когда стали делать производство "по всем правилам", а не просто "как выйдет" - то вспомнились все описанные в этих подходах процессы и модели. И получается, что в 99,9% случаев даже малые бизнесы "колхозят" на коленке кривое и косое подобие всего того, что там уже давным-давно отработано до мелочей.
Ну и была еще одна интересная цель: чтобы операционная деятельность всех проектов велась максимально просто для команды, которая такую деятельность и ведет. И это не мы, наша работа заканчивается на начале операционной деятельности. А далее - обычно, кто во что горазд. И проект часто "сыпется". А это плохо. То есть некая система MRP/ERP предполагалась, как некий прототип, шаблон, достаточно универсальный образец для большинства проектов.
Ну и консолидация балансов, плюс поддержка всей бизнес-деятельности. В том числе, для оптимизации налогов.
В общем, то что в GERAM описано как EOS. Опять же, бухучет и стыковка с гос. системами - вторичная, и малозначительная.
Сложность и вроде бы непонятность OFBiz сначала ошарашила. Но потом понял, что все там очень просто, только иная логика. Событийные модели всех стандартных процессов. Причем качественно атомизированные, разделенные друг от друга, хотя и несколько иные, чем принято в России.
То, что надо настраивать, допиливать - и что? В 1С вовсе не меньше выходило работы. То, что на Линукс - так это еще лучше. Я с 1992 до 2019 года работал только на продуктах MS. А теперь все выкинул и перешел на Линукс. За 2 месяца освоился, за 2 года вполне себе обслуживаю весь этот зоопарк. Ничего особо сложного не вижу. А я не специалист какой-то супер-пупер, не админ. Так, только немного разбираюсь.
Насчет документации. Тоже интересная тема. OfBiz реализует набор неких вполне стандартных бизнес-процессов. Если их не понимаешь - то и глубокая работа в OfBiz не выйдет. С другой стороны, человек на складе должен нажать одну кнопку - и все. Понимать ему не надо, как все это работает. И не стоит надеятся, что он прочтет инструкцию. Поэтому инструкции для "эникейщиков" не нужны. А для специалистов - они есть для каждого процесса и модуля. Не для самого OfBiz! А например, для Accounts payable, A/P. Все это совершенно стандартное, миллион раз описано в куче книжек. Зачем все это повторять?
Ну или BIRT. Вполне достаточно знать, что отчеты делаются на нем. Далее есть документация для BIRT, она что для OfBiz, что для матумбы - более-менее одинаковая. И так все модули и инструменты OfBiz.
Там же можно скачать полную версию, с демо базой данных. Там же есть и линк на демку, работающую он-лайн
Да, на оффсайте демку я нашел, просто вот при беглом взгляде "вау"-эффекта не испытал - поэтому и поинтересовался чем-то конкретным, чтобы исключить синдром утенка.
По вашим наводкам посмотрю (модели данных, каталоги и т.д.), спасибо. Вполне возможно, что что-то полезное почерпну.
И да, Ofbiz вовсе не идеал. Глюков - куча. Но мне больше нравится
Что бы он еще где-то был, этот идеал. Везде набор компромисов и граблей.
Забавно. Знаком с похожими перлами. Видел такой стиль программирования в на работающем решении. Делал программист который работает в "самой" роснефти. Там местами пожесче было. Приходилось исправлять. 1С прощает многое... Этим пользуются не компетентные и бестолковые индивиды которые называют себя программистами. Программирование это понятие вне синтаксиса вне платформы. Существует само по себе. Оно в голове, а не в компьютере. Если человек изучил синтаксис, то это не значит что он умеет программировать.
Спасибо за описание ценностей нашей организации !
Ректальное программирование как метод не должно ограничиваться технологиями 1С. Обращаюсь к сообществу с просьбой проекции и миграции передового опыта на другие технологии.
Самое печальное, что если будете писать лучше, чем выше приведенный метод, то просто уволят. Сократят. Ибо все будет хорошо. И вспоминается старый анекдот, как старый врач оставил на клинике сына, а тот возьми да и вылечи постоянного клиента, которого старый доктор лечил всю жизнь.
8 Загрузить-выгрузить Например, методы "Выгрузить" у результата запроса и "Загрузить" у таблицы.
А тот факт, что выборка медленней будет обходится, не смущает ? Выгружаю в ТЗ мы жертвуем ОЗУ, но увеличиваем скорость работы. Используя выборку сам процесс обхода более медленный. В типовых, например, наборы записей через Выгрузить() из запроса в Загрузить() набор записей много где грузятся. И были тесты на больших наборах данных, где это тестировалось. Выгрузить()->Загрузить() быстрее отрабатывало.
Вопрос в том, насколько большая ТЗ, сколько ОЗУ есть на сервере и насколько нужна скорость обхода. К чему такой однобокий подход.
Есть стратегия выгружать результат запроса в ТЗ частями, если ТЗ ну очень большая. Добавляя искусственный разделитель какой-то. И по частям загружать, но работая с ТЗ, а не с выборкой. Это будет быстрее
Ещё один пример: <...>.Найти(). Очень удобно использовать в цикле вместо, например, получения данных в запросе, ведь запросы писать сложно.
Потому что нужно использовать НайтиСтроки(), предварительно проставив индексы на колонки, по которым ищем. И поиск будет производится мгновенно.
Ректальное программирование: основы для практикующих 1С-программистов