Примечание: хотя статья адресована прежде всего одинэсникам, труЪ-программисты также могут узнать многие используемые методики или взять что-то на вооружение.
Одной из самых популярных и зарекомендовавших себя методологий программирования в 1С является так называемое ректальное программирование. Редкий проект внедрения и сопровождения учётных систем на платформе 1С обходится без его использования. Зачастую без знания данной методологии программистам даже бывает сложно найти работу в сфере 1С, потому что работодатели, особенно фирмы-франчайзи, в основном отдают предпочтение классическим, зарекомендовавшим себя методикам, а не новомодным заграничным веяниям.
В тоже время, данная тема освещена довольно скудно и программистам, даже опытным, приходится тратить тысячи часов на изучение ярких примеров ректального программирования. Иногда даже программисты со стажем затрудняются ответить на базовые вопросы, скажем - "Что лучше, запрос в цикле или получение данных через четыре точки"? Данный материал призван дать хотя бы базовое представление о методике ректального программирования и его успешного применения на проектах внедрения продуктов 1С любой сложности.
Что это?
Итак, прежде всего ответим на вопрос - что вообще есть ректальное программирование? Чем оно отличается от других методик? Какие преимущества даёт для программиста и его работодателя?
Ректальное программирование - это, прежде всего, программирование свободного человека, если хотите - венца творения. Это программирование, свободное от всяких предрассудков, навязанных рамок следования стандартам, параноидальной боязни демонстрировать свой код другим участникам проекта. Ректальное программирование - это путь состоявшегося программиста, уверенного в своём абсолютном превосходстве и компетенции, не нуждающегося в поучениях и не поддающегося стадному инстинкту постоянно обучаться.
В свою очередь работодатель, нанимая такого программиста, может быть уверен в том, что такой сотрудник почти наверняка органично впишется в коллектив таких же программистов, и будет двигаться в общем векторе развития компании.
Несколько постулатов философии ректального программирования
Главное, чтобы работало
Задача даётся для того, чтобы её выполнили. Если задача выполнена, значит цель достигнута. Не нужно думать о призрачных перспективах, возможностях развития, доработках или переработках. Мы живём в очень нестабильном мире, а жизнь коротка. Незачем думать об оптимизации, производительности, рефакторинге, стиле, стандартах - вдруг завтра ядерная война?
Код - это искусство
Шедевр не может быть простым, доступным каждому. Если бы Толстой втиснул Войну и мир в брошюру между статьями о садоводстве и скандвордами, а Шопен играл бы на ложках - кто сейчас знал бы этих гениев и их шедевры? Шедевральность шедевра в его сложности. Поэтому, если хочешь достичь совершенства в программировании - уходи от простого к сложному. Все эти комментарии, понятные имена переменных и прочий сахар - удел плебеев и гуманитариев. "Если ты не можешь разобраться в несчастной паре тысяч строк моего кода - зачем ты вообще пришёл в программирование?" Программирование - это джунгли, слабых здесь затаптывают.
Всё новое - хорошо забытое старое
Если не забывать старое - не будет потребности в новом. Учить новым трюкам надо собаку, а не взрослого состоявшегося программиста, который всё уже знает. Всё, что было в 8.0, отлично работает и в 8.3, что ещё нужно?
Несколько базовых приёмов ректального программирования
Приведём несколько широко распространённых приёмов ректального программирования, чтобы читатель имел общее представление о практическом применении данной методики.
1. Комментарии в коде
не нужны. Мало кто знает, что слово "комментарий" происходит от слова "закомментировать"! Комментарии придуманы для того, чтобы программист мог закомментировать десяток-другой процедур и функций и продолжать экспериментировать в коде, выражая своё творческое "Я". Но иногда комментирование используют не по назначению - за двумя слэшами пишут какую-то информацию о том, что делает код. Это очень вредная практика. Во-первых, что за странная фантазия - писать комментарии по коду, если ты и так знаешь, что в нём происходит? Во-вторых, что может быть непонятного в модуле с несчастными 15 тысячами строк и тремя сотнями процедур? Или тем более в пакетном запросе из двадцати составляющих? И, в-третьих, кому вообще придёт в голову лезть в твоё бессмертное творение, созданное на века?
2. Через точку
Всем известно, что данные в 1С можно получать через точку. Например:
РеализацияТоваровУслуг.Заказ.Контрагент.Партнер.КонтактноеЛицо.ТелефонКогда-то кто-то запустил слух, что, якобы, это плохо, мол, из базы тянется куча ненужных объектов, не учитываются права и прочий бред. Но подумайте сами, для чего тогда Господь создал 1С с возможностью получать данные через точку? Любому умному человеку очевидно, что это бессмысленно! Бесспорным фактом является то, что раз 1С создана с такими возможностями, значит их и нужно использовать, а не слушать еретиков. Более того, как вы себе представляете другие способы получения информации? Программист что, ещё и запрос должен писать для этого?? Конечно же нет! Шах и мат, атеисты!
3. Копирование кода
Одно из важнейших умений программиста - пользоваться уже написанным кодом для создания нового. Если уже есть какой-то код, который выполняет нужное действие - зачем изобретать велосипед и писать его ещё раз, если его можно просто скопировать? Более того, его можно копировать ещё и ещё, столько раз, сколько нужно! Это в разы сокращает трудозатраты, ведь не нужно искать закономерности, придумывать новые функции, пытаться абстрагировать какие-то части. Исключив таким образом огромное количество бессмысленных действий, мы получаем повышение производительности труда программиста в разы, даже в десятки раз! Копирование кода - одно из важнеших умений в ректальном программировании!
4. Форматирование
не нужно. Форматирование кода, как и многие другие ненужные украшательства, призвано ограничить волю самовыражения программиста, отучает мыслить нестандартно, загоняет в рамки, обезличивает работу программиста-творца. Зачастую, среди серости и монотонности "стандартного" программирования очень сложно показать свою избранность, не говоря уже о том, что часто потомки просто не смогут идентифицировать авторство такого кода. Как же обидно будет, создав памятник ректального програмирования, использовать стандартное форматирование, заставив таким образом нобелевский комитет будущего (когда будет учреждена премия в сфере 1С-программирования) сомневаться в авторстве! Не правда ли, ужастная участь? Именно поэтому не нужно стесняться писать такой код:
процедура создатьдокумент(отказ,сс,массив,тч,сообщпользчтнельзсозддок=ложь)
если отказ=истина тогда отказ=ложь; возврат; конецесли;
если типзнч(сс)=тип("документссылка.заказклиенту")тогдаДа и в конце концов, имеет человек право иметь неработающие Enter, Shift и Tab на клавиатуре или нет??
5. Общие модули
Очень часто можно увидеть, как неопытные, некомпетентные, слабые духом программисты создают целую кучу общих модулей, умудряясь даже делать модули почти для одинаковых целей, но с разными контекстами и возможностями - клиентные, серверные, клиентсерверные, повторные, с вызовом сервера и т.п. Между тем большое количество модулей говорит о душевных метаниях, неуверенности в себе и отсутствия понимания вообще, как устроена работа платформы. А ведь всё очень просто:
сервер не может работать с клиентом, а клиент с сервером - может, если у модуля стоит флажок "Вызов сервера"!
Думаю, специалисты ректального программирования уже поняли, каким должно быть решение. Для остальных же вот правильный ответ: можно просто создать один общий модуль, назвать его ОбщийМодуль1, поставить у него флажки "Сервер" и "Вызов сервера" - и всё!
6. God object
Так в загнивающей капиталистической литературе называют объект в системе, который хранит все данные и/или весь функционал. Не правда ли - гениальная в своей простоте идея? Ведь действительно, как удобно иметь в системе объект, где хранится всё! Представьте, как упрощается разработка! Все запросы в системе пишутся по одному объекту, а программист больше никогда не задаётся вопросом - а откуда брать данные? Вот они, все здесь. Таким объектом может быть, например, регистр сведений (обязательно периодический), или ещё лучше регистр накопления. А все реквизиты всех хозяйственных операций в деятельности можно сделать как измерения такого регистра. В дальнейшем, при последующей разработке, можно просто добавлять измерения. Пользоваться таким регистром очень просто - заполняются только нужные реквизиты, а остальные остаются пустыми. Вот и всё! Мы добавили один объект, создали в нём 2-3 сотни измерений для всех случаев жизни, а насколько просто стало работать с базой! Только теперь становится ясен истинный смысл выражения "целостность данных". Если же поместить вообще всю деятельность в один объект не получается, можно хотя бы стремиться к этому, создать два-три объекта. Например, один справочник, один объект и один регистр, который двигается этим документом.
7. Попытки
Иногда в работе кода могут происходить ошибки, к сожалению, это неизбежно. Но цель программирования - выполнение задачи без ошибок. Как же быть? А что, если я скажу вам, что ваш код может работать всегда! Вообще всегда!! Без ошибок!!! Магия? Шарлатанство? Нелегальные способы? Нет, нет и нет! Всего лишь "Попытка"! Да, это такая конструкция, которая позволяет как бы попробовать выполнить кусочек кода, а если случилась какая-то ошибка, то можно просто аккуратненько её обойти. А если заключить весь код в попытку, а в исключении ничего не писать, то ваш код всегда будет работать без ошибок. Представьте - так просто и всё всегда работает, пользователь никогда не получит какую-нибудь страшную ошибку в работе. Всё что нужно - это писать все функции-процедуры вот так:
Процедура ВыполнитьОбмен() Экспорт
Попытка
// сюда помещаете всё тело процедуры
...
Исключение
// здесь ни в коем случае ничего не писать, иначе можно напугать пользователя!!!
КонецПопытки;
КонецПроцедурыВот и всё. И забудьте об ошибках. Кстати, это чудо возможно только в ректальном программировании, никакая другая методика не даёт таких впечатляющих результатов, поэтому она и ценится как среди программистов, так и среди их работодателей.
8. Загрузить-выгрузить
В 1С есть множество волшебных методов, которые магически выполняют свою работу без нагрузки на железо и при этом очень упрощают работу программиста. Например, методы "Выгрузить" у результата запроса и "Загрузить" у таблицы.
Представим, что у вас есть запрос, который получает миллиард строк из вашего богобъекта из п.6 и вам нужно их поместить в ТЧ объекта. Слабые духом скорее всего сделают выборку и будут построчно загонять в ТЧ. Но для чего, если можно просто написать:
ТЧ.Загрузить(Запрос.Выполнить().Выгрузить());И всё сделается само за одно действие! Никаких циклов, никаких обходов, никакой вообще нагрузки на аппаратную часть. Строки просто волшебным способом оказываются внутри ТЧ.
И таких волшебных методов в 1С много. Ещё один пример: <...>.Найти(). Очень удобно использовать в цикле вместо, например, получения данных в запросе, ведь запросы писать сложно.
9. Юзерфрендли
Пользователь - существо само по себе безвольное и находится на гораздо более низкой ступени развития, чем программист. Поэтому делать интерфейсы, ориентируясь на пользователя, дело неблагодарное, бессмысленное и даже опасное. Вместо этого программист, как создание гораздо более умное и просветлённое, должен помогать пользователю, придумывая за него, как ему удобнее и что ему вообще нужно. А также развивать у пользователя нестандартное мышление и мелкую моторику, создавая интерфейсы с секретами, тайнами и загадками. В дальнейшем пользователь только спасибо скажет за такую помощь.
Ведь кто ещё смог бы научить его определять по звуку вентилятора охлаждения процессора, что операция, которая висела в 1С 40 минут, уже завершилась? Страшны ли пользователю какие-то излучения, если он годами смотрел на форму цвета фуксии с зелёно-красными кнопками? Убьёт ли такой человек в порыве гнева свою жену, если он каждый день заполнял форму с сотней полей, в которой если перевыбрать одно значение, форма сбрасывается в ноль, но при этом выжил и сохранил рассудок? Болью и страданиями от использования доработанных ректальным способом интерфейсов выложена пользователю дорога в нирвану.
10. Кэш
не нужен. Ещё один из небольших трюков увеличения производительности труда программиста - не обращать внимание на мелочи, следуя широкими шагами к завершению задачи. Например, как вы думаете, что можно улучшить в коде:
Если ЭтаФорма["ДеревоМетаданных"].НайтиПоИдентификатору(ТекСтрока).ПредставлениеОбъекта = "Справочники"
ИЛИ ЭтаФорма["ДеревоМетаданных"].НайтиПоИдентификатору(ТекСтрока).ПредставлениеОбъекта = "Документы"
ИЛИ ЭтаФорма["ДеревоМетаданных"].НайтиПоИдентификатору(ТекСтрока).ПредставлениеОбъекта = "Планы видов характеристик"
ИЛИ ЭтаФорма["ДеревоМетаданных"].НайтиПоИдентификатору(ТекСтрока).ПредставлениеОбъекта = "Планы счетов"
ИЛИ ЭтаФорма["ДеревоМетаданных"].НайтиПоИдентификатору(ТекСтрока).ПредставлениеОбъекта = "Задачи"
ИЛИ ЭтаФорма["ДеревоМетаданных"].НайтиПоИдентификатору(ТекСтрока).ПредставлениеОбъекта = "Бизнес-процессы"
ИЛИ ЭтаФорма["ДеревоМетаданных"].НайтиПоИдентификатору(ТекСтрока).ПредставлениеОбъекта = "Планы обмена"
Тогда
ПлчЭлмнт = ЭтаФорма["ДеревоМетаданных"].НайтиПоИдентификатору(ТекСтрока).ПолучитьЭлементы();
КонецЕсли;или
Для Каждого а ИЗ МассивНаСтоТысячСтрок Цикл
а.Контрагент = Справочники.Контрагенты.НайтиПоНаименованию(
СтрЗаменить(Справочники.Организации.НайтиПоНаименованию("ООО Лютик").Наименование, "ООО", ""));
КонецЦикла;Правильно - ничего! Код лаконичен, не засоряет память ненужными переменными и работает, а больше ничего и не нужно для выполнения задачи.
11. Хардкодинг
Ещё одно иностранное слово, которое означает, что внутри кода зашиты какие-то значения. Например:
Если Имя = "Вася" Тогда
Сообщить(Имя);
КонецЕсли;Здесь хардкодинг - это "Вася". Непонятно, зачем они там заграницей придумали для этого отдельное слово, ведь если тебе нужно проверить "Васю", то как ещё это можно сделать?
Заключение
Итак, это было краткое введение в основы ректального программирования. Надеюсь, данный материал поможет программистам, особенно начинающим, влиться в ряды, начать успешную карьеру и стать своими в среде программистов 1С.
Комментарии (130)
odinesnik
13.12.2021 18:04+15Заодно, возможно, пойму, имеет ли смысл писать на Хабр более менее развернутую аргументированную статью на тему, за что я люблю 1С
monane
13.12.2021 18:22+3Извините, не могу претендовать за всех, но я бы почитал, тема то живая и 1с програмистов много, значит будет отклик.
odinesnik
13.12.2021 18:34+2Пока я настроен написать, главное, чтобы еще хватило времени
vkni
14.12.2021 06:25+3Реально занятно - действительно другой мир. В "обычном" программировании доступ к полям структур, включая вложенные, делается обычно через точку. При этом всё вот это находится в памяти, причём если это какой-нибудь C, то там
РеализацияТоваровУслуг.Заказ.Контрагент.Партнер.КонтактноеЛицо.Телефон
заменяется компилятором на доступ по указателю со смещением (какое-то число, определяемое на этапе компиляции). Вне зависимости от вложенности.
Поэтому напишите, пожалуйста.
prohodil_mimo Автор
14.12.2021 09:17+7Такое в 1С тоже есть - например, можно через точку обратиться к полю коллекции.
Но также 1С придумала такой способ обращения через точку, чтобы заменять вложенные запросы.
Например, в БД есть таблица А. В ней есть колонка "Подчинённый", там хранится ссылка на строку таблицы Б. Чтобы получить какое-то поле из таблицы А и сразу поле из таблицы Б по ссылке из "Подчинённый", в любом другом языке программирования нужно было бы написать запрос, где выбираем из таблицы А, связываем с таблицей Б. В 1С же можно просто обратиться прямо из кода без запроса:
А.Подчинённый
И получим значение из таблицы Б.
Т.е. форма синтаксического сахара.
Но проблема в том, что под капотом это даёт кучу проблем (которые хорошо описали здесь в комментариях). А ректальные программисты видят только простоту использования такой конструкции, не желая знать о побочных эффектах.
CrushBy
14.12.2021 10:07Уже была такая статья, и судя по плюсам многим понравилась. Но не хватает более технической статьи (вроде вот этой, которая с критикой). Такую же, но уже описывающую положительные моменты, было бы интересно почитать.
prohodil_mimo Автор
14.12.2021 10:48+2Там немного не такая статья. Эта статья - сарказм по поводу Г-кода в 1С. Там же - пояснение труЪ-программистам, что такое 1С.
mSnus
13.12.2021 18:07+2О, а что там не так с "через точку"? Что значит "не учитываются права" - а они там в какой должны момент учитываться, когда запрос пишешь? С 1С уже лет 20 не работаю, просто любопытно)
odinesnik
13.12.2021 18:33+2Через точку не так то, что так можно делать только в запросе, потому что в этом случае sql выбирает ровно то, что ты просишь, потому что ты сам в явном виде указал системе, что тебе нужно.
То есть в примере из статьи "РеализацияТоваровУслуг.Заказ.Контрагент.Партнер.КонтактноеЛицо.Телефон" построится план запроса, в котором в результате выбирается только телефон.
Если же выбирать через точку из объекта или ссылки на реализацию, то в итоге логика системы будет другой.
Поскольку система не знает, не начнешь ли ты сейчас в следующем коде кроме телефона выбирать еще десяток полей из того же контактного лица, то она на всякий случай при первом обращении к какому-либо полю объекта получает объект целиком.
В результате будут получены полностью заказ, контрагент, партнер и т. д.Особенно феерично получается, если в каком-нибудь объекте полсотни плюс реквизитов, может быть всякие двоичные данные и пр.
Ну то есть, несмотря на соблазн обращаться к реквизитам объектов через точку без запроса, делать так нельзя, нужно получать через запрос.
В той же БСП (библиотека стандартных подсистем) для этого есть специальная функция, упрощающая это действие.
Naf2000
13.12.2021 19:18+2Нет не так. Не получает объект целиком. А в терминах 1с вообще объект не получает, А только ссылку. Проблема в том, что каждая точка это отдельный запрос, вместо того, чтобы выполнить один.
И ещё если ссылка пустая, то такой код:
А = МояСсылка.Наименование;
Присвоит А пустую строку, а запросом получим пустую выборку.
odinesnik
13.12.2021 20:02+2Про реквизит через несколько точек не уверен до конца, что будут получены все промежуточные объекты целиком.
Про одну точку точно так.По поводу каждая точка — это отдельный запрос наверное да, так и есть.
По поводу наименования пустой ссылки да, это нужно обрабатывать кодом.
RhelasTgav
14.12.2021 09:07+2Может быть получен объект целиком. Зафиксированы случаи. См. "1С: Настольная книга эксперта"
odinesnik
13.12.2021 18:41По поводу не учета прав ситуация такая.
Если обращаться через точку к объекту, то можно получить нарушение прав, да.
Это еще одна причина, почему нужно использовать запрос.Если же использовать запрос, то в нем нужно писать ключевое слово "разрешенные", в этом случае будет учитываться RLS (Record Level Security) и ошибки не будет.
Ошибка будет только если нет прав на таблицу целиком.
Правда и данные могут не получиться, если нет прав, ну так а как иначе, это нужно обрабатывать в логике.
Mustard
14.12.2021 10:49+1Каждая точка это левое соединение объекта с таблицей реквизита. Представьте, что бывает в цикле даже с десятком тысяч строк.
Хотя 1С все это дело конечно пытается кэшировать, а разработчики платформы 1С регулярно такие вещи оптимизируют…LARII
16.12.2021 01:08Дополню, что каждый объект между точками может быть составным типом. И тогда ещё больше джойнов...
FLU911
13.12.2021 18:08Прикрутите опрос, кто сколько пунктов набрал за последний месяц. У меня всего один, но это не потому что я не сторонник данной парадигмы.
ProstakovAlexey
13.12.2021 18:11+22Пишу на java, на 1С не писал, 1С программистов в деле видел. Уверен, что если среднему джависту выдать такой объем бизнес логики, которую без аналитика перерабатывают 1C программисты, но джавист напишет какой-нибудь groovy enginer класс, и передаст писать groovy скрипты кому-нибудь, а сам с этого проекта тихонечно в сторонку, в сторонку....
vis_inet
14.12.2021 09:03+12Поддерживаю!
Приятно узнать, что хоть кто-то не относится к 1С с усмешкой.
speakingfish
14.12.2021 11:45-5Внутри 1С и так Java. Просто со своими библиотеками и сгенерированными классами, как и в любом другом CRM на Java.
Ta_Da
14.12.2021 11:54+10Все верно, только 1С это не "любой CRM на Java". Во-первых потому, что не совсем CRM, во-вторых, потому что не на Java.
VVizard
14.12.2021 20:07+5Это не 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С обычно разговор заканчивается, потому что говорить тут просто не о чем.
Neikist
15.12.2021 00:01Примерно такое же мнение после ухода из сферы 1с спустя 4.5 года работы с этой платформой (свою коробку пилили и на проектах допиливали).
plus
13.12.2021 18:21+14Если бы это только к 1С относилось :)
Alexey2005
14.12.2021 11:36+8В мире Machine Learning эту парадигму программирования довели до совершенства. Открываем любой проект — и там под капотом полная жесть.
Если взять например проект ruDALL-E, про который недавно писали на хабре, то уже на этапе загрузки можно увидеть, что оно поднимает сразу два дублирующих друг друга фреймворка — pytorch и tensorflow. Это хорошо ещё разработчики про JAX не знают, а то бы они и его туда добавили для комплекта. А первый же пулл-реквест, который они получили после выкладывания проекта на GitHub, ускорил генерацию изображений в 10 раз.
В общем, это типичный академический код, по сути сырой прототип. Проблема лишь в том, что в мире ML сделать из такого прототипа нормальный продукт практически невозможно — обучение таких громадных нейронок очень дорого. Поэтому у разработчиков сервисов на основе нейронок нет другого выхода, кроме как брать всю эту конструкцию из говна и палок как она есть, целиком, и как-то встраивать в собственный код, который после этого уже не может быть настолько хорош, как хотелось бы.
Naf2000
13.12.2021 19:06В копилку:
Передача параметров в методы через запись/чтение базы данных
https://geniy1s.ru/nekanonicheskij-sposob-spuskaniya-parametra-nizhestoyashhim-proczeduram/
oq0po
13.12.2021 21:35+2путь состоявшегося программиста, уверенного в своём абсолютном превосходстве и компетенции.
О да, знаю одного такого, имевшего полный доступ к сырцам и внезапно для всех участников проекта поменявшего все иконки GUI в релизе для продакшена просто из собственной прихоти. Да! Так оно туда и ушло. Стоп! Он - неприкасаемый. Ибо. Остальные - черви.
ya_penek
14.12.2021 16:29+2А еще перед увольнением можно написать на иконке тоненьким гостовским шрифтом трехбуквенное ругательное слово. В ИТ отделе этого никто не заметил, потому что все запускают экзешник из фара или тотал коммандера. А у всего начальства на рабочий стол вынесен крупный ярлык. Было весело...
Gachevskii
14.12.2021 09:08+2Ректальное программирование
1с
Возможно я слишком испорчен или это опыт от взаимодействия с 1с, но кроме улыбки ничего не вызвало)
С уважением)
JavaED
14.12.2021 09:08+4Как одинэсник с 2003 года, люто плюсую, всё так и есть ;))))
zuek
14.12.2021 17:03Ой, я в 1С залезаю (как и в любой другой эксплуатируемый код) очень редко и неохотно, но вот такое в 1С встречаю с завидной регулярностью:
ЭтоСклад = (Найти(НРег(Организация.Наименование), "складо") > 0); ЭтоТрансп = (Найти(НРег(Организация.Наименование), "транс") > 0); ЭтоПРР = СокрЛП(Организация.ИНН) = "3211135524"; Если ЭтоСклад Тогда ПеременнаяДлинаНомера = 3; Префикс = "С"; ИначеЕсли ЭтоТрансп Тогда ПеременнаяДлинаНомера = 3; Префикс = "Т"; ИначеЕсли ЭтоПРР Тогда ПеременнаяДлинаНомера = 3; Префикс = "П"; Иначе ПеременнаяДлинаНомера = 4; Префикс = ""; КонецЕсли;Вот за что мне такое в эксплуатации? И это ещё не самое страшное место.
Да даже в скриптиках, призванных раз в день проверять корректность выгруженных на внешнюю площадку бэкапов, таких волосодыбательных мест не встречал...
VVizard
14.12.2021 20:10Такое есть везде. Проблема говнокода в 1С встречается чаще из за более низкого порога и сжатых сроков т.к. 80% разработки 1С это разработка по часам. Это примерно как ожидать от продажной женщины за 1500р в час такого же отношения и внимания как от жены.
Но на самом деле проблема такого говнокода это все же проблема того кто пишет и команды (правда в 1С опять же 70% работает без команды). Но никак не платформы и не языка.
CoderSoft
14.12.2021 09:08+6Вначале было смешно, потом грустно потому что вспомнилось то же самое на тех проектах, где работаю сейчас и в прошлом и это не 1С
darkmon
14.12.2021 09:14+2Всё так. Только непонятно, зачем в эти Bad practices затесался прием №8? Конструкция прекрасно работает, сам пользуюсь и всем советую. А если запрос вернул вам миллиард строк, то это проблема запроса, а не загрузить-выгрузить. Как будто построчное заполнение тут может спасти)
Naf2000
14.12.2021 09:46+1И я тоже так делаю. В смысле кода это наиболее лаконичное решение.
Проблема в архитектуре самих классов: для того чтобы "вылить" данные из результата запроса в табличную часть, Вы должны использовать промежуточный контейнер - таблицу значений, хотя в принципе он не нужен. Либо вы "руками пишите" цикл обходы выборки запроса и заполняете построчно табличную часть.
SaintMortum
14.12.2021 09:54+1Даже если будет миллиард строк, то больше времени потратится в другом месте, а не в загрузить-выгрузить. Например, при выполнении запроса или записи объекта. Просто кто-то занимается ерундой и оптимизирует что-то локально вместо оптимизации системы в целом.
SaintMortum
14.12.2021 10:02Комментарии в коде и правда не нужны. Это признак непонятно написанного кода или обычно пишут очевидные вещи.
ruimage
14.12.2021 10:49+1Тут еще друга беда есть. Исторически в 1С контроль версий реализован в виде системы "хранилища". И беда хранилища в первую очередь не в том, что там нет возможности ветвления, а в том, что нельзя быстро поднять историю а-ля blame или log в гите.
В итоге все доработки окружаются комментариями с указанием даты, ответственного за изменения, описания задачи по которой было сделано изменения.
Страшный рак в итоге получается и при этом никаким другим образом не передать информацию зачем и когда что-то меняли.
Сейчас у 1С есть плановая программа по переходу в GIT с EDT, вот только переход на новые рельсы очень уж тяжел после N лет работы в "Конфигураторе"
Roland21
14.12.2021 11:04этой плановой программе уже лет 5
и учитывая что ЕДТ не поддерживает (и не будет) старый функционал типа "толстого" клиента - программе по переходу еще много лет впереди
ну и интерфейс ЕДТ это конечно огонь, когда даже по видео-инструкции хрен разберешь что и как должно работать. Привет 1С
SaintMortum
14.12.2021 12:26-1Даже такие "комментарии" с авторством уже много лет как неактуальны, ибо есть gitsync.
prohodil_mimo Автор
14.12.2021 12:33+1Как гитсинк может помочь в сравнении-объединении конфигурации? Однажды пришлось сравнивать-объединять конфу, где куча доработок с одной стороны (эталон), куча доработок с другой стороны (надо накатить), при этом вторая ещё и более новая по обновлениям. Хотел бы пожелать делать эту работу в аду хотя бы лет тысячу всем, кто не ставит комменты авторства доработок.
SaintMortum
14.12.2021 12:38А как комментарии помогут в этом? Всё равно нужно вникать в код. И делать это намного проще без мусорных комментов. При желании можно и нужно смотреть в историю в гите, там больше информации чем в комментах. Странно из-за "однажды" продолжать работать по-старинке.
prohodil_mimo Автор
14.12.2021 13:51+3Не обижайтесь, но у меня впечатление, что вы чисто теоретизируете, без практического реального применения теории. Вы правда не понимаете, что, имея сотню конфликтов (возьмём такое скромненькое сравнение-объединение, даже без десятков тысяч конфликтов), можно по комментам исполнителя пройтись и проставить флажки за час, а можно на каждый конфликт ходить и смотреть историю гита и потратить неделю? А ведь бывают и совсем интересные случаи, когда один кусок менялся несколько раз, а в источнике - какая-то версия из середины. Или когда кусок кода удалили по ошибке. Или когда кусок кода удалили не по ошибке. И в любом из этих случаев надо понять, что произошло. И можно это понять вот прямо здесь и сейчас, по комменту, а можно ходить по историям.
Наверное, в какой-то волшебной стране, где добрые мудрые программисты под управлением доброго мудрого РП начинали проект на гитах и вели его по конвенциям, и возможны какие-то свершения (хотя я до сих пор не видел ничего удобнее для решений конфликтов в коде 1С, чем сравнялка-объединялка от 1С), но в реальной жизни ваш проект может начаться, например, с того, что вам просто не дадут поставить гит (тру стори).
SaintMortum
14.12.2021 14:47-2Смотря что считать конфликтом. Для меня это когда оно автоматически не мерджится. Таких случаев бывает очень мало, уж никак не "сотни". Тут ни истории, ни комментов как правило не нужно. Когда же возникает реальный конфликт объединения, то без истории никак не разобраться. В ситуации когда на просмотр истории гита тратится неделя (в разбирательствах что почему и как) флажки за час можно проставить разве что от балды.
P.S: стандартная "сравнялка-объединялка" вещь весьма убогая, не зря добавили поддержку внешних программ типа kdiff3.
yukon39
14.12.2021 13:33Git тоже неплохо умеет в трёхстороннее сравнение.
prohodil_mimo Автор
14.12.2021 13:43Во-первых, сравнение-объединение имеет несколько хороших специфических инструментов. Всё-таки очень удобно, когда методы показаны и сопоставлены как методы и можно поставить флажок сразу на метод, а не на каждый конфликт внутри него. Про формы и макеты я вообще не говорю - простой реквизит или обработчик события может выйти в десятки строк XML. Теоретически, конечно, всё возможно, но попробуйте практически как-нибудь сравнить-объединить две конфы с конфликтами.
Во-вторых, гит ещё нужно поставить. Мне удавалось добиться разворачивания гита в одном из пяти проектов. В остальных никакие аргументы не действовали - вот вам конфигуратор, вперёд и с песней, какие ещё гиты?
yukon39
14.12.2021 14:03Вполне ожидаемо, что специализированная IDE Конфигуратор или EDT предоставляют более удобные инструменты для определенных сценариев.
Однако доже без них git вполне может справиться с этой задачей самостоятельно.
А вот, то что git для кучи не только 1С-ников, но и зачастую для их руководителей ругательное слово это, конечно, печально.prohodil_mimo Автор
14.12.2021 14:10+1Тут важно не путать инструменты и цели. Очень часто бывают проекты, где набрать побольше "супер-модных" инструментов с "крутыми" английскими названиями и сделать максимально не как у всех - становится целью проекта.
Поэтому использовать гит ради использования гита ещё более тупо, чем не использовать его там, где он реально может пригодиться.
Если сравнить-объединить проще всего через конфигуратор, не понимаю, зачем бы я использовал гит и окологитовые инструменты для этого.
Сам я использую гит там, где надо постоянно лезть в историю, где много веток с одновременной разработкой. В этих вопросах гит в разы удобнее 1Сных инструментов (у меня как-то история по объекту формировалась час, а создать версию конфы из истории заняло день!). Но сравнивать-объединять я предпочитаю через 1С.
elFurion
15.12.2021 09:11+1Eclipse, на базе которого делается EDT, почти канул в небытие за это долгое время. :(
Сейчас лучше IDE делают на базе открытой платформы idea https://www.jetbrains.com/ru-ru/opensource/idea/ . Я получаю очень много позитивных эмоций от работы в IDE PyCharm от jetbrains после многих лет работы в конфигураторе. Интуитивный, быстрый, всегда подсвечивает где у тебя какие ошибки (или проблемные места) в коде, удобные горячие клавиши, позволяет использовать много крутых фич git`а без консоли и т.д.
shashurup
14.12.2021 12:27+5Комментарий в коде должен говорить не о том, что этот код делает, а о том ЗАЧЕМ этот код это делает.
VVizard
14.12.2021 20:14Они не нужны там где ты можешь выделить отдельные классы с методами, разместить их в соответствующих каталогах и.т.п. В 1С когда у тебя в одном модуле размещены 95 процедур и 129 функций при этом все они так или иначе вызывают процедуры и функции из других модулей с таким же названием но с другой инструкцией (ПовтИсп, ВызовСервера и.т.п.) комментарии с описанием что это, какие у него параметры жизненно необходимы.
SaintMortum
14.12.2021 10:09+10.Комментарии в хранилище
не нужны. Ибо кому придёт в голову копаться в прошлом? Живи сегодняшним коммитом!
dima_home
14.12.2021 10:37+1"РеализацияТоваровУслуг.Заказ.Контрагент.Партнер.КонтактноеЛицо.Телефон" в запросе.
Комментарий 1С:
Если в запросе используется получение значения через точку от поля составного ссылочного типа, то при выполнении этого запроса будет выполняться соединение со всеми таблицами объектов, входящими в этот составной тип. В результате SQL текст запроса чрезвычайно усложняется, и при его выполнении оптимизатор СУБД может выбрать неоптимальный план. Это может привести к серьезным проблемам производительности.
Мой комментарий:
Каждый программист, при написании кода, стоит перед выбором: повысить производительность или читаемость кода. Каждый случай индивидуален.prohodil_mimo Автор
14.12.2021 10:53+2Тут два момента.
Производительность - это цель, а читаемость - это средство. Не совсем корректно их сравнивать. При этом сразу обращу внимание, что я считаю читаемость очень важным параметром кода. Но не единственным и далеко не всегда главным.
Написание запроса для выбора подподподвложенного поля совсем не означает, что код сразу становится совершенно нечитаемым.
VVizard
14.12.2021 20:19+1На самом деле то что 1С позволяет такое писать не проблема 1С, любая ORM с ленивым чтением будет делать то же самое.
Писать так или нет тоже зависит от задачи, ну и для справедливости прям так никто не пишет, это большая редкость. Чаще просто получают через 1-2 точки и это нормально если ты дальше что то делаешь с этим объектом и если у тебя не HiLoad блок а что то что выполняется раз в месяц.
И чаще всего в разыменовываемых объектах не лежат огромные хранилища значений.
При этом СУБД нет особой разницы прочитать один реквизит или прочитать всю строку. Поэтому я бы не стал в большинстве случаев на это обращать внимание.
Нужно просто понимать что ты и для чего делаешь.
Arimefu
14.12.2021 11:23+2Прежде всего через точку не рекомендуется получать через точку именно от полей составных типов, которые могут ссылаться на разные таблицы справочника. Если же поля однозначного типа, то в этом нет ничего плохого, на уровне SQL результирующий запрос будет абсолютно таким же.
При получении через точку в коде, а не в запросе, да, есть много нюансов: 1С будет загружать в себя все промежуточные объекты, а если встретится какой-нибудь документ с большой табличной частью, то это явно скажется на производительности. В общих модулях для этого даже есть функция получения реквизита (или нескольких реквизитов), которая как раз строит запрос на основании метаданных только к нужному реквизиту. И это намного быстрее, чем получать объект, хотя и кажется, что кода написано немало.
В случае же необходимости получения через «несколько точек» от полей составных типов, кроме как написания запроса, причем с явным указанием типов промежуточных полей (т.е. через ВЫРАЗИТЬ...), не получится сделать оптимального кода.
Но по большому счету, достаточно просто однажды понять структуру того, как устроено все в базе, и вопросов по этим пунктам больше не возникает.
beerchaser
14.12.2021 18:00Лично мне больше доставляют не запросы на чтение - эти куски могут быть отпрофилированы и переписаны в соответствии с хБуками, а способ организации апдейта объектов. Когда, например, нужна групповое изменение атрибута справочника. С одной стороны понятно, что механизм платформы обеспечивает целостность объектов, но когда понимаешь, сколько под ним лежит ерзанья по таблицам...
OlegZH
14.12.2021 11:25Простите, а Вы не можете развернуть свой пример подробнее? В скольких случаях Вы используете в запросе своё многоточие? В каком контексте? И какую задачу, вообще, решаете?
dima_home
14.12.2021 13:12Если у вас есть доступ к ИТС, то тут много примеров:
https://its.1c.ru/db/metod8dev/content/2662/hdoc
dima_home
14.12.2021 13:46Пример поиска ошибок в заполнении ставки НДС для не резидентов.
ВЫБРАТЬ РеализацияТоваровУслугТовары.Ссылка КАК ДокументПродажи, РеализацияТоваровУслугТовары.Номенклатура, РеализацияТоваровУслугТовары.СтавкаНДС, РеализацияТоваровУслугТовары.НомерСтроки ИЗ Документ.РеализацияТоваровУслуг.Товары КАК РеализацияТоваровУслугТовары ГДЕ НЕ РеализацияТоваровУслугТовары.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС0) И РеализацияТоваровУслугТовары.Ссылка.Контрагент.НеЯвляетсяРезидентомyukon39
14.12.2021 14:11-1Ну тут да, гораздо эффективнее будет набор внутренних соединений вместо набора левых, которые подставит платформа при разименовании:
ВЫБРАТЬ РеализацияТоваровУслугТовары.Ссылка КАК ДокументПродажи, РеализацияТоваровУслугТовары.Номенклатура, РеализацияТоваровУслугТовары.СтавкаНДС, РеализацияТоваровУслугТовары.НомерСтроки ИЗ Документ.РеализацияТоваровУслуг КАК РеализацияТоваровУслуг ВНУТРЕННЕЕ СОЕДИНЕНИЕ Справочник.Контрагенты КАК Контрагенты ПО РеализацияТоваровУслуг.Контрагент = Контрагенты.Ссылка И Контрагенты.НеЯвляетсяРезидентом ВНУТРЕННЕЕ СОЕДИНЕНИЕ Документ.РеализацияТоваровУслуг.Товары КАК РеализацияТоваровУслугТовары ПО РеализацияТоваровУслуг.Ссылка= РеализацияТоваровУслугТовары.Ссылка ГДЕ НЕ РеализацияТоваровУслугТовары.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС0)
Совсем было бы хорошо, предвыбрать все ставки НДС и добавить вместо отрицательного условия еще одно внутреннее соединение.Arimefu
14.12.2021 14:27Проверил оба варианта запроса — нет, не могу сказать, что есть какая-то разница. На базе с несколькими десятками миллионов записей в табличной части Товары оба запроса выполняются одинаковое время. До уровня запроса, который получается на SQL, конечно, не опускался, но разницы даже по смыслу и не должно было быть: оба запроса оперируют одинаковыми таблицами с одинаковыми отборами в общем-то, все соединения по сути на одном уровне. Не исключаю, может на каких-то уже неактуальных версиях платформы поведение может быть другим.
yukon39
14.12.2021 15:17Не одинаковыми. Платформенное разименование генерит ЛЕВОЕ соединение. А тут нужно явно внутреннее.
Что касается скорости:
1. Есть ли индекс у НеЯвляетсяРезидентом
2. Убрать НЕ в условии СтавкаНДС
Lapland_Man
14.12.2021 20:01Теоретически внутреннее соединение должно быть быстрее, но на практике получается или одинаково (одинаковый план запроса) или левое соединение быстрее
Примеров - полный гугл
Arimefu
15.12.2021 06:59+1Индекса конечно же нет, для чего он в данном случае? Это не тот реквизит, который стоит индексировать у справочника контрагентов.
Убрал НЕ, ничего не изменилось, абсолютно то же самое время выполнения, причем даже откинув статистику SQL (для чистоты в копии базы проверил).
Для чего эта оптимизация ради оптимизации? Ну генерируется левое, а не внутреннее соединение, не вижу ничего плохого. Как уже написали, вполне возможно, что план запроса вообще будет одинаковым.Ta_Da
15.12.2021 07:37+2Для чего эта оптимизация ради оптимизации
Недавно проходил вебинар/мастер-класс по оптимизации запросов для 1С, где конкретная компания рассказывала о своих внутренних стандартах. В частности - про замену "Не..." на внутренние соединения, которая (возможно, но сама компания не проверяла) в определенных условиях, дают прирост, а может быть и не дают, но "так заведено" (что нормально для внутренних стандартов). После чего астрологи объявили неделю карго-культа по оптимизации и переписыванию запросов.
yukon39
15.12.2021 17:06Это наша компания, да. На нашей скромной базе в 7,8 ТБ это работает.
Собственно, замена НЕ на внутренние соединения у нас работает просто отлично.
Не проверяли практически же мы разницу «ЕСТЬ НЕ NULL» vs «НЕ ЕСТЬ NULL».Ta_Da
15.12.2021 17:24-2Это наша компания, да
Значит, я угадал.
На нашей скромной базе в 7,8 ТБ это работает
"У меня такая же нога, но не болит". Это я к тому, что у вас работает - замечательно, но наверное не стоит свои внутренние стандарты продавливать в массы, тем более в обсуждении, которое к оптимизации запроса вообще не имело отношения.
dima_home
15.12.2021 10:27+1А теперь сравните читаемость запросов.
Ответьте себе честно..."сколько секунд вам нужно, что бы понять что делает запрос первый и второй?"yukon39
15.12.2021 17:21Отличие же в том, что второй запрос транслируется в SQL 1-в-1, а первый в SQL можно даже сразу и не узнать, если не знать как именно платформа разворачивает последовательные левые соединения.
Для разбора проблем с этим запросом гораздо предпочтительней именно второй развернутый вид.
F0iL
14.12.2021 11:23+14Пол жизни занимаюсь embedded-разработкой в самых разных ее ипостасях и конторах разного размера.
Так вот, там большая часть всего этого типа "Главное чтоб работало", "Код - это искусство", "Все новое - хорошо забытое старое", подходы работы с "Комментариями", "Копированием кода", "Форматированием", "God object" и "Хардкодом" в точности как описано в статье там не то что общеприняты, а такое ощущение, что являются строго обязательными, и вокруг стоят три кольца оцепления с пулеметами чтобы случайно не пропустить в индустриую того, кто не готов следовать этим годами сложившимся традициям и существует специальный канонический набор отговорок чтобы объяснять необходимость всего этого неофитам. А за произнесение вслух слов "юнит-тесты", "рефакторинг" и "CI-пайплайн" могут набить морду.
Так что я хоть никогда и не был 1С-разработчиком и крайне далек от этого, но нет, не удивили :)
Old_Chroft
14.12.2021 17:12+1Автор статьи внезапно попал из своего уютного мирка "правильной разработки" в мир "кровавого интырпрайза".
вокруг стоят три кольца оцепления с пулеметами чтобы случайно не пропустить в индустриую того, кто не готов следовать этим годами сложившимся традициям
Эта традиция называется "результат должен быть вчера!". И сначала в авральном режиме задача решается "в лоб", а через пару месяцев вспоминается присказка "работает - не трогай!".
Обговнять можно любой инструмент (не только язык программирования. Например молоток: в "кривых" руках бьет не по шляпке гвоздя, а по пальцу. В особо запущенных случаях - еще и по лбу).
Не подумайте, что я ярый поклонник, но 1С прекрасно решает свою прикладную задачу. Менеджеру и бухгалтеру пофигу насколько прекрасен код: его волнует только то, что он написан вовремя, выдает нужный результат и за приемлемый срок. Для остального есть площадки, на которых программисты меряются алгоритмами.
prohodil_mimo Автор
14.12.2021 20:01+1Не переживайте так, не надо. Статья - о ректальных программистах, а не о том, как 1С плохо решает прикладную задачу.
F0iL
14.12.2021 20:08+5Опять же, я далек от 1С, но неоднократно своими глазами видел, к чему приходит такое "результат должен быть вчера" и "работает - не трогай". А приводит оно к нарастанию технического долга до таких огромных масштабов, что внесение даже небольших изменений в проект начинает напоминать оздоровительную пробежку по минному полю, отладка похожа на курс практической проктологии, а количество матерных слов в минуту со стороны разработчиков при поддержке всего этого растет в геометрической прогрессии. И в итоге мы имеем либо низкое качество продукта с вытекающим оттуда недовольством заказчика ("нужный результат" начинает выдаваться далеко не всегда, а как повезет, или "приемлемые сроки" срываются все чаще и чаще), либо вообще большая часть команды программистов увольняется, не желая разгребать эти авгиевы конюшни, да и нанятые на их место подозрительно быстро сбегают или требуют x2 оклад за вредность.
Поэтому в наше время даже на энтерпрайзных галерах такого стараются избегать.
capitannemo
14.12.2021 11:31+7Если рассматривать эту статью как предновогоднее/пятничное чтиво то ловите в копилку
Мы обращались в фирму 1С с предложением ввести в язык (речь идет о версии 6.0) следующие конструкции : ПОЧЕМУ БЫ И НЕ — проверяет условие еще раз (самый частый глюк старой 1С) НЕПРЕМЕННО — выполняет оператор без сбоев и зависаний ОТНЫНЕ — присваивает значение переменной так, чтобы оно там действительно оказалось. (присвоить переменной вида, к примеру, «Справочник» значение в языке 1С — порой очень непростая задача, иногда требующая конструкции аж из 4-х операций) ВО ЧТО БЫ ТО НИ СТАЛО — выводит текст отчета который без этого оператора выводится через раз. НЕ СПАТЬ — отключает внутренний глюкогенератор Я СКАЗАЛ — выполняет команду до тех пор, пока она не выполнится. ИМЕТЬ СОВЕСТЬ — приостановить выполнение команды при её зависании.
- Предлагаю в 1С внедрить новую директиву: &НаКлиентеНоЕслиЧоТоИНаСервере
- лучше сразу: &ИменемБорисаНуралиеваВыполнисьГдеБыНиБылПочему-то фирма не прислушалась к нашему мнению..
А если серьезно, то язык и вся инфосистема развивается в достаточно правильном направлении, не надо впадать в отчаяние
1С это в любом случае быстрое программирование, потому что там результат нужен вчера
Так же как и в быстрых шахматах приходится жертвовать красотой ради результата но не всегдаГлавное - это понимать, что и зачем пишешь конкретно ты. Это уже половина дела.
SilverHorse
14.12.2021 21:49+2Ну нельзя же так, я своим истерическим ржачем всех перебудил в час ночи...
Grigorenkovic
14.12.2021 12:13"Наличие знаний не гарантирует адекватного их применения" - вот что хочется сказать за и против использования указанных шаблонов и действий.
На все можно посмотреть с других сторон:
Писать в комментарии описание к задаче может быть единственным ключиком для понимания происходящего при отсутствии документации или устаревших версиях (как очень часто бывает). Кусок кода может сам по себе может ровным счетом ничего не сказать о причине его написания, и даже запутать. А времени на что, чтобы разобраться во всех взаимосвязях может уйти неприлично много.
Поскольку негативные результаты использования конструкции "через точку" описаны, обозначу варианты когда же все-таки можно допустить использование: если нам нужно разово обратится к нужным данным и сделать это нужно максимально быстро. Если в процессе интерактивного взаимодействия нам не нужно брать из базы многократно одни и те же данные, что использование данной конструкции не влияет на получение результата с точки зрения использования, но повышает читаемость и понимание происходящего. Зачем тратить время на создание громоздкого запроса к базе, который будет использован для получения всего одной строки? Опять же область применения такой конструкции сужается, важно понимание что мы не будем нагружать базу таким методом, т.е мы должны быть уверены что данных в таблицах, к которым обращаемся, должно быть немного.
-
-
Безусловно правильно проектирование конфигурации и базы данных с минимально необходимым количеством объектов. Но есть варианты, когда действительно важно разделить модули по разделам использования, особенно если доработки ведут разные поставщики услуг.
"God object" - вы описываете извращенное понимание и применение таблицы или базы для хранения настроек, шаблонов и повторно используемых значений. Считаю что такие таблицы должны быть для удобства, причем должна быть возможность менять данные настроек интерактивно. Опять же, для каждой задачи нужно придумать свою структуру во избежание излишней гибкости, так и во избежание ограничений по хранению нужных данных.
Для того чтобы определить, использовать ли "Try", нужно все же попытаться найти причину возникновения исключений. Большинство явно не горит желанием разобраться и потому действительно используют не по назначению. Но как всегда, есть исключения, в основном это обработка внешних событий.
Про метод Выгрузить() как-будто немного зависти есть только потому что такой метод существует :) Все методы нужно применять с пониманием, когда это можно использовать и это оптимальный вариант. Когда структура идентична. Почему нет? У Вас есть сведения что метод работает некорректно? Зачем в очередной раз изобретать велосипед если для этого и сделаны такие методы. Или может зачем использовать фреймворки? Тру программисты только на ассемблере пишут.
Причиной этому является в основном непонимание заказчиком потребностей и неспособность задать правильные вопросы на начальных этапах разработки. В итоге достаточно часто интерфейсы выглядят монструозными :) после внесения кучи правок и фич. Изначально все стремятся достичь совершенства в соответствии с собственным пониманием и опытом, но потом одна уступка за другой... и приходится все перепроектировать...
-
-
prohodil_mimo Автор
14.12.2021 12:27+1Если честно, я не очень понял суть Вашего комментария. Вы не поняли, что статья - сарказм, или Вы говорите о том, что это всё не должно быть сарказмом, а должно быть написано в реальных руководствах для программистов 1С?
altone
14.12.2021 13:56Ну почему-бы не объяснить для не-1Сников, что на самом деле всё не так просто? Добавлю туда же:
1) 1С, к сожалению, не сделала в обычном конфигураторе ничего для сохранения комментариев в запросе, из-за чего у вас есть возможность писать комментарии перед ним (что для запросов в 2000+ строк зачастую не очень осмысленно), либо писать внутри и бережно, вручную потом восстанавливать после конструктора (либо редактировать запрос вручную).
...
3) Та же БСП настолько велика
и всеобъемлюща, что поиск нужной функции в ней может в разы превзойти время написания своей. И ещё не факт, что эта функция потом не изменится...4) В этом месте вспоминаем, что, например, цикл в одну строку работает быстрее "красивого цикла".
5) Зачастую при первоначальном программировании не очень понятно, куда именно пойдет данная функция/процедура (ну кроме очевидных сервер/клиент). По идее после окончания прототипирования хорошо бы отрефакторить, но на это не всегда есть время и деньги.
...
7) Попытки не всегда используются в критичных местах кода, иногда можно просто что-то попробовать сделать и идти дальше.
...
...
...
Вообще, у 1С (да, наверное, не только у 1С) есть определенная специфика — волшебная фраза "надо вчера". Зачастую такие обработки/отчеты/решения нужны на один раз. В таких случаях обычно не важно, насколько красиво/оптимально сделано — а важна именно скорость выполнения. К сожалению, иногда такие решения живут значительно дольше, чем ожидалось. Ну так исправление этого — ваша (наша) же работа, о чём тут ныть?
dima_home
14.12.2021 13:58Просто когда шутят над тем, что ты используешь каждый день и при этом называют твой труд "ректальным" - немного обидно.
В целом я поддерживаю Grigorenkovic во всех пунктах его комментария, кроме 9, в ней автор статьи просто наступили на больной мозоль.prohodil_mimo Автор
14.12.2021 14:01Сразу вспомнил эту миниатюру из Большой разницы - Мы Гестапо, делать больно - это наша профессия)
Чтобы не было больно, можно, например, перестать использовать методики из этой статьи, и начать работать менее ... ректально;)
yukon39
14.12.2021 14:13+1Если вы вышеперечисленное используете и делаете ЕЖЕДНЕВНО, то, извините, по другому кроме как «ректально» это и не назвать.
Не делайте так!dima_home
14.12.2021 16:38Как же не делать, если функция НАЙТИ вместо запроса, которую тут "заклеймили ректальной", единственная функция в языке 1С которая позволяет вести поиск данных с учетом различий в регистре.
Вот и приходится делать сразу два "ректальных" решений в одном куске кода (ВЫГРУЗИТЬ И НАЙТИ):
Запрос = Новый Запрос("ВЫБРАТЬ | РеализацияТоваровУслугИТ_КодыМаркировок.Ссылка | РеализацияТоваровУслугИТ_КодыМаркировок.СерийныйНомер |ИЗ | Документ.РеализацияТоваровУслуг.ИТ_КодыМаркировок КАК РеализацияТоваровУслугИТ_КодыМаркировок |ГДЕ | РеализацияТоваровУслугИТ_КодыМаркировок.СерийныйНомер = &КодМаркировки"); Запрос.УстановитьПараметр("КодМаркировки",ИскомыйКМ); ТаблицаНайденныхКодов = Запрос.Выполнить().Выгрузить(); //а теперь ищем еще раз, уже через регистрозависимый способ поиска НайденныеСтроки = ТаблицаНайденныхКодов.НайтиСтроки(Новый Структура("СерийныйНомер",ИскомыйКМ); Если НайденныеСтроки.Количество() Тогда //Действительно найденны КМ именно те КонецЕсли;prohodil_mimo Автор
14.12.2021 17:02Заклеймили не саму функцию Найти(). Заклеймили только её необдуманное использование. Более того, весь сарказм статьи направлен на необдуманность. На то, что людb знают способ решения проблемы, но не задумываются над тем, как всё устроено под капотом, как всё написанное будет ложиться в парадигмы и в последующую жизнь системы и т.п. Многие знают, что найти что-то можно через Найти - и им больше ничего неинтересно. Они используют Найти не потому, что регистрозависимое, а потому что им и неинтересно что-то ещё знать.
А ведь это и есть то самое, что отличает недомиддлов от миддлов и сеньоров. Но в сфере 1С (да и не только, будем откровенны) очень много недомиддлов стоят на должности миддлов, сеньоров, архитекторов, РП и т.п.
VVizard
14.12.2021 20:22Возьмите любой ORM или тем более современный JS framework там 30% разработчиков не то что не задумываются о том как это реализовано а даже не понимают что там вообще что то под капотом), особенно это касается Frontend.
prohodil_mimo Автор
15.12.2021 11:21Совершенно верно. Поэтому я и сделал ремарку о том, что не только 1С-ники узнают себя в этой статье.
TheDeadStone
14.12.2021 17:20+1В 8.3.20 в язык запросов добавили функции
ВРег(Upper) – преобразует все символы строки в верхний регистр.
НРег(Lower) – преобразует все символы строки в нижний регистр.
Так что Вы сможете всё проверки делать в запросе.
dima_home
14.12.2021 17:47UPPER и LOWER предназначены для другого и добавляет SQL дополнительную работу.
Для поиска правильно использовать COLLATE.
Но в нашем примере новые функции не спасут отца демократии, поскольку изначально база 1С создана в рекомендуемом режиме сортировки: CYRILLIC_GENERAL_CI_AS (Порядок словаря, без учета регистра).
Вот если бы 1C предложила в язык запросов такое: "ПОДОБНО_С_РЕГИСТРОМ"SELECT * FROM myTable WHERE myField = 'sOmeVal' COLLATE CYRILLIC_GENERAL_CS_AS
altone
14.12.2021 14:12+210) Я бы написал:
Если Найти("Справочники,Документы,Планы видов характеристик,Планы счетов,Планы счетов,Задачи,Бизнес-процессы,Планы обмена",ЭтаФорма["ДеревоМетаданных"].НайтиПоИдентификатору(ТекСтрока).ПредставлениеОбъекта)>0 Тогдано не факт, что это было бы оптимально. Потому что то, что выглядит оптимально в коде - не всегда оптимально по факту. Вот, например, мой старый комментарий:
// В текущей версии 1С "Найти" работает быстрее даже сравнения ПрефиксСтроки="SUBJECT:" Если Найти(ПрефиксСтроки,"SUBJECT:")>0 Тогда СтрокаДаты = ТекСтрокаКонвертаСокрЛП;Плюс 1С обычно имеет историю разработки, и, зачастую, всё начиналось с одной строки в "если", на двух строках оптимизировать было ещё рано, а на трёх — уже поздно. Причём в 1С тоже действует святой принцип "работает - не трожь", так что рефакторинг будет производится только когда это место всех достанет.
Grigorenkovic
16.12.2021 12:09-1Если бы статья была на инфостарте, я бы даже еще несколько пунктов добавил, но здесь большинство сарказма не увидели :) типа в очередной раз убедились какие 1сники недопрограммисты
saboteur_kiev
14.12.2021 14:48+4Ведь кто ещё смог бы научить его определять по звуку вентилятора охлаждения процессора, что операция, которая висела в 1С 40 минут, уже завершилась?
Лучшая шутка в статье.
Nehc
14.12.2021 15:13+1>>> Бесспорным фактом является то, что раз 1С создана с такими возможностями, значит их и нужно использовать, а не слушать еретиков.
Вот уж действительно — вредный совет… ) Во-первых, зависит от задачи: если вы работаете с единичными объектами: заполняете программно новый объект/запись, либо формируете какую-нибудь печатную форму — получение значений полей через точку вполне оправданно, хотя бы даже просто в плане громоздкости/читаемости кода… А во-вторых — запрос запросу рознь! Тут в комментариях уже были примеры, но на мой взгляд не достаточно сильно в них акцентировали внимание на ключевой момент: получение значений через точку В ЗАПРОСЕ гораздо опаснее, чем получение значения через точку в коде! ;) Потому, что в коде это точно единичный объект, а в запросе это неявное левое соединение. Причем в определенных случаях (Регистратор.Номер) — не одно, а десятки!
У вас получается что через точку в коде нельзя, а запросом можно. В то время как на самом деле нельзя (по крайней мере, не желательно) именно комбо: в запросе через точку! )LARII
16.12.2021 01:22Через точку в коде тоже платформа получает составной тип с массой джойнов. Только ещё без конструкции разрешенные и без возможности использовать CAST.
sets
14.12.2021 18:57Никогда не писал на 1С, но вроде всё кроме пункта 8 опознал, широко распространенные и уважаемые среди настоящих программистов практики. Что является аналогом 8 вне 1С?
prohodil_mimo Автор
14.12.2021 20:10+1Дело в том, что в 1С много встроенных прямо в язык штуковин, облегчающих написание кода. При том совершенно не обязательно эти штуковины оптимальны и не сказываются на производительности.
Аналоги? Ну представьте, что у вас есть библиотека, а ней есть метод, который превращает дерево в плоский массив. Понятное дело, что эта функция имеет место быть и вполне может использоваться для каких-то задач. Но ректальный программист использует её, например, для того, чтобы потом обойти этот массив и вывести сообщение. Т.е. ему лень писать рекурсию для обхода дерева. Поэтому он вначале использует функцию для преобразования дерева в массив, а потом уже этот массив в цикле обходит и по каждому элементу выводит сообщение. Т.е. две циклические операции вместо одной - и всё это просто потому, что ему лень написать метод на пару строк длиннее. При том, что размер дерева может быть практически любой.
elFurion
15.12.2021 10:07+2ТЧ.Загрузить(Запрос.Выполнить().Выгрузить());
Пример вне 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
Это конечно же пример того как делать не надо :) Вместо этого следует построчно считывать и обрабатывать информацию в цикле. Потому что оперативная память не резиновая. И еще не факт, что потребуется обработать всю информацию целиком.
MarazmDed
14.12.2021 19:49+1Самое главное не сказали: а собственно,почему ректальное программирование в моде в мире 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 рабочих мест. Кроме душевных терзаний профессионалов такой говнокод не будет иметь никаких последствий с точки зрения производительности. Понятно, что если такой гений придет в контору покрупнее, то уже нужно живительный ректальный криптоанализ применять, для выпрямления рук. Но в ШаражМонтажКонторе - и так сойдет.
prohodil_mimo Автор
14.12.2021 19:59+2Постоянно слышу какой-то комплекс неполноценности от 1С-ников. Статья ведь совсем не о том, что 1С плох. Она о том, как ректальные 1С-программисты (которых там много, но далеко не подавляющее большинство) не хотят ничего знать и ни о чём думать.
Но упорно натыкаюсь на комменты, где пытаются оправдать 1С. Зачем? Она разве нуждается в оправдании? Почему вы чувствуете неуверенность в себе, занимаясь 1С? 1С, как и вообще любой язык, фреймворк и среда - это просто инструмент достижения цели проекта. Обычно холивары на тему "труЪ" устраивают джуны с тремя днями опыта, которые и "свой" язык не знают, не то, что могут сравнить его с 1С.
Поэтому, думаю, вам надо перестать беспокоиться и оправдывать 1С - это не нужно. 1С - это просто одна из технологий в мире технологий, с плюсами и минусами.
monane
14.12.2021 20:38+4«Есть всего два типа языков программирования: те, на которые люди всё время ругаются, и те, которые никто не использует.»
Bjarne Stroustrup.https://habr.com/ru/post/144632/
Я вот не 1С програмист, но как и многие "тру" кодеры зачеркнуто програмисты, увидел в статье очень многое из того что видел. Такой вот калабур ;-)
Как видите статья зашла, я же говорил вас много тема живая и актуальная.
MarazmDed
16.12.2021 12:511С - это просто одна из технологий в мире технологий, с плюсами и минусами.
Я ровно это и хочу показать своими комментариями.
По поводу комплексов - их нет. А вот негативное отношение к 1С со стороны хабрасообщества - есть (скорее всего, среди той части, которая джуны без 3 дней опыта).
Да, среди 1сников просто огромное море говнонедокодеров, но ситуация проста: порог входа. Теперь любая кухарка может управлять 1ской.
prohodil_mimo Автор
16.12.2021 12:58+1А вот негативное отношение к 1С со стороны хабрасообщества - есть
Почему вас это беспокоит? Кстати, ни одного холивара здесь в комментариях от неодинэсников не было. А вот комплекса неполноценности от одинэсников, почему-то, очень много. Что очень странно для меня. Во-первых, зачем вообще переживать от того, что кто-то думает? Во-вторых, если вообще хочется чем-то меряться, то ни одной прямой линейки нет, зато есть много косвенных. В 1С вполне средняя по ИТ зарплата, средняя по ИТ занятость, средний по ИТ спрос и т.п. Не понимаю, зачем писать портянки оправданий 1С, тем более там, где никто 1С даже ни в чём не обвинял.
Повторюсь, 1С - это просто одна из технологий в мире технологий, с плюсами и минусами.
Да, среди 1сников просто огромное море говнонедокодеров, но ситуация проста: порог входа. Теперь любая кухарка может управлять 1ской.
Порог входа постоянно повышается. Говнокодеров везде много. Собсна, потому я и сделал приписку, что многие узнают эти методики, даже ни дня не работая в 1С. И, как показали
drWhy
16.12.2021 13:56«1С — это просто одна из технологий в мире технологий, с плюсами и минусами»
Бывают случаи, когда используется только платформа — наблюдал БД, пересаженную с Delphi/Paradox сотрудником по собственной инициативе, просто потому что мог. В итоге он ушёл, а организация осталась с новой лицензией и совершенно уникальной конфигурацией.Ta_Da
16.12.2021 17:09Бывают случаи, когда используется только платформа — наблюдал БД, пересаженную с Delphi/Paradox сотрудником по собственной инициативе, просто потому что мог
Бывает, да. Я допустим так работаю ("совершенно уникальные конфигурации" в смысле, а не "перевел на 1С потому что мог"). О рисках всегда предупреждаю заранее. В чем вы видите проблему?
drWhy
16.12.2021 17:27Но проблемо, если переход согласован. Та БД к бухгалтериии не имела ни малейшего отношения, т.е. вся стандартная конфигурация была просто выброшена. Предыдущий вариант был сделан давно предыдущим сотрудником, исходники сохранились. Перенести можно было на любую платформу, человек сделал на том чем владел, ни с кем не согласовав. Позже руководство было вынуждено приобрести лицензию на платформу. А к простой БД с исходниками приложения добавился необъятный монолит, который придётся допиливать у соответствующих специалистов. КМК получился не самый оптимальный вариант для пары табличек и пары формочек.
Ta_Da
16.12.2021 17:38Та БД к бухгалтериии не имела ни малейшего отношения, т.е. вся стандартная конфигурация была просто выброшена
90% решений на 1С тоже к бухгалтерии отношения не имеют, в общем-то. При этом стоимость именно готовых решений на 1С - копеечная. Вопросы скорее в стоимости пользовательских / серверных лицензий. И внедрении/адаптации.
Перенести можно было на любую платформу, человек сделал на том чем владел, ни с кем не согласовав. Позже руководство было вынуждено приобрести лицензию на платформу.
Какой-то 1С-ниндзя, который незаметно для руководства переписывает все на 1С, а руководство это замечает только когда он уволился =)
А к простой БД с исходниками приложения добавился необъятный монолит, который придётся допиливать у соответствующих специалистов. КМК получился не самый оптимальный вариант для пары табличек и пары формочек.
А монолит-то необъятный откуда появился, если исходная система была из пары табличек и пары формочек? Все-таки либо 1С-ник взял что-то готовое (допустим, была база из двух табличек по расходу материалов на производстве, а 1С-ник развернул ERP) или руководство "забыло упомянуть", как этот монолитный монстр вырос из их же "хотелок" на этапе замены Delphi на 1С. Так-то небольшую базу из пары табличек на 1С напилить и сопровождать будет скорее всего дешевле, чем на Delphi (если там и правда была пара табличек) - любой студент справится.
drWhy
16.12.2021 17:47«Какой-то 1С-ниндзя, который незаметно для руководства переписывает все на 1С, а руководство это замечает только когда он уволился =)»
Таки да. Ну а что такого — данные вводятся, выборки делаются. А потом внезапно инвентаризация ПО.
Под монолитом имел в виду собственно платформу. К запорожцу гусеницы прилипли. Вы бы к примеру взялись сконвертировать уникальное приложение обратно в Delphi или любой другой язык за цену лицензии?
VVizard
14.12.2021 20:45Все так и есть, 1С это действительно доступно и всерьез.
Единственное в чем я с вами не согласен так это в масштабе до 1000 человек. Проблем не будет с типовыми решениям до 200-300 пользователей.
Дальше уже начинаются сложности, нужны эксперты которые за этим будут следить. Но даже для 300 человек сложно найти не допиленную типовую, и вот дальше у платформы появляются проблемы:
Неквалифицированные кадры (низкий порог входа, низкие ЗП)
Запредельная сложность крупных конфигураций (Отсутствия ООП, Типизации, Какой либо структуры хранения модулей)
Сложность прикладной части (это отдельная боль).
Отвратительная производительность платформы (тут ниже есть мой пример сравнения с java)
Игнорирование прогресса в разработке СУБД начиная с 92 года. (Газпром вынужден тратить миллиард на сервера СУБД под 1С потому что у 1С есть файловый вариант для ларька который дережит Арсен, и все возможности платформы по работе с СУБД ограниченны этим вариантом).
Жесткий монолит (тут без коментариев, достаточно посмотреть как реализована бесшовная интеграция с документооборотом, я когда смотрю всегда восхищаюсь тем сколько сил и труда было вложено в то что в WEB разработке идет бесплатно).
-
Сжатые сроки + бизнес на первом месте, а отдел автоматизации где то между завхозом и гаражом, прибыли не приносит, сидят там одни дармоеды и вот это все...)
Причем эти пункты нужно не складывать а перемножать. И
surVrus
14.12.2021 23:38-11) только 1С покрывает все нужды бизнеса в автоматизации с 0 до, скажем, 1000 человек.
Не только. Есть OfBiz. Как система для операционной деятельности более-менее вменяемой фирмы - самое оно. Классом выше, чем все, что я видел и ковырял в 1С и подобных продуктах.
9_pm
15.12.2021 06:35+1Вся соль 1С как раз в том, что нужда бизнеса - особенно бизнеса маленького - в автоматизации в первую очередь касается как раз не операционной деятельности, а регламентированного учета, сдачи отчетности, взаимодействия с разнообразными государственными информационными системами и т.д. А тут у 1С в РФ просто нет достойной альтернативы как ни крути, потому что ни один OpenSource или стартап не будет так же тщательно следить за каждым чихом наших регуляторов и реагировать во вменяемые сроки.
А вся организация именно операционной деятельности бизнеса до, скажем, 100-200 человек вполне реализуется в понятном каждому экселе или гугл таблицах. Если грамотно наладить процессы, то и больше можно. А когда компания дорастает до того, что ей реально надо автоматизировать операционную деятельность, то она обычно к этому времени уже обросла продуктами 1С для регламентированного учета, поэтому использует то, что знакомо.
И при всей моей любви к 1С это печальная на самом деле ситуация, так как отсутствует конкуренция. Но честно говоря, единственный выход, который видится, находится вне возможностей как самой 1С, так и сообщества или потенциальных её конкурентов. Это прекратить регулировать бизнес с такой скоростью, чтобы поддерживать отчетность можно было только поддерживая целый штат достаточно грамотных и от этого очень дорогостоящих технических специалистов.
surVrus
15.12.2021 13:02а регламентированного учета, сдачи отчетности, взаимодействия с разнообразными государственными информационными системами и т.д.
Все зависит от организационной схемы бизнеса. Например, пекарня. Которая производит 10-12 продуктов, 3-4 человека персонал. Юридически это может быть какой-нибудь ИП с упрощенным налогообложением (или типа патента, не знаю как это сейчас называется). То есть юридически - почти учета не надо. Но нужно быстро, качественно и с минимальными усилиями получить MRP/ERP/CRM и потом со всякими иными приблудами (типа электронной коммерции). Тут Ofbiz гораздо интереснее 1С. Я много лет использовал 1С, с самых ранних версий, и до новейших. Все там неплохо, в определенной логике бизнеса - все работает.
Но когда столкнулся с реальным производством, реальными иными требованиями к бизнесу (в Польше), то понял, насколько же в 1С все криво, косо и устарело. По сравнению с тем же Ofbiz. Ну и открытость проекта, плюс его работа на Linux перевесила все плюшки от 1С.
Если же нужен "бухучет" - то да, 1С - прелестно.
prohodil_mimo Автор
15.12.2021 13:21Дело в том, что решение о внедрении продукта - очень мультифакторно. То, что есть какая-то сферическая идеальная система совсем не означает, что выберут её. Вот несколько параметров только навскидку:
Количество экспертизы на рынке. Если купить 1С, то щелчком пальца можно найти и программистов, и аналитиков, и обучаторов и большие команды внедрения и т.п. Насколько бы офигенной не была система, она не нужна, если я не смогу себе найти аналитика, чтобы мне поставил учёт в этой система пять минут назад.
Количество кадров на рынке. Оператора 1С, бухгалтера 1С, РП 1С, программиста 1С найти несложно. Насколько сложно найти мне в штат оператора вот этого Офбиз (не чванство, просто действительно первый раз слышу о такой программе)?
Из п. 1 неизбежно вытекает стоимость и возможность доработок. Когда мне нужна будет печатная форма с моим гербом или отчёт продаж с учётом погоды на день продажи, я могу это всё купить занедорого - 1С позволяет дорабатывать, а на рынке много рабочей силы. Как с этим у офбиз? Смогу ли я найти программиста? По какой цене? Где?
Гениальность 1С вообще не в качестве продукта. У них вот буквально лет пять как вообще о каком-то качестве можно говорить, до этого ёжики плакали и кололись, все, кто работал с 1С, её ненавидели, особенно пользователи. Гениальность в том, что они смогли создать дешёвый продукт, выполняющий задачу, создать сеть распространителей "от тайги до британских морей" и создать огромный вал рабочей силы любого качества в этой сфере.
Ta_Da
15.12.2021 15:40-1Любопытства ради, а что конкретно, по сравнению с OfBiz "криво, косо и устарело" (может где-то можно покрутить демку, сравнить, не перелопачивая наугад всю документацию и тыкаясь в кнопки)? Вы про платформу или про конкретные решения на платформах?
surVrus
15.12.2021 18:18Там же можно скачать полную версию, с демо базой данных. Там же есть и линк на демку, работающую он-лайн.
а что конкретно
Трудно коротко ответить, самое точное - почти все. Я не супер-специалист в 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 вовсе не идеал. Глюков - куча. Но мне больше нравится.
Aevarandi
16.12.2021 10:18+1Все это выглядит гораздо худшим решением, чем 1с для мелкого и среднего бизнеса. Странно это упоминать как хорошее решение для пекарни в 10-12 человек. Готового решения нет, документации нет, работает под linux в котором обычные люди мало работают и даже простые задачи им делать будет сложно, размер базы что 400мб, что 10 гигов никого волновать особо не будет при размере современных дисков. И в той же хорека, если захочется интегрироваться с r-keeper или storehouse в 1с просто можно взять готовое решение, то в OFbiz придется писать решение для интеграции. 1с может обслуживать то еще удовольствие бывает, но зато из коробки может решить кучу проблем. Если нужно решать уникальные задачи делать это не на 1с разумно, но для обычных небольших бизнесов явно проще взять коробку с 1с.
drWhy
16.12.2021 12:34«размер базы что 400мб, что 10 гигов никого волновать особо не будет при размере современных дисков»
Для оператора может и всё равно, хотя банально остатки вывести из мелкой базы будет побыстрее, а для генерации отчётов на базе покрупнее вполне может потребоваться распределённая база с синхронизацией, ну или генерировать отчёты по ночам.
prohodil_mimo Автор
16.12.2021 13:05+2Полностью согласен. Единственный кейс, который я бы видел для этого офбиза - это команда с кучей внедрений, которая даёт клиенту в два-три раза меньшую цену за внедрение, чем за 1С, причём под ключ. В остальном - больше похоже на автомобиль, который забираешь не со стоянки, а с конвейера завода, разобранным до винтика, а винтики ещё и с правой резьбой, а гайки не 13, 17, а 18.4 и 22.6, и вообще многое ещё надо паять и варить. И всё это - без документации.
Ta_Da
16.12.2021 17:16Там же можно скачать полную версию, с демо базой данных. Там же есть и линк на демку, работающую он-лайн
Да, на оффсайте демку я нашел, просто вот при беглом взгляде "вау"-эффекта не испытал - поэтому и поинтересовался чем-то конкретным, чтобы исключить синдром утенка.
По вашим наводкам посмотрю (модели данных, каталоги и т.д.), спасибо. Вполне возможно, что что-то полезное почерпну.
И да, Ofbiz вовсе не идеал. Глюков - куча. Но мне больше нравится
Что бы он еще где-то был, этот идеал. Везде набор компромисов и граблей.
telnov
14.12.2021 21:40+2Забавно. Знаком с похожими перлами. Видел такой стиль программирования в на работающем решении. Делал программист который работает в "самой" роснефти. Там местами пожесче было. Приходилось исправлять. 1С прощает многое... Этим пользуются не компетентные и бестолковые индивиды которые называют себя программистами. Программирование это понятие вне синтаксиса вне платформы. Существует само по себе. Оно в голове, а не в компьютере. Если человек изучил синтаксис, то это не значит что он умеет программировать.
gbr
15.12.2021 15:51+1Ректальное программирование как метод не должно ограничиваться технологиями 1С. Обращаюсь к сообществу с просьбой проекции и миграции передового опыта на другие технологии.
zorggroz
15.12.2021 16:10+2С языка сняли, ведь описанное не относится к 1с языку как таковому, проблемы то общие.
LARII
16.12.2021 01:12Самое печальное, что если будете писать лучше, чем выше приведенный метод, то просто уволят. Сократят. Ибо все будет хорошо. И вспоминается старый анекдот, как старый врач оставил на клинике сына, а тот возьми да и вылечи постоянного клиента, которого старый доктор лечил всю жизнь.
odinesnik
Стаж в 1С — 20 лет. На Хабре недавно. Очень интересно понаблюдать за развитием комментариев в такой ветке :))