0. 1c-intelligence 10075 19.06.20 10:00 Сейчас в теме

Правила жёлтого напильника

Как вносить изменения в типовые конфигурации при решении задач. Материал дополняется, подписывайтесь.

Перейти к публикации

Комментарии
Избранное Подписка Сортировка: Древо развёрнутое
Свернуть все
1. Rustig 1476 19.06.20 10:16 Сейчас в теме
Не забудьте в процедуре обработки проведения, которую пишете, проверить в начале на Источник.ОбменДанными.Загрузка, чтобы не формировать движения для объекта, прилетевшего с обменом.


Конструкция кода вида:

Документ.ОбменДанными.Загрузка = Истина;
Документ.Записать(РежимЗаписиДокумента.Проведение);

вызывает исключение! поскольку проводить в режиме обмена нельзя

Поэтому вопрос: как понять вашу рекомендацию?

В типовых ни разу не видел, чтобы в процедуре проведения стояла такая проверка.
echo77; байт; awk; +3 Ответить
2. Drivingblind 122 19.06.20 10:21 Сейчас в теме
(1) много где так.
Вот пример из модуля документа ПриобретениеТоваровУслуг в ERP:
Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
	
	Если ОбменДанными.Загрузка Тогда
		Возврат;
	КонецЕсли;
<.....>
КонецПроцедуры

вот статья по этому вопросу на ИТС: https://its.1c.ru/db/v8std#content:773:hdoc
3. Rustig 1476 19.06.20 10:37 Сейчас в теме
(2) Дривинблинд, читайте внимательно публикацию и комменты
pavlov_dv; Andreeei; Fox-trot; +3 Ответить
7. Drivingblind 122 19.06.20 10:52 Сейчас в теме
(3) извиняюсь. Поторопился
9. Rustig 1476 19.06.20 10:57 Сейчас в теме
4. 1c-intelligence 10075 19.06.20 10:41 Сейчас в теме
(1) да, вы правы, не обратил на это внимание, что такая проверка перед/при записи делаться должна. Исправлю.
5. Rustig 1476 19.06.20 10:43 Сейчас в теме
(4) у вас тут новосибирская поддержка? не глядя, заступаются :)
6. 1c-intelligence 10075 19.06.20 10:47 Сейчас в теме
(5) а я не знаю, что такое новосибирская поддержка.
8. Rustig 1476 19.06.20 10:57 Сейчас в теме
(6) :) ладно, проехали)))
(7) все нормуль :)
37. &rew 21 22.06.20 07:11 Сейчас в теме
(6)"Я свидетель! Что случилось?"
40. ILM 238 22.06.20 09:41 Сейчас в теме
(6) Нас надо знать в лицо. Приедете в Новосибирск, Вас поддержат!
17. json 2647 19.06.20 13:47 Сейчас в теме
(1) вот так надо делать при обмене, чтобы не было ошибки:

Документ.ОбменДанными.Загрузка = Истина;
Документ.Проведен = Источник.Проведен;
Документ.Записать(РежимЗаписиДокумента.Запись);


А движения приходят отдельным потоком
i.s.o; vdscom; +2 Ответить
19. Rustig 1476 19.06.20 14:01 Сейчас в теме
(17) 1) во второй строке лишнее слово ОбменДанными, а то получается что у свойства ОбменДанными есть свойство Проведен....
2) при обмене поле Документ.Проведен чаще всего равен автоматом полю Источник.Проведен. Это зависит от правил обмена, и в правилах регулируется. Дополнительно прописывать такую конструкцию мне кажется не надо.
3) в процедуре ПередЗаписью нет переменной Источник. Поэтому будет синтаксическая ошибка.

Для разных конфигураций движения отличаются, например для обмена УТ-БП....
Отдельным потоком не представляю по каким правилам они приходят.
Мне кажется проще провести документ отдельной командой, если он проведенный, тогда он сам сделает все нужные движения.
20. json 2647 19.06.20 14:16 Сейчас в теме
(19)
1. Исправил
3. Это прописывается в правилах обмена, а не в процедуре ПередЗаписью(). В типовых правилах есть переменная Источник, из которой заполняется объект

Если конфигурация идентичная и это просто узлы одной системы, то движения могут ходить.
Если конфигурации разные, то тогда обычно проведение выполняется отдельным регл. заданием. А документы для проведения помещаются в регистр, по которому работает это регл. задание
10. Synoecium 693 19.06.20 11:24 Сейчас в теме
неплохо, но тема слабо раскрыта.
1) Изменение ролей - если вам приходится менять типовые роли, вы свернули не туда. Сделайте лучше дополнительную роль с доступом к новым объектам (можно даже к типовым объектам, но лучше не надо). Копировать типовую роль и добавлять туда новые объекты тоже плохой тон
2) Добавление предопределенных значений - лучше в типовые объекты их не добавлять, велик риск потерять при обновлении. Сделайте лучше отдельный справочник предопределенных значений с значением любого типа и допиливайте его себе на здоровье. Идиот будет счастлив
3) Изменение элементов/реквизитов форм. Вообще, на сегодняшний день, я считаю что все изменения форм в типовых конфигурациях на УФ должны выполняться программно. Для этого есть переопределямые модули в современных конфигурациях, а в тех, что попроще, такие модули можно добавить 1 раз и пользоваться всю жизнь. Идиот конечно будет сильно озадачен как оно так все происходит, но после первого обновления скажет вам спасибо
4) Насчет изменения запросов, рекомендую попробовать новый объект СхемаЗапроса. С его помощью можно гораздо меньше зависеть от структуры и типовых изменений исходного запроса. Добавление полей, например, делается парой строчек. Еще парой строчек кода можно присобачить левым соединением какой-нибудь регистр сведений с нужными данными. На поля и таблицы из схемы можно опираться в своем алгоритме и прописать разные ветки условий и т.д. Для идиота это будет выглядеть сложно, но ему в любом случае будет сложно, зато мы получим некоторую устойчивость доработки к изменениям. Кстати, через схему запроса можно также дорабатывать запрос из динамического списка, что немаловажно, так как доступа к тексту запроса в модулях нет.
5) Изменение определяемых типов - лучше их не изменять. Опять же высок риск потерять изменения при обновлении, к тому же можно неявно расширить тип какого-нибудь регистратора или измерения в регистре, что может вылиться в проблемы схожие с "Добавление чего-нибудь в регистры накопления"
байт; Darklight; mip128; Rustig; +4 Ответить
11. 1c-intelligence 10075 19.06.20 11:27 Сейчас в теме
(10) до этого еще руки не дошли просто.
15. ipoloskov 120 19.06.20 12:34 Сейчас в теме
(10)
Изменение определяемых типов - лучше их не изменять. Опять же высок риск потерять изменения при обновлении

Я разработал методику, как обезопасить себя от потери данных: https://infostart.ru/public/1227685/
Изменять приходится, например, чтобы добавить присоединенные файлы к своим объектам.
21. Darklight 22 19.06.20 17:07 Сейчас в теме
(10)Плюсую, но:
4) Насколько я знаю "СхемаЗапроса" - та ещё дрянь (пробовал пользоваться пару лет назад - больше не хочу, может что-то, конечно, сейчас изменилось - не знаю - скажите коли стало лучше) - у данного инструмента три фундаментальные проблемы:
1. Очень ограниченный API на изменения - банально даже поиска нормального даже в линейном списке нет, не говоря уже о поиске нужной точки изменения во всём запрос - от того конструкции работы с этим объектом просто монструозны - с кучей вложенных циклов; и даже если создавать свой хелперский API - всё равно всё - банальные операции выливаются в десятки строк кода (и сотни-тысячи строк в хелперском кустарном API). В 98% гораздо проще просто обработать текст банальными текстовым функциями. А надёжность - да почти не пострадает (будет на уровне 50% в обоих случаях) - тут просто проблемы уже глубже лежат - внутри самого синтаксиса запросов.

2. Работать можно только очень строго последовательно - т.е. если надо добавить поле - то нужно сначала добавить источник этого поля (если его нет), а чтобы его добавить - нужно добавить все прочие источники, от которых он зависит, и настроить соединения. А когда доходит до временных таблиц - так вообще просто жесть какая-то при работе выходит. Шаг влево - шаг в право - и всё - сразу ошибка при вызове метода. От того вносить правки в запросы - ОЧЕНЬ сложно и громоздко - приходится думать минимум на три шага вперёд и "бегать" по всему API данного объекта и его производных. От того код модификации получается крайне запутанным и трудно воспринимаемым. Ну, а если исходный запрос вообще ещё требует постобработки (да хотя бы банальной сборки из нескольких частей-подзапросов и временных таблиц, а в конфигурациях такое бывает частенько) - то в схему его либо вообще не загрузить, либо если и загрузить - то по выходу потеряются все "управляющие комментарии" (или "фигурные" расширения языка запросов - да хоть для СКД).

3. Доступность: "Сервер, толстый клиент, внешнее соединение". Может не так уж принципиально, но порой тексты запросов формируются на клиенте, а потом только передаются на сервер для выполнения (или устанавливаются в интерактивные объекты)

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

5) ОпределяемыеТипы штука очень мощная, но криво сделанная (особенно в расширениях). Их применение в конфигурации - большое благо (могло бы быть) - как раз из-за возможности в едином месте настраивать тип общего назначения, и потом везде его применять. И 1С идёт таким путём. И чтобы расширить это назначение своими типами - гораздо надёжнее внести их именно в определяемый тип, чем лезть в реквизиты, где он используется, проконтролировать (и объединить) опредлеляемый тип при обновлении куда менее рисковано, чем контролировать все места его применения (которые могут прибавляться/убавляться)
12. pm74 169 19.06.20 11:27 Сейчас в теме
боянчик конечно , но с юмором и читается легко поэтому +
Принципиально есть три варианта внесения изменений: закомментировать типовой запрос и написать свой, внести точечные маркированные изменения в типовой, подменить типовой своим
четвертый - через схему запроса
13. ipoloskov 120 19.06.20 12:21 Сейчас в теме
Чтобы у идиота был доступ к реестру задач, нужно вести этот реестр в самой конфигурации (в расширении). Например, в общем модуле __ОписаниеИзмененийКонфигурации
davdykin; mvxyz; Rustig; +3 Ответить
14. awk 714 19.06.20 12:21 Сейчас в теме
Отсутствие префикса обычно говорит либо о беспросветной тупости, либо о перетаскивании объекта из другой типовой конфигурации, либо о том, что программисту стыдно за этот объект.


Есть еще вариант. Мы работаем забегая вперед и знаем, что 1С создаст такой же объект (рано или поздно). Что бы это вовремя засечь и не плодить сущности, процитирую вас:

Сначала стандартная рекомендация: убедитесь, что объекта, который вы хотите добавить, в типовой нет. Не по названию, а по назначению. Если конфигурация незнакомая, спросите у того, кто в ней шарит.


Правда - это крайне редкий случай. 99,99% случаев проще (да и нужно) ставить префикс.
16. pm74 169 19.06.20 13:31 Сейчас в теме
есть еще один класс задач по доработке (про который ничего не сказано)
требующий отдельной главы в методичке . Когда нужно добавить функциональности отдельному сегменту чего либо.
пример на скрине
Прикрепленные файлы:
25. muskul 20.06.20 04:37 Сейчас в теме
(16)разные виды номенклатуры со своим учетом по характеристикам? не?
29. pm74 169 20.06.20 10:11 Сейчас в теме
(25) уже настроены , в данном случае требуется сделать выбор вида характеристики обязательным в частном случае
32. AntonSm 27 20.06.20 16:10 Сейчас в теме
33. pm74 169 20.06.20 18:54 Сейчас в теме
(32) спасибо , мне помощь не требуется
Я говорю про общий класс задач (очень частых кстати), для решения которых применяется несколько общераспространенных методов, начиная от "НайтиПоКоду" , заканчивая приведенным вами способом. И раз уж речь идет о методичке для " стажеров и программистов" , то недурно бы дополнить для обсуждения.
18. dandykry 5 19.06.20 14:01 Сейчас в теме
Еще раз повторю: если вы хотите внести изменения в типовой запрос, то вы что-то делаете не так.


Либо разработчики КА/УТ/ЕРП что-то делают не так уже несколько лет.
К примеру в предпоследнем релизе ЕРП при печати нескольких Коммерческих предложений, все печаталось как 1 большой документ.

Тема хорошая. К примеру, у нас есть отдельные правила по маркировке исправлений косяков от 1с )
22. oleganatolievich 145 19.06.20 20:47 Сейчас в теме
1. Для кого делаются доработки
Про идиота - зачем эти эмоции лишние? Это уже давно сказано
«Пишите код так, как будто поддерживать его будет склонный к насилию психопат, который знает, где вы живёте» (с) Джон Ф. Вудс.

2. Типы конфигураций.
Это разумеется само собой. Достаточно график обновлений посмотреть.

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

4. Маркировка изменений
Разумеется само собой. Зачем делать заметку об измененном коде без первоначального?

5. Изменение типовых запросов
Если правка ошибки в типовом запросе? Лучше обрабатывать текст запроса после его объявления, а не править это объявление.

6. Добавление новых ссылочных объектов
Обычно новая подсистема, и конечно нужно делать какое-то исследование конфигурации, чтобы не плодить сущности. Это очевидно.

7. Добавление чего-нибудь в регистры накопления
Уж тем более надо провести исследование, поиск ссылок на объект, прежде чем что-то трогать в таблице, которая может оказаться огромной. За названия ресурсов ИмяРесурсаX надо лишать премии.

8. Добавление нового регистра накопления или регистра сведений, подчиненного регистратору

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

Много букв. Основная мысль, которая заграфоманена в статье - "не лезь в типовую. а если лезешь, то сделай анализ изменений, и добавляй чаще, чем изменяй".
xantif_2000; aegoncharov; +2 Ответить
27. aegoncharov 20.06.20 09:46 Сейчас в теме
(22) Поддержу по п.3 про префиксы. Вопрос неоднозначный.
Особенно что касается безапелляционной рекомендации:

"Для франча префикс должен коррелировать с названием компании или бренда (типа «бит», «сс» и т.д.).
Для завода вынужден рекомендовать какой-нибудь префикс, коррелирующий с названием организации. "


Если каждый программист начнет делать свои префиксы в зависимости от места своего трудоустройства, то без слез на конфигурацию сложно будет смотреть. То же касается и "местячковых" префиксов предприятий.
Во-первых, у владельца конфигурации, по хорошему, должна быть некоторая концепция префиксации при доработках, которой следует придерживаться всем приходящим разработчикам. Если ее нету - то внешний разработчик может предложить ее.
Во-вторых, я считаю, что префиксация в большинстве случаев должна коррелировать с самим прикладным смыслом доработки.
Если вносится какая-то универсальная подсистема, например, какой-нибудь "Контроль доступа к данным", состоящая их нескольких модулей, регистров, справочников, то этим объектам вполне удобно будет дать префикс, какой-нибудь "КДД_".
Если вносится какая-то отраслевая доработка/подсистема, то можно дать "отраслевой" префикс, например, ХБКП (хлебобулочно-кондитерское производство).
Очевидный плюс в таком подходе - эти доработки проще переносить на другие предприятия (если сравнивать с префиксацией по наименованию предприятия, которое вообще может поменяться).
Если вносятся изменения непосредственно в типовую функциональность, то тут, вероятно, вообще лучше придерживаться стандартов наименований объектов и реквизитов самой типовой конфигурации. Многие алгоритмы по обработке данных используют совпадение наименований реквизитов в зависимости от их содержания. Если есть реквизит "Контрагент", хоть типовой, хоть добавленный, уже из наименования ясно что в нем.

Да, есть проблема, когда в конфигурацию добавляют свой документ/реквизит, а потом 1С делает свой с таким же наименованием, ее надо иметь ввиду.
JohnyDeath; Infector; +2 Ответить
28. oleganatolievich 145 20.06.20 09:50 Сейчас в теме
(27)
Если каждый программист начнет делать свои префиксы в зависимости от места своего трудоустройства, то без слез на конфигурацию сложно будет смотреть.

да, согласен. видел много таких поделок.
жаль, в 1С нету аналога пакетов из Java, которые ограничивают пространство имен.
23. Labotamy 19.06.20 21:28 Сейчас в теме
Объясните плз беспросветному тупому трусу нафига префикс?
sashocq; oleganatolievich; +2 Ответить
30. davdykin 24 20.06.20 13:58 Сейчас в теме
(23) Префиксы на самом деле очень удобны:
1. Можно найти все функции в модуле, какие ты добавлял, редактировал и т.д.
2. Вы видите реквизит в конфе, которого нет в поставке, что это, артефакт от прошлого кривого обновления, дописанный реквизит? По префиксу сразу видно. Да и искать такие реквизиты среди 20-30 стандартных - значительно проще.
3. Ну.. автодополниение тоже удобно, доработки в основном все скидываю в один модуль, т.к. не удобно под 2-3 процедуры делать отдельный модуль, выделяешь префиксом ДоработкаПравил_, ДоработкаОбмена и т.д., очень удобно
24. genayo 19.06.20 22:48 Сейчас в теме
А так-то, лучше во франче не работать :))
31. davdykin 24 20.06.20 13:59 Сейчас в теме
(24)По-моему для "начала" работы самое то:
1. Поработаете с разными задачами
2. Если франч путевый - посмотрите стандарты работы, это сильно помогает в дальнейшем
3. Очень большой плюс - обмен опытом.
34. genayo 20.06.20 20:38 Сейчас в теме
(31) Вот именно, если франч путёвый. А их, путёвых, не так уж и много.
35. davdykin 24 21.06.20 05:09 Сейчас в теме
(34)Даже не путевый франч, опыта вам даст больше )). Хотя сейчас франчи мне кажется кроме как "проехать по ушам какая крутая штука ИТС", на большее не способны
52. genayo 24.06.20 08:26 Сейчас в теме
(35) Я тут дорабатывал одну подсистему "от франча" - проклял всё, проще было самому с нуля написать. Нахрен такой опыт по велосипедостроению с квадратными колёсами.
56. davdykin 24 28.06.20 10:46 Сейчас в теме
(52) Ну вообще очень странно, вы по одному случаю делаете обобщающие выводы.. вы думаете те кто не во франче - сразу пилять чистый, красивый код?
59. genayo 29.06.20 13:54 Сейчас в теме
(56) Это не один случай, это просто свежий пример. Конечно, не все сразу пишут качественный код, но во многих мелких (и не очень :( ) франчах, чтобы заработать, надо быстро писать код, который хоть как-то работает, чтобы быть принятым заказчиком. А про дальнейшую доработку и поддержку думать как-то не принято...
60. davdykin 24 29.06.20 18:12 Сейчас в теме
(59)Не знаю, я всю жизнь во франче работал и работаю, и как-то стараюсь не писать работающий говнокод, потому что клиенты потом в основном обращаются к нам же за поддержкой, зачем мне создавать себе лишнюю работу... да и как-то стыдно будет, если "следующие" ребята обслуживающие увидят твои грабли
26. z86 55 20.06.20 08:23 Сейчас в теме
А мне больше нравится суфиксы в новых объектах: когда что-то пишешь то по логике можно написать Номенклатура_сд чем чих_номенклатура. Также в комментариях пишем префикс но : "//с.д. рижий 2020-06-19" потому что подобрать префикс из 2-3 бук который не повторяется в тексте очень сложно. Ище есть небольшая рекомендация - когда пишем свои функции и переменные в тексте то начинаем с префикса "сд_" или просто "_", и обязательно коменты
36. JohnyDeath 297 21.06.20 10:38 Сейчас в теме
Префиксы - зло!
Даешь постфиксы!
48. 1c-intelligence 10075 23.06.20 22:35 Сейчас в теме
(36) я вот честно не понимаю, чем постфиксы лучше.
Мыслю в стандартном контексте: вносим не очень много изменений в типовую, т.е. наиболее распространённая ситуация для франча. Допустим, 3 справочника, 1 документ, 5 регистров сведений, ну и по мелочи - роли там, подписки.

Преимущества префикса:
1. Визуально в списке объектов МД их лучше видно, т.к. по левому краю они одинаковы (а список объектов прижат влево);
2. Если кто-то решит отсортировать список МД, то все добавленные объекты останутся рядом друг с другом, не разбегутся по списку (как объекты с постфиксами);
3. В контекстной подсказке достаточно набрать префикс, и тут же под курсором окажется весь наш небольшой набор. С постфиксами так не получится - контекстная подсказка по подстроке не ищет.

В остальном всё одинаково. Поиск в дереве метаданных одинаков для префиксов и постфиксов.

Объясните?
53. JohnyDeath 297 24.06.20 09:12 Сейчас в теме
(48) Те самый плюсы, которые ты описываешь для префиксов, являются для меня минусами )
Если кто-то добавил справочник "ПунктыПогрузкиВыгрузки" или общий модуль "КоннекторХТТП", то я хочу в подсказке видеть их именно по "пункты..." или "кон.." и не вспоминать о том, какой- же у них был префикс. Я работал в конфигурации, над которой трудилось куча франчей. И вот такое правило с префиксами у заказчика было обязательным требованием при приемке работ. Так вот там найти что-то внятное было очень сложно, отсюда росли еще одни грабли, о которых ты здесь также писал: некоторые модули ил даже справочники просто-напросто дублировали друг друга только потому, что разработчик одного франча не нашел похожего объекта/модуля другого франча.

По преимуществам префиксов из списка:
1. Визуально в списке объектов МД их лучше видно, т.к. по левому краю они одинаковы (а список объектов прижат влево);

Зачем их видеть визуально в списке МД? В предприятии, надеюсь, они отображаются без префиксов? И ничего, пользователи знают и любят названия без префиксов. А чем мы хуже?
2. Если кто-то решит отсортировать список МД, то все добавленные объекты останутся рядом друг с другом, не разбегутся по списку (как объекты с постфиксами);

Так это же наоборот плюс постфиксам. Справочник "КонтрагентыПрисоединенныеФайлы_бит" я хотел бы видеть рядом со справочником "Контрагенты", и не пытаться искать его по "бит_Контрагент", "кд_Контрагенты", "вз_Контрагенты"...
3. В контекстной подсказке достаточно набрать префикс, и тут же под курсором окажется весь наш небольшой набор. С постфиксами так не получится - контекстная подсказка по подстроке не ищет.

Это если ты знаешь какой префикс и если он у тебя один на конфигурацию. Но думаю, что нужно-таки начинать набирать код отталкиваясь от смысла "ОбщегоНазначения..", "Контрагенты..", "РаботаСФайлами..", чем вспоминать создателя этого ОМ/Справочника

Очень много отраслевых решений, построенных на типовых конфигурациях, имеют в своих правилах "префиксы". И когда они доходят до клиентов, то уже на местах начинают добавлять свои префиксы. Т.е. уже на старте имеем 2 префикса.
54. 1c-intelligence 10075 24.06.20 11:34 Сейчас в теме
(53) похоже, это все-таки дело вкуса. Как квас и кефир.
55. JohnyDeath 297 24.06.20 12:58 Сейчас в теме
(54) Можно еще посмотреть на типовые конфигурации и их Общие модули. Например "ОбщегоНазначения" и его "дети" в бухгалтерии: ОбщегоНазначенияБП, ОбщегоНазначенияБРО, ОбщегоНазначенияБТС, ОбщегоНазначенияЭДКО
Если бы разработчики каждой из этих подсистем (модулей) следовал правилу префиксов, то мы бы заимели "БП_ОбщегоНазначения" и т.п. Использовать такие ОМ крайне неудобно.
Но это лично мое мнение, никому его не навязываю. Просто с лихвой хлебанул этих префиксов у трех разных клиентов, где трудилась армия разных групп франчей. И их сортировка в дереве метаданных по префиксу, а не по смыслу только напрягает. Про контекстную подсказку можно просто забыть
38. skillman 22.06.20 07:33 Сейчас в теме
Как эта тема сейчас стала популярна!
Прям раньше жили без этого теперь опомнились или наелись обновлять типовые релизы ,которые кто-то поменял!?
39. &rew 21 22.06.20 07:47 Сейчас в теме
(38)Да нет. Просто сейчас дорабатывать типовые конфы стало сложнее. Много скрытых зависимостей. Изменились требования к аппаратной части. И если писать "за ПИСОТ рублей", то вместо базы можно в недалеком будущем получить "мертвяка". У меня так товарищ"алкашку" УТ восстанавливал после таких деятелей. Весь учет угробили. Самого бог миловал пока.
41. Mechanik21 20 23.06.20 17:53 Сейчас в теме
Не по теме: подскажите, что за классическое письмо было упомянуто в Корпоративном Ламанчском о верности работников? Я его тогда сразу нашёл и прочитал, а теперь вспомнить не могу, а случай такой, что дословно процитировать хочется)
42. 1c-intelligence 10075 23.06.20 18:10 Сейчас в теме
47. Mechanik21 20 23.06.20 21:33 Сейчас в теме
43. German 873 23.06.20 20:04 Сейчас в теме
Начал за здравие, а закончил...

Начал читать, понравилось/зацепило деление на типы конфигураций, отложил, потом выкроил свободный вечерок на чтение статьи..
А дальше хоть не читай:
Префиксы - редуцент из тех времен когда в конфигураторе не было поиска по части строки, представьте что у вас будет с конфой когда у вас работает 10 или 20 компаний подрядчиков, не удивительно что они потом у вас "ТипыЦен найти не могут"..
Внешние отчеты/обработки/заполнения в типовых - ахахаха

Мой вердикт "правила" для коллектива "мы с Тамарой пилим парой" - до 3-4 разрабов в одной полумертвой конфигурации.
Для современных с коллективом более 30 специалистов, просто запрещены к использованию. Поэтому жирный минус.

Что бы не быть голословным подготовлю к публикации наш правила/регламент которой ковался кровью в больших коллективах и современных конфигурациях
44. 1c-intelligence 10075 23.06.20 20:13 Сейчас в теме
(43) а расскажете, чем могут 30 человек одновременно заниматься в одном проекте по доработке типовой конфигурации? Правда интересно.
45. German 873 23.06.20 20:32 Сейчас в теме
(44) как вы себе представляете этот рассказ? Если вы ставите под сомнение необходимость такого огромного числа ресурсов, то могу лишь сказать, что их по факту было 2 раза больше, а дальше вопрос объема данных и масштабов компании и стоящих задач.
46. 1c-intelligence 10075 23.06.20 20:47 Сейчас в теме
(45) нет, не ставлю под сомнение, правда интересно.
Если это фуллтайм и франч, то это 10 млн. в месяц.
Если это внутренняя команда, и все разрабы, то они именно типовую дорабатывают? Ну и это всё равно 5 тыс. ч/часов в месяц - столько стоит хороший проект внедрения erp, но там не только разработка.
Если это разработка, а не доработка, то там, вроде, другие правила нужны.
49. BabySG 23.06.20 22:45 Сейчас в теме
(46) пилили овердофига. И не один франч, их было иногда 10+. Ну а детали может Герман рассказать (ему пофиг на NDA, а мне нет :) )
Разработчиков, действительно, было меньше. Но важно понимать, что может быть разработчик, который раз в месяц вносит изменение (например, это эксперт и занимается производительностью) - но от этого требования к соблюдению правил не меняются.
PS. Кстати, изначально Герман не был настроен так против внешних обработок )
50. 1c-intelligence 10075 23.06.20 22:56 Сейчас в теме
(49) ну я подожду, чё.

Я встречал людей, которые все печатные формы всех документов УПП рисовали в модуле объекта. Вроде у них было какое-то объяснение даже, но я уже не помню, какое. Интересно ваше послушать.

Просто может оказаться, что вы (или он) опишете, как обстоят дела в 0.01% ситуаций - меня тоже часто в этом упрекают, говорят, что это синдром выжившего.

А так, мне правда интересно. Например, почему Герман назвал современной конфигурацию, в которую надо вносить бешеное количество доработок. А полумертвой - ту, в которую не надо. Весь мой опыт говорит об обратном.

В общем, жду интересного рассказа.
51. genayo 24.06.20 08:24 Сейчас в теме
(50) "Уж полночь близится, а Германа всё нет" :)
57. Tavalik 2300 29.06.20 05:57 Сейчас в теме
Вы уж, Иван, извините, но вода водянистая. А на методичку для стажеров и подавно не тянет.

Прикреплю наши правила разработки, может вам пригодятся: https://infostart.ru/public/647048/
58. 1c-intelligence 10075 29.06.20 08:43 Сейчас в теме
(57) у вас хорошо написано, но не всё объяснено - стажеры не сдадут мне экзамен, если не смогут объяснить, почему именно так надо вносить изменения.
Ну и не про все виды изменений написано. Например, ничего нет про регистры.
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

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

Программист 1С
Санкт-Петербург
зарплата до 150 000 руб.
Полный день

Программист 1С
Екатеринбург
зарплата от 80 000 руб. до 130 000 руб.
Полный день

Ведущий программист 1С
Москва
зарплата от 150 000 руб.
Полный день

Ведущий программист 1С (УТ 11)
Москва
зарплата до 200 000 руб.
Полный день