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

Среднее количество функций в стеке вызовов растет неуклонно и необосновано. Количество общих модулей, названия которых я должен помнить - растет.

Все плохо, ящитаю. Положение монополиста толкает коллектив уважаемых разработчиков к потере чувства реальности и прочему маразму

Хочу пойти программировать на шарпе, но не могу, у меня ипотека

Вон из профессии

(1) Низя, ипотека

клюшечник, иди делай уроки

(1) Тебе то что? Или ты в такой форме дружеские советы даешь?

А что тогда ныть, если ипотека?

(4) а тебя задело, признай?

(5) А что хорошего-то?

да, все очень плохо

(0) 2 варианта: растанься с хатой но иди шарпуй или кот заклей скотчем и одинэсь!

разработчики типовых любят использовать конструкции типа

Процедура сформировать()
СформироватьОтчет();
КонецПроцедуры;

Процедура СформироватьОтчет()
Ещечтото();
КонецПроцедуры;

Процедура Ещечтото()
..
КонецПроцедуры;

все хуже некуда

(6) Да так, легкое желание взять и уе...ть. Это мелочи

(12) а никак не уе...шь, обломайся

Это не сложность растет, а программисты тупеют.

а в шарпе ТС будет мучить уборка мусора и вообще..)

а вот еще приколы от разработчиков типовых УФ

&НаКлиенте
Процедура ВидОперацииПриИзменении(Элемент)

   ВидОперацииПриИзмененииНаСервере();

КонецПроцедуры

&НаКлиенте
Процедура ДатаПриИзменении(Элемент)
   
   ДатаПриИзмененииНаСервере();

КонецПроцедуры

&НаКлиенте
Процедура ОрганизацияПриИзменении(Элемент)

   ОрганизацияПриИзмененииНаСервере();

КонецПроцедуры

&НаКлиенте
Процедура СкладПриИзменении(Элемент)

   СкладПриИзмененииНаСервере();

КонецПроцедуры

&НаКлиенте
Процедура КонтрагентПриИзменении()

   КонтрагентПриИзмененииНаСервере();

КонецПроцедуры

&НаКлиенте
Процедура ДоговорКонтрагентаПриИзменении(Элемент)

   ДоговорКонтрагентаПриИзмененииНаСервере();

КонецПроцедуры

&НаКлиенте
Процедура СпособЗачетаАвансовПриИзменении(Элемент)

   СпособЗачетаАвансовПриИзмененииНаСервере();

КонецПроцедуры

&НаКлиенте
Процедура ГрузополучательПриИзменении(Элемент)
   
   ГрузополучательПриИзмененииНаСервере();
   
КонецПроцедуры
клиент-серверное мышление

(0)Забей на типовые приемы. Пиши сам:-)

(12) уепись головой ап стенку - мб поможет тебе

Вообще я не дибил, если что. Коллеги меня всегда уважали

(19) это ты самому себе чсв повышаешь?

(19) >Вообще я не дибил

шо, даже справка есть? :)

(16) В типовых и в обычных формах лулзов достаточно.

Интересно, а что повышают себе все, кто сразу накинулся гнобить нытика? )

ничего прекраснее управляемых форм не встречал...

(19) А теперь и это в прошлом? :))

(21) А у тебя тоже нету, не выделывайся

(0) считаешь, надо отказаться от модульности и один и тот же код повсюду копипастить?

а на этом форуме ругать разработчиков не принято)
суперлюди будут с пеной у рта доказывать, что это не глюки, а особые фичи

(23) все по законам природы. Меня гнобили и я гноблю. Думаешь здесь сказка?

+(17)А вообще после пары лет чтения типовых модулей как то привыкаешь к их ипанутости и стараешься не использовать особенно заковыристые изыски.

(16) А в УФ разве можно как-то иначе?

(0) так это же хорошо..

меньше случайных людей в профессии, больше бабла профессионалам..

(19) Целиком и полностью согласен. С каждой новой конфой теряются некоторые положительные наработки и заменяются тупыми универсальными никому ненужными фичами.

(29) Это не закон природы )))

(28) Есть такая фигня. Читали "Новое платье короля"?

(16) А что тебя смущает?

(35) дай угадаю, это та сказка, где король голый и которую читают всем детям до пяти лет?

(33) И где они профессионалы?

(37) Ты наверное еще до нее не дорос, без обид))

(34) это закон природы! На Мисте выживает только сильнейший.

Создание софтварных ключей 1с - это конечно хорошо, но далеко нехорошо усложнять админам жизнь и удорожать использование таких ключей.

традиционно:


Если ВидСчетаФактуры = Перечисления.ВидСчетаФактурыВыставленного.НаАванс
           ИЛИ ВидСчетаФактуры = Перечисления.ВидСчетаФактурыВыставленного.НаАвансКомитента
           ИЛИ ВидСчетаФактуры = Перечисления.ВидСчетаФактурыВыставленного.НаСуммовуюРазницу Тогда
           ДанныеДляПечати    = СобратьДанныеСФнаАвансИСуммовуюРазницу(ТекущееОснование);
       ИначеЕсли ВидСчетаФактуры = Перечисления.ВидСчетаФактурыВыставленного.НалоговыйАгент Тогда
           ДанныеДляПечати    = СобратьДанныеСФНалоговыйАгент(ТекущееОснование);
       ИначеЕсли ТипОснования = Тип("ДокументСсылка.ОтчетКомитентуОПродажах") Тогда
           ДанныеДляПечати    = СобратьДанныеПоОтчетКомитенту(ТекущееОснование);
       ИначеЕсли ТипОснования = Тип("ДокументСсылка.РеализацияТоваровУслуг") Тогда
           ДанныеДляПечати    = СобратьДанныеПоРеализацияТоваровУслуг(ТекущееОснование);
       ИначеЕсли ТипОснования = Тип("ДокументСсылка.РеализацияОтгруженныхТоваров") И ТипЗнч(ТекущееОснование.ДокументОтгрузки) = Тип("ДокументСсылка.РеализацияТоваровУслуг") Тогда
           ДанныеДляПечати    = СобратьДанныеПоРеализацияТоваровУслуг(ТекущееОснование);
       ИначеЕсли ТипОснования = Тип("ДокументСсылка.РеализацияОтгруженныхТоваров") И ТипЗнч(ТекущееОснование.ДокументОтгрузки) = Тип("ДокументСсылка.ПередачаОС") Тогда
           ДанныеДляПечати    = СобратьДанныеПоПередачеОС(ТекущееОснование.ДокументОтгрузки);
       ИначеЕсли ТипОснования = Тип("ДокументСсылка.ВозвратТоваровПоставщику") Тогда
           ДанныеДляПечати    = СобратьДанныеПоВозвратТоваровПоставщику(ТекущееОснование);
       ИначеЕсли ТипОснования = Тип("ДокументСсылка.ОтчетКомиссионераОПродажах") Тогда
           ДанныеДляПечати    = СобратьДанныеПоОтчетКомиссионераОПродажах(ТекущееОснование);
       ИначеЕсли ТипОснования = Тип("ДокументСсылка.АктОбОказанииПроизводственныхУслуг") Тогда
           ДанныеДляПечати    = СобратьДанныеПоАкту(ТекущееОснование);
       ИначеЕсли ТипОснования = Тип("ДокументСсылка.ПередачаОС") Тогда
           ДанныеДляПечати    = СобратьДанныеПоПередачеОС(ТекущееОснование);
       ИначеЕсли ТипОснования = Тип("ДокументСсылка.ПередачаНМА") Тогда
           ДанныеДляПечати    = СобратьДанныеПоПередачеНМАОрганизаций(ТекущееОснование);
       ИначеЕсли ТипОснования = Тип("ДокументСсылка.ОтражениеНачисленияНДС") Тогда
           ДанныеДляПечати    = СобратьДанныеПоОтражениеНачисленияНДС(ТекущееОснование);        
       ИначеЕсли ТипОснования = Тип("ДокументСсылка.РеализацияУслугПоПереработке") Тогда
           ДанныеДляПечати    = СобратьДанныеПоРеализацияУслугПоПереработке(ТекущееОснование);
       ИначеЕсли ТипОснования = Тип("ДокументСсылка.НачислениеНДСпоСМРхозспособом") Тогда
           ДанныеДляПечати    = СобратьДанныеПоНачислениеНДСпоСМРхозспособом(ТекущееОснование);
       ИначеЕсли ТипОснования = Тип("ДокументСсылка.ОказаниеУслуг") Тогда
           ДанныеДляПечати    = СобратьДанныеПоОказаниюУслуг(ТекущееОснование, "Контрагенты");
       ИначеЕсли ТипОснования = Тип("ДокументСсылка.КорректировкаРеализации") Тогда
           ДанныеДляПечати = ПолучитьДанныеДляПечатиИсправленияСчетаФактуры(ТекущееОснование);
       КонецЕсли;

типовая

(39) вообще странно, что ваше развитие остановилось на том, что вы сами читали сказку про голого короля. Мне как-то её в детстве читали, а я уже читал более серьезные книги.

(52) и что вас смущает?

(42) А как лучше написать?

(42) с ООП было бы в тыщу раз проще, я помню ту ветку :)

(27) Нет, не надо отказываться от модульности. Структура модульности только должна быть продуманной.

(19) Значит, ты просто дЕбил.

Скорее функциональность ТР растет быстрее чем возможности платформы.

(46) опять дроч на ООП ?

(43) Ты просто не дорос. К более серьезным книгам перешел рано, если не понимаешь смысла такой простой сказки

(45) А помоему он предлагал решение ?

(0) Общие функции чаще полезны, чем бесполезны.
Например, сделал несколько лет назад доработку с использованием общих процедур. Метаданные немного менялись, а старая доработка не потребовала доработки. ;)
Если бы доработка была реализована тупо своим кодом, потребовалось бы много ресурсов, чтобы восстановить её работу.

(47) что там не продуманно?

(42) Полиморфизм от 1С

(53) врешь ведь..

1С настолько часто тусует модули и функции в типовых что как правило использование общих процедур и функций из типовых модулей к следующему релизу перестает работать..

чем сложнее система, тем труднее новичкам и, в итоге, лучше старожилам.

я за усложнение. лишь бы не глючило

Отчасти ТС прав. Постоянное перетасовывание процедур и функций в типовых и вследствие этого переписывание своих наработок после обновления кого угодно взбесит.

(56) +100
1С часто так перех..чивает типовые, что приходится все доработки переписывать.
Никакой совместимости.

Я пишу свои прцедуры и функции или заимствую из ОбщихМодулей

в БП2.0 есть РС "ФИОФизЛиц". При всех равных измерениях и ресурсах, в БП 3.0 этот регистр называется "ФИОФизическихЛиц".
Зачем нужно было переименовывать регистр? Теперь придется переписывать все, что было связано с этим регистром. Лично я не вижу причин, почему нужно было переименовывать регистр, а работы у программистов добавилось прилично.
http://www.forum.mista.ru/topic.php?id=618172

(59) все постоянно меняется и стремится к совершенству.
Может ты слишком стар и пора задуматься о покое?

(61)+100500 поддерживаю

(57) После каждого нового релиза можно заново считать себя новичком )

(62) Это ты про типовые слово "совершенство" употребил?

(59)Может 1С не хочет чтоб 1Ски сдохли с голоду?

(62) Почему-то 1С идет к совершенству очень кривыми тропами.

(0) я пока не вижу особых проблем. да, сложность разработки выросла, но она выросла в угоду производительности и функциональности. платформа растет, что не может не радовать
(61) работа над ошибками, так сказать

(66) Слава 1С и Нуралиеву Б.Н. пророку его!!

(67)  неча на зеркало пенять, коль у самого рожа крива. Возьми да и сделай лучше.

Есть мнени когда иы переделываешь свои поделки ты смотришь код новому применяшь новые фишки и все робит быстрее .

(61) В библиотеке стандартных подсистем может он так называется. Вот они  и приравняли.

(70) гы... угадал :) Уже 4ый год работаем на "лучшем", на переписанной БП.

(64) УТ 11.0.7 и УТ 11.0.9 уже две большие разницы. БП 2.0 хоть стабильна, но удушат её, и БП 3.0 будет повторять судьбу УТ 11.

(16) И в чем проблема? Все верно. Это УФ и клиент-серверная разработка, детка (с)

Не у всех сразу все получается

Семерка убога, восьмерка уродлива. Нет в жизни счастья..

вообще САБЖ боян 20 летней давности....

и придумали тогда сначало DLL а потом и "Компоненты" которые обеспечивали интерфейс взаимодействия...

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

тогда все будет логично, правда до определенного момента :)

(78) Это примерно тоже самое, как у Дельфи или ТуробоПаскаля убрать модульность и вернуться назад, к обезьяне. На одних менеджерах объектов далеко не уедешь.

(78) >> вообще отказатся от общих модулей
Это верно. Точнее пусть будут, но писать название модуля из 30-и символов для вызова функции из 10-и символов, смысл которой понятен и так - верх маразма. Либо синтаксис подключения модулей нужен, либо неймспейсы. Чтобы при большом желании можно было обращаться к функциям через точку, но чтоб это было не обязательно

(80) гениальную конфу в студию

А где Маня ? Уж он то сейчас всем бы разъяснил за восьмерку .

(81) Я не занимаюсь разработкой конфигураций

(75) Код в (16) случается когда тупой программист, как-раз не соображая в клиент-серверной логике, каждый раз тупо бегает на сервер, чтобы ему не мешали ограничения на клиенте.

(80) это перл!

(80) Да. Длинные названия - это зло. Вот помнится раньше длина имени файла была ограничена 8-ю символами. И ничего - всем хватало :)))

(83) а чем занимаешься?

(87) Да 1С-ник я как бы

СхемаКомпоновкиДанных = ПолучитьМакет("ФактЗатрат");
КомпоновщикНастроек = Новый КомпоновщикНастроекКомпоновкиДанных;
КомпоновщикНастроек.Инициализировать(Новый ИсточникДоступныхНастроекКомпоновкиДанных(СхемаКомпоновкиДанных));
ЗУП_ТиповыеОтчеты.УстановитьПараметр(КомпоновщикНастроек, "ОбъектЗатрат", Ссылка);

ДанныеРасшифровки = Новый ДанныеРасшифровкиКомпоновкиДанных;
КомпоновщикМакета = Новый КомпоновщикМакетаКомпоновкиДанных;
МакетКомпоновки = КомпоновщикМакета.Выполнить(СхемаКомпоновкиДанных, КомпоновщикНастроек.Настройки, ДанныеРасшифровки);
ПроцессорКомпоновкиДанных = Новый ПроцессорКомпоновкиДанных;
ПроцессорКомпоновкиДанных.Инициализировать(МакетКомпоновки, , ДанныеРасшифровки);
ДокументРезультат = ЭлементыФормы.ТабличныйДокументЗатратыФакт;
ДокументРезультат.Очистить();
ПроцессорВывода = Новый ПроцессорВыводаРезультатаКомпоновкиДанныхВТабличныйДокумент;
ПроцессорВывода.УстановитьДокумент(ДокументРезультат);
ПроцессорВывода.Вывести(ПроцессорКомпоновкиДанных);

имхо, как бы 1С не реализовывала свои механизмы - одинесники всегда будут чем-то недовольны)

(88) уверен?

(88) тогда свою гениальную разработку выкладывай где у тебя нет кучи переходов по разным процедурам/функциям и между формой и модулем

+(92) чтобы критиковать кого-то, для начала напиши лучше!

(91) Дружище, я вижу ты полон осознания интеллектуального превосходства надо мной... Это так пошло, надо сказать

(93) http://lurkmore.to/Сперва_добейся
?

(94) да господь с тобой, у меня и проф образования-то нету

понабрали по объявлению..

(96) У кого оно тут есть?

(94) это тебе пошло, а ему нормально

100

открываю БП 3.0, общие модули - ...
куча однотипных с разными суфиксами, типа такого:

ДополнительныеОтчетыИОбработки
ДополнительныеОтчетыИОбработкиВМоделиСервиса
ДополнительныеОтчетыИОбработкиКлиент
ДополнительныеОтчетыИОбработкиКлиентСервер
ДополнительныеОтчетыИОбработкиПереопределяемый
ДополнительныеОтчетыИОбработкиСобытия

они бы придумали как их объединять

нет, ООП тут не родить!

(0) Вообще не вижу никаких проблем с так называемой "сложностью" устройства восьмёрки. Наоборот, с течением времени код становится всё лучше и лучше, растёт универсальность.

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

(0) Абсолютно согласен
А также например в УТ 11 предеают вместо именованных парамеров структуры.

Во сколько строк кода выливается расчет например суммы ндс по строке при програмном запонении.
Зато б..ть одна процедура
ОбработкаТабличнойЧастиКлиент.ОбработатьСтрокуТЧ(ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения);

Функция ИмяТипаДокументы() Экспорт
   
   Возврат "Документы";
   
КонецФункции

(0) всё нормально, просто ты клюшкодав

(68) Да нефига она производительнее не стало. Яркий пример новая парадигма формирование отчетов в БП 3.0 через вызов фоновых задач. Да при этом теоретически каждая такая фоновая задача может использовать отдельное ядро процессора, вот только при этом производительность (время формирования отчета) упало в 2-3 раза. Зато как круто, теперь любой менеджер может уложить сервак запустив в своей сесии пару десятков огромных отчетов. Ведь раньше 1С это не позволяло, зато теперь смотрите как круто

(0) потому что типовые пишут студенты за тарелку супа, они же ТС и критикуют :)

(106) А с чего это время выполнения отчета падает?
Сервак положить можно было и раньше обычной карточкой счета или анализом продаж.

(108) тьфу... время растет

в ДОСовские времена я вычитал где-то,что средний прогер в голове держит объем примерно 7 экранов текста. Потому модульность позволяет закрывать нижние уровни и по дереву проекта ползти вверх. Плюс наверное коллективная разработка позволяет справляться с усложняющимися проектами. Вот только с запросами так красиво не получается. И как их генерят я ума не приложу, особливо те которые из нескольких тыщ строк.
И чего пенять на читабельность кода в 1С, если выходные модули у того же JS напоминают бред сумашедшего с null-читабельностью.

Резюме: возрастающая сложность текстов модулей  - следствие коллективной разработки -  и ее результатом будет отбрасывание одиночек с рынка услуг 1С-программистов, оставляя в нем только центры разработки от фирмы 1С ;))))))

Я конечно дико извиняюсь, но те кто пишет свои доработки на основе общих процедур/функций, неужели так трудно создать свой общий модуль, скопировать туда эти процедуры/функции и писать свои доработки на их основе? Обновлять конфу тоже никаких проблем в этом случае.

(110) Т.е. запросы на несколько тыщ строк пишут коллективом? А набивает текст секретарша?

(112) я этого не утверждал - потому как не знаю, что явно и написал: << И как их генерят я ума не приложу,>>

(0) Ты всегда можешь отказаться от типовых решений и писАть свои - в которых не будет сотни тысяч строк кода, в которых все будет красиво и изящно - решения которые тебе будет приятно писАть\читать\сопровождать. Для этого совсем не обязательно переходить на шарп.

(114) лукавишь)))
сложность кода увеличивается пропорционально количеству выходящих НПА , НПД от минГосДоходов, от Налоговых Комитетов.
Ибо в наших государствах бухучет и налоговый учет имеют тенденцию к бесконечному маразматическому усложнению