Зачем 1С так усложняют свои типовые конфигурации (УПП) #527120

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

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

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

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

1.3 ?

Что-бы все было сложно и обычный бухгалтер не смог ничего изменить, а УППисты получали отстатыщ ! Неужели непонятно

да

+500. там давно уже черт ногу сломит. да и любой другой

1.2 норм, привык. >пишут напрямую в регистр - а как ещё их делать можно?) Зато програмеры УПП не будут бедствовать, работа есть всегда

Говорят в 1С были программисты которые предлагали все написать чисто и ясно в УПП. Но под коверные интересы и тайный заговор позволили уволить эти программеров и они с горя ушли в Парус

самый правильный ответ был дан в

$

Меня другое бесит - когда не соблюдают свои-же правила оформления кода. Один из примеров: После обновления превращается в: ..>>Если ...... >>>>КонецЕсли; , где .. - два пробела, а >> - символ табуляции.

За 2 недели (2 программиста) перевели сильнопереписанную конфигурацию с 1.2.8 на 1.3.7 (с учетом своих особенностей) а ты болобол, который только и научился на мисте трындеть.. (если тебя все устраивает, твой вариант "3" - больше от тебя не требовалось в этой ветке)

Во избежания тупых комментов.. Ко всем, я не сказал, что не могу разобраться с кодом.. мое мнение, что 100% можно было написать проще, и работало бы быстрее

в УПП рекомендации не соблюдаются даже, запросы в цикле и т.д.

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

как говаривал Нуралиев - лучше безобразно но однообразно.

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

Спецом? А для чего?

Ну дык.. Эволюция... Или мутация.. Смотря с какой стороны смотреть.

напиши свое

из того, что ты что-то не осиливаешь, не следует, что это что-то плохо сделано

Да и вооще: То, что не развивается - умирает

наше мнение обратное

Но УПП пытается и развиваться и деградировать.

или давай конкретные примеры, или завязывай трепаться

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

УПП слишком проста... там многое упростили из за того, что 1Сики понять не могли

нормально все, даже отлично!

а как бы ты написал этот кусок кода?

Вынести специфичные для доков вещи в функции модуля менеджера

Есть сложности - есть работа. :-)

так конкретика-то будет?

Помню лет 5 назад дискуссии SAP vs 1C. Главный тезис - 1С легко доработать под нужды предприятия, любой каприз за ваши деньги, САП громоздкий, доработать что-то сложно и дорого. Кто-то хвастался, что до 80% конфы переписывал. К чему пришли?

Пример: Процедура СформироватьДвиженияПоВыпускуПродукцииИНаправлениямВыпуска .... и так куча проверок а в конце эти тексты передаются в процедуры СформироватьДвиженияХХХ... Вопрос: разве нельзя получать эти все текст в модуле самого объекта, а потом уже, если хотят, вызывать напрямую функцию СформироватьДвижения? Зачем выносить это в общий модуль со всеми этими проверками на тип? до перехода на 1.3.7 я практически обходился без изменения общих модулей а сейчас получается почти все модули общие дописанные (хоть и изменения не очень большие) так труднее теперь отслеживать обновления этих модулей

уродство типовое

Все очень просто. Это из-за универсальности. Узкие, специализированные системы, как правило, значительно проще.

А потом если нужно добавить еще 1 измерение в регистр, то захватывать и править кучу объектов? В данном случае, имхо, логика есть - формирование движений в одном месте.

тотже самый пример : Процедура СформироватьДвиженияПоВыпускуПродукцииИНаправлениямВыпуска внутри этой процедуры во вложенности вызывается Процедура СформироватьДвиженияПоВыпускуПродукцииНаСклад, в которой делаются движения по складам, я добавляю одно измерение в регистр ТоварыВРезерве, в итоге приходится все равно для каждого объекта в отдельности переделывать движения..  и нет никакого "одного" места, где было бы все собрано..

С УПП не работаю, но если потребуется, разберусь.

напиши лучше... Ну или покажи

В рамках 1 модуля или в рамках нескольких объектов? Одно дело, когда чтобы внести имправление, захватываешь 1-2 модуля. Другое дело, когда завжватываешь еще объектов

А по голосовалке

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

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

в написано "Зачастую, замедление проведения". Претензиями к читабельности можно пренебречь, поскольку это субъективный критерий

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

уволить, нельзя оставить

Скорость поддержки одним программистом, возможно... Скорокть разработки же может замедлить, имхо. Т.к. там отнюдь не 1 программист и захватывать 10 объектов вместо 1-2 - не здорово.

чувствуется большой опыт...

Использовать нужно минимум типового кода 1С. Потому как якобы "типовой" код через некоторое время исчезает из "типовых" конфигураций, и нужно все переписывать/адаптировать заново. Многие 1с-ники путают термины "универсальный", "унифицированный" с тем чудом, что пишет 1С. 1С с универсальностью программирования рядом не стоял, а уж с унификацией - тем более. Ответы "устраивает, потому что деньги идут" - это вообще не по теме. Ответы "Нравится, потому что осиливаю" - мягко говоря, некорректны: 1с свои типовые тоже "осиливает", не уставая из года в год править ворох проблем, ошибок, ляпов, пофигизма. Получая вместо развития зацикливание. Ответы "да, желательно бы все унифицировать", "да, универсальности бы не помешало добавить в 1С" - относятся к теме "Что мы хотим видеть в 1С". В теме же "почему усложняют" нужно обсуждать "считаешь сложным/не считаешь сложным". Ответов же "устраивает, потому что деваться некуда" - нет.

так что: 1, 2, 4, 5 + сменить руководство 1С на корню.

Это потому что в 1С нету ООП.

И чем бы оно помогло? Думаю, если бы оно было так необходимо, то в восьмерке бы оно появилось, так что дело скорее не в этом. Сколько "нетленок" написали?

шли бы вы все в sap...

Золотые слова. Но тут есть куча ярых процедурников которые не понимают в ООП и кричат, что в 1С это не нужно

Может потому и кричат, что есть что и с чем сравнивать? ;)

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

с чем сравниваем? даже Бейсик в плане программирования универсальнее и унифицированее 1С :)

1) Говорите не правду (про нетленки). Зачем? 2) Написать сложную систему сил хватило, разработать свой язык так же сил хватило, а реализовать ООП - нет. Не вяжется одно с другим.

Пусть. А вот FoxPro было совсем не универсальным, но мы же его не с бейсиком, не с С++ не сравниваем ;)

+ потому что Бейсик - это уже ООП и RAD, а 1С - никогда и ни разу ни то, ни другое :)

но вот только программисты, ознакомившиеся с 1с и Фоксом, говорят: ну ваше 1с, я на фоксе лучше тоже самое сделаю!" :)

А что думаете про УТ11? УПП2 будет на базе нее, так что уже можно прикинуть, что нас ждет :)

, этот атомный бред вызван веществами или это что-то эндогенное?

ОФф: "Универсальные" механизмы ВыполнитьПогашениеПотребностиЗаказаНаПроизводствоПоРаспределению     Подряд идут строки:

что за УПП 2? Второе пришествие марсиан? :)

УПП 2.0 что же еще

Лефмихалыч, вы в "Справочнике врача" страницы иногда переворачивайте :) И начните с буквы "А", а не "Э" :)

Им обычно хватало одно взгляда на 7.7, что бы просить фокс.

ну, это еще будет в следующем веке :)

Самое прикольно, что того минимума из ООП, что уже есть в v8, вполне бы хватило для более стройного кода. Тот же банальный приводимый пример с "Если ТипДокумента = ... Тогда" Имхо когда алгоритм нуждается в знании о конкретном переданном типе объекта - это говорит о плохо продуманной структуре проекта. А ведь есть же в 8ке возможность обратиться и к методам модуля объекта, и к методам менеджера. Можно было в базовом алгоритме прописать текст = док.ПолучитьТекстЗапросаПоТабличнойЧастиПродукция; И в модуле документа реализовывать его так, как надо. Вот тут то и всплывает отсутствие в 1С наследования, и придется уже в каждом модуле документа реализовывать функцию ПолучитьТекстЗапросаПоТабличнойЧастиПродукция. А вот на 7ке с 1С++ у меня весь класс проведения ПриходнойРеализатора, отнаследован от ПриходнаяНакладная: Все, сразу понятно, чем он отличается от обычного прихода.

при поиске програмера на УПП 2.0 где реализуют все хотелки за всю историю 1С, надо будет писать АТДВЕСТИТЫЩ

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

см. 41. Хотя я признаю у такого подхода право на существование, но существующая практика групповой разраотки в 8-ке не всегда поддерживает подобный подход, имхо.

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

такая возможность есть только в 8.2 - в виде менеджера модуля. В 8.1 для этого надо объект получать, а вот уже это - ручной тормоз

+ пеляет, не менеджера модуля, а модуля менеджера

И это опять следствие несовершенства инструмента. Ну вот как-то все современные системы контроля версий и групповой разработки обходятся без блокирования объектов, а 1С - не осилила. Чем свой велосипед изобретать - сделали бы выгрузку/загрузку метаданных в текстовики, а там уже к ним любой svn/mercurial/git/fossil бы прикручивался. Для 7ки вон gcomp есть, а для 8ки - нету :(

фигня война прорвешься

кусок кода в студию в подтверждение своих утверждений

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

Ах да, не проголосовал. Только мне не нравится код, но он ПРАВИЛЬНЫЙ! Как раз в соответствии с эволюцией. У нас было такое же в точности развитие. ... Как жаль, что это приходит с опытом и мы не прислушиваемся к уже воевашим на этом фронте

упс...

Вот здесь соглашусь. Кроме того, что для 8-ки нету.

Вот, 1С потихоньку нащупывает пути. И пытается таки сделать урезанное подобие ООП.

"сделали бы выгрузку/загрузку метаданных в текстовики" вот тут ты совсем не прав. Нельзя выносить в текстовики ни вкоем случае! В 77 сделали грубейшую ошибку и теперь пожинают плоды. Все должны быть приучены к порядку: изменения только раз в неделю (месяц или год), со всеми проверками, контролями и оценками в деньгах. Если идут ежеминутные изменения, значит прог мягко говоря не соответствует должности

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

Есть? Где?

А что ни кто не упоминает про отсутствие расширенных работ с файлами или нет вызовов ИП функций? Особенно интересны просьбы сделать работу со звук.картой

Да? Я тут про ООП уже читаю и прочую ересь тормозящую создание нормальных конф.

Читай избирательно )

Упс... т.е. драки не будет? Жаль...

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

Чесслово не работал с этим чудным инструментом. Объясни мне зачем для разработки он? Неужели сосед не может хранилищем пользоваться? (я честно не понял)

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

Поддерживаю.

а вы много писали на языках с ООП ?