Всем привет! Есть у меня такой вопрос:

У клиента, с которым я сейчас работаю, периодически проходит аудит от сторонней конторы, с целью проверки, правильно ли ведется учет, как ведется разработка на 1с и тп... И вот, аудиторы посмотрев в конфигураторе на мой код, выкатили мне претензии, что я типо не правильно веду разработку - не использую расширения, сделал самописный обмен с БП через ком-интерфейс и тп. При это все что я сделал работает на ура, у пользователей претензий нет, им даже нравится. Я им сказал пойти погулять, но неприятный осадок остался. И возник вопрос - можно ли на самом деле обвинить программиста в том, что он не следует стандартам 1С (Например тем, которые указаны тут: https://its.1c.ru/db/v8std), при условии, что все сделанное работает правильно? Обязательны ли все эти стандарты к использованию, или это просто набор рекомендаций?

(0) Ресстрелять!

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

>>сделал самописный обмен с БП через ком-интерфейс

боже, зачем ???

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

(0) Это больше к риск-менеджменту относится, чем к качеству разработки.

Кодекс — это просто свод указаний, а не жестких законов(с)

(3) Так надо, мой друг :)

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

(4) Тех. документацию я веду.

(2) Ага, было дело - программистка до меня написала свою конвертацию данных, только на dbf файлах... Было весело...

(7) та не самописный это гуд, зачем ком ? А вдруг линукс наступит ?

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

+ (11) давай быстренько на веб-сервисы и они скажут что модномолодежно )

(12) Так это... через КД тоже так можно настроить...

(12) А что нельзя настроить...

(2) Типовой обмен там не подходил. Откроет конфигуратор - разберется. Разобраться в коде ком-интерфейса намного проще чем анализировать правила обмена.

(16) Ком - устаревшее говно мамонта, которое даже майкрософт похоронил.

(16) не согласен. все как раз наоборот

переделать на КД+вебсервис

(16) базы типовые, бсп? Тогда обязан следовать парадигме 1с в обменах тоже

много умных вещей. код по стандартам приятнее дорабатывать.

Скорее да. Но не всегда, но скорее ДА

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

(23) Если простенькие

(0) Если конфа сильно переписано , тогда расширения только во вред , иначе стоит применять. если работает все на ура пошли они в ж.. . По ком соединению обмен конечно трабл, а вот то что обмен самописный плюс, например при одном обновлении правил слетела кассовая книга, в следующем обновлении правил 1С ошибку исправила

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

(18) Наоборот это будет: Майкрософт его похоронил, потому что это устаревшее говно мамонта. Все врено.

(23) дело в том, дорогой друг, что ты так изучаешь ТЕХНОЛОГИЮ. Да, в этой конторе ты с нуля "навелосипедил" но в другой тебя ждет отлаженный/допиленный обмен на ED и вот тут ты вспомнишь советы ветки...

(26) Даже если использование стандартов в итоге выливается в неудобные решения и переусложненную поддрежку?)

(28) Использую там свой самописный, только доделанный под нового клиента, давно так делаю. отлично все у всех работает, мне даже спасибо говорят :)

Типовые обмены от 1С я давно вспоминаю как страшный сон))

(0) Ох, как мне эти аудиторы надоели... Два раза в год проверяют.
Значит так.
Аудиторы могут проверять только соответствие чего ни будь, чему ни будь. Так же могут давать только рекомендации. Все остальное ерунда на постном масле.

Теперь вопрос!

С чего аудиторы решили что код разработанный в организации должен соответствовать стандартам 1С? Есть ли в организации документ который обязывает внешних и внутренних разработчиков при разработке руководствоваться стандартом от 1С? Если такой документ есть и тебя с ним ознакомили, то аудиторы правы. Если такого документа нет, то они могут только рекомендовать придерживаться данного стандарта. При этом решение о соблюдении стандарта должно принимать руководство, т.к. это дополнительные затраты как на обучение специалистов, так и на контроль качества кода. Оно руководству надо?
Это с точки зрения бизнеса.

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

Смешали в кучу стандарты разработки и варианты реализации задачи

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

(2) стандарты часто меняются. Так что следующий программист может и понять твой коде, который писался по стандартам 10-летней давности

(0) > можно ли на самом деле обвинить программиста в том, что он не следует стандартам 1С

Можно обвинить программиста, а можно обвинить обвинителей программиста – прав будет тот, у кого больше прав!

Если у аудиторов ПО 1С (странно, как вообще такие личности появились, пусть лучше стандартизируют процесс внедрения 1С, если делать нечего) прав больше, то пусть сами и программируют (а может быть это и есть их цель – забрать клиента себе на поддержку?). А вообще-то, по-видимому, стоит в договорах заключать право на «свободу творчества», я например, везде декларирую, что программирую по принципу «1С:Несовместимо». Скоро, наверное, уже и без официальных корочек не будут допускать к работе с 1С. Все это явно следствие переизбытка кадров на рынке услуг 1С. В крайнем случае, всегда можно поменять свою бизнес модель поведения. Например, программировать бесплатные, на определенный период, скажем, год, собственные конфигурации. Меня этот вариант вполне устраивает. Кому понравятся мои конфы, купят (за символические деньги) продление еще на год или более, а кому нет, то использовать не будут либо будут ломать защиту, что тоже неплохо. Плохое или неинтересное взламывать не будут, раз ломают, значит, продукт небесполезен. А как это использовать в своих целях это уже другой вопрос.

(8) что значит не айс, если во всех типовых обмен через ком это первый пункт варианта обмена?

(30)
>>У клиента, с которым я сейчас работаю, периодически проходит аудит от сторонней конторы

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

(19) Какой вариант события более реалистичен?
1. У клиента стоит линукс и ком не работает
2. У клиента файловая версия и нет апачи

Мне почему то кажется что второй вариант на 2 порядка чаще встречается, чем первый

(39) когда он сравнит производительность - поставит апачи )

(40)Сказано же, что всё работает и всё устраивает...

(40) Кто ему даст ставить апачи?

Мля покажите мне стандарт от 1С, который говорит, что нужно везде совать расширения?

С этими расширениями все бнулись, сори

Возьмем, например, вот это правило https://its.1c.ru/db/v8std#content:2149184420:hdoc и вот э тот пункт из него:

"Обмены между конфигурациями, использующими Библиотеку стандартных подсистем (БСП), следует делать на основе формата EnterpriseData, разрабатывать новые обмены на основе ПК запрещается."

Означает ли это, что для конфигураций, поддерживающих БСП (как УТ11, с которой я сейчас работаю), обязательно делать обмены на EnterpriseData в любом случае? Или это обязательно, только если я использую КД, а если делаю через ком или самописный - то не обязательно.

(44) +

(43) + тем более в своей нетленки

(0) Мой совет - подрезать себе ЧСВ и посмотреть на ситуацию глазами клиента. Для него нестандартный код и вообще решения — реальный риск. Если ты с ним рассоришься, следующему прогу придется трудно. Либо разбираться в нестандартных решениях и поддерживать их, либо переписывать на стандартные. В любом случае это доп. затраты.

Аудиторы, понятное дело, действуют в интересах клиента.

(44) обколются своими стандартами и суют везде расширения

(48) т.е. допзатраты на следования стандартам мы игнорируем?

(45) у тебя с обеих сторон БСП или УТ11 <-> самописка?

стандарты они такие, сегодня одни, а завтра другие

разрабатывать нужно так, что бы работало. Код писать максимально понятно с необходимыми комментариями. А выбор способа реализации и технологии - прероготива исключительно программиста (или же специального тех специалиста на предприятии)

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

(50) вот именно. Многое можно решить за пару часов и забыть про это на пару лет. Ну а можно завязаться на всякие БСП и подпрыгивать потом при каждом обновлении оного

аудиторы кода, бггг...
хто они такие, и кто их подтвердил их компетенции?

(48) "Для него нестандартный код и вообще решения — реальный риск"

Я вот все не пойму - где тут риск-то? Новый программист конфигуратором пользоваться не умеет? В чем там разбираться - открыл код и читай. 5 минут. В доработках правил обмена тоже надо будет разбираться, а это загрузка/выгрузка в КД, анализ и тп. И, как вишенка на торт, отладка правил обмена. Вы мне хотите сказать, что это проще, чем отладчиком походить по строчкам в обмене, и ту, которая упадет с ошибкой, поправить?

Те, кто говорят, что следуют стандартам — лгут. Абсолютно всем стандартам, изложенным в https://its.1c.ru/db/v8std, не следует даже сама фирма 1С. Где-нибудь, но обязательно ошибёшься, сделаешь не так.

Однако направление в этих стандартах описано верное. По возможности, их конечно стоит придерживаться.

(50) Нет, не игнорируем. На рынке есть X прогов, обученных стандартам 1С, и конкурирующих между собой. И есть один, обученный стандартам имени Nyarlathotep. (Да, и конечно есть 10X лбов, не обученных ничему.) Понятно, что выгоднее придерживаться стандартов 1С.

(23) не верю. дойти отладчиком еще уметь надо. особенно если это ком обмен.
возьми на пример обмен ут103-розница1 через прямое соединение и попробуй отловить момент проведения документа...
а теперь представь что все это еще на упр формах, с выключенным режимом модальности

К примеру я добавляю в типовую свой уникальный документ. Для добалвения печатной формы у меня 2 варианта
1. добавить команду печати непосредственно в сам документ
2. Сделовать стандартам и снять с поддержки кучу глобальных модулей, чтобы прописать мой документ и при каждом обновлении не забыть повторить эти процедуры, только ради того чтобы через 10 лет новый программист "быстрее" въехал в мой код

(59) Мой обмен и обмен "обмен ут103-розница1" - это совсем разные вещи. У меня все прописано явно, проведение - отдельной явной строкой.

(56) скажи боссу чтоб отправил тебя на изучение новых и параллельных технологий  (пока ты буху учетные ошибки помогал исправлять, вышли новые механизмы... те же расширения), объясни(ну если сможешь) , что твой комобмен разрабатывается в 5 раз быстрее, чем на КД
Не нравится - пусть отправит тебя на курсы, а сам на время твоей переподотовки пусть сопли бухам подтирает
Курс Расширения  - 5700 https://xn----1-bedvffifm4g.xn--p1ai/courses/1c-smart-customization/
Курс КД - 9700 https://xn----1-bedvffifm4g.xn--p1ai/data-conv/

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

зато доработка правил, я считаю, проще.мое мнение

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

(56) >5 минут

Лол. Это тебе 5 минут, а мне час. Ты когда-нибудь сталкивался с кодом прожженого семерочника, по нужде пересевшего на восьмерку? Без отступов, без пробелов, переменные с именами от 1 до 5 букв, из коллекций использует только СписокЗначений, и т.д.?

С обменом фишка не в том, что код легче отлаживать. А в том, что написанного тобой кода почти нет, и отлаживать почти нечего.

(65) да и работают ком-обмены как черепахи

(63) Проще ком дорабатывать, так как перед тобой весь код в открытом виде

А вот понять в КД что в какой то ПКС, после определенных событий  есть еще ВыгрузитьПоПравилу() которая подтягивет еще десяток ПКО - это задача не теревиальная даже для мидл 1с-ника.

(67) хз... хз...

особенно бесит в "стандартах" что функции в БСП меняются вплоть до количества обязательных(!) параметров. то есть используя такую функцию не можешь быть уверен, что она при обновлении конфы не выдаст ошибку.

(65) Кода нет если нужно 2 документа между одинаковыми конфами перекинуть.
А ты попробуй без кода в КД написать обмен между 7-кой и 8-кой, да еще при том что нужно несколько документов объединить в один, где то наоборот из одного документа в 7-ке родить 5 разных документов в 8-ке и т.д. и т.п.

Или попробуй с первого раза найти в каком месте при переносе в типовом обмене от 1С заполняется пасмортные данные физлиц, если в ПФД он явно не выгружаются

(65) Я делаю и отступы, и пробелы, и комментарии пишу.

"А в том, что написанного тобой кода почти нет, и отлаживать почти нечего."

Написаны правила обмена, и к ним код, если это в конвертации. И отлаживать их тоже приходится. А явного кода в отладчике нет... И начинается процесс загрузок/выгрузок в кд, чтения журнала регистрации, ловли момента ошибок при обмене и тп.

(60) Ни то и не другое.

Если типовая на БСП, то тебе нужно следовать стандартам:
Использовать расширение и подсистему подключаемых команд.
С версии БСП 2.3.5 (если не путаю) дополнительные отчеты, обработки и печатные формы делаются именно так (через расширение), а не через справочник внешних обработок.
Тогда не придется ломать никакие модули. Единственное изменение в конфе - это наличие твоего нетипового документа.

(17) > Ком - устаревшее … мамонта, которое даже майкрософт похоронил.

С чего вы это взяли? И что M$ предлагает на замену?

На самом деле плох не СОМ или «семерка» или там DDE и Visual FoxPro, которые мешают танцору танцевать, плохо – отсутствие фантазии или ее недостаток. Например, вы не сможете подключиться из 1С77 к самой себе как внутрипроцессному СОМ серверу, только как внепроцессному OLE-серверу (а это новый эксепляр «семерки» в памяти). Но то, что нельзя сделать по каналу СОМ, можно сделать по каналу DDE, который для СОМ является дедушкой. Другими словами, можно организовать внутрипроцессную связь в «семерке» по каналу DDE, которая будет на порядок быстрее, чем внепроцессная OLE-связь. И также на порядок проще в использовании.

(70) с первого раза Ctrl+F в notepad++ по назаванию МД

(74)по XMLке правил

(75) +1

Если это было требованием работодателя.

По правилам именования процедур/функций/реквизитов/перменных обязательно. Любители извращаться с именованием вида КолСтаршСотр (сокращения без причины) или УКП (аббревиатуры которые не являются совсем общепринятыми) или СуммаПрихода (не очевидено что хранит переменная или делает метод) -
задолбали.

(3) >> >>сделал самописный обмен с БП через ком-интерфейс
>> боже, зачем ???
Полагаю из-за скорости.

Если стандарты достаточно хороши, почему бы и нет.
Нужен прагматический подход, а не тотальное следование.

(0) Я бы посадил автора на полгода разбирать чужой код, такого же творца велосипедов. И чтобы код был как в (65). Да, жестоко, но будет шанс, что самсебекодер поймет, ради чего собственно придумали стандарты - пусть кривые и косые и сама 1С их не любит соблюдать (точнее вредители проникают даже в неё). Но между плохим стандартом и вылизанным велосипедом гения - большинство выберет стандарт.

(0) ИМХО, следует максимально следовать стандартам разработки.
Однако всегда есть исключения, и это нормально.

>> не использую расширения, сделал самописный обмен с БП через ком-интерфейс и тп

Тут я не вижу никаких оснований для попадания в категорию исключений.

В работе надо помнить о факторе автобуса. wiki:Фактор_автобуса

Фактор автобуса резко повышается:
Чем дальше твой код от стандартов;
Чем больше ты вносишь изменений в конфигурацию;
Чем больше твои изменения касаются критичных для бизнеса аспектов (модулей, подсистем, разделов учета).

Хозяин базы данных сам должен решать для себя вопрос:
Что важнее - дешевизна и скорость разработки или риск (пусть даже гипотетический), возникающий с привязкой критичной инфраструктуры на одного единственного человека.
Оба варианта вполне допустимы - главное, чтобы работодатель знал об их существовании и понимал возможные последствия.

(80) самописный код на 2 странице намного проще чем типовой код размазанный по 125 процедур 50 общих модулей

(82) Вот вот.

(0) Стандарты необходимы, но как любой инструмент требуют взвешенного подхода, а не слепого следования.

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

(17) > Ком - устаревшее овно мамонта, которое даже майкрософт похоронил.

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

(85) 2 страницы контролировать проще, чем размазанное на сотни процедур такое же творчество.

Ну самописный обмен через COM теоретически может быть оправдан, хотя все равно хрень, ибо COM - устаревшая (и хреновая) технология, но вот если ты конфу на поддержке курочишь без использования расширений, за это надо гнать. Если конфа уже раскурочена до тебя, тогда вызывает вопрос компетентность аудиторов.

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

Ну аудиторы же просто порекомендовали а не штраф выкатили. Т.е. дали рекомендации и по сути правильные. На счет обмен по COM работает и хорошо. У меня вообще обмен с БП через ВнешниеИсточники, по сути на прямую черзе SQL сделан, работает на 4-6 порядков быстрее и все довольны :)

(+)90 тьфу не тот флажок поставился.

хм

Кодекс пирата — это просто свод указаний, а не жёстких законов.

(89) Родила то родила, но обновить даже версию формата далеко не тривиальная задача

По поводу расширений. Они нормально заработали совсем не давно.
Кидаться переписывать все под них смысла нет

(95) Почему не стоит? Если база на свежайшей конфигурации и внедрение только началось, то почему бы и нет?

(71) "отлаживать их тоже приходится. А явного кода в отладчике нет" // Неправда )

(96) Ну если делать нечего, то можно и переписывать.
Но обычно делать всегда есть чего

(98) Разве экономия времени и сил при обновлении - не стоит усилий по переносу изменений в расширение?

(99) При обновлении внесенные изменения в код конфигурации проще контролировать и спокойнее на душе. Но только если изменения внесены эффективно (точечно).

А вот заработает ли твое расширение после обновления ты по факту узнаешь уже только после обновления

(100) Как бы я хотел, чтобы это было правдой... Но вот недавно я столкнулся с базой, в которой изменения внесены были более-менее точечно, но чтобы выполнить сравнение с конфигурацией поставщика - надо было ждать 7 минут, пока откроется окно сравнения.

(101) Любое изменение придется тестировать после обновления. Но само обновление будет немного проще (далее-далее-далее) - с расширением, и гемор с объединением изменений - если без расширения.

"гемор с объединением изменений - если без расширения" // Подробнее

Второе предложение в (100) не просто так написано )

(102) Обновление конфы - проще, обновление доработок - сложнее

(103) Да, но в жизни вместо человеческого кода приходится встречаться с велосипедами и костылями.

(105) А в чём сложность второго по сравнению с кодом, раскиданным по конфигурации? Я только начал перенос изменений в расширение, и пока не встречал особого геморроя. Когда изменения были в конфигурации, а не в расширениях - пришлось пострадать...

(107) Когда будет более-менее серьезное обновление конфы поймешь

(108) Подскажите пожалуйста, к чему готовиться.

Мне вот интересно, учет ТМЦ в эксплутации в ERP, сделанный на оборотном (!) регистре накопления, это следование стандартам ?

(109) то что перестанет работать, а сравнения с типовой нетути

(109) Еще один фанат расширений

(110) это архитектор был спохмелья

А вот интересно ты сейчас в гите ведешь версионироание разработки расширений? или совсем не ведешь?

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

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

(115) Так конфу поставщика обновили, и теперь хер поймет что именно делало расширение

(111) Спасибо за ответ, но это известная засада. Я подумал, что речь шла о неожиданном косяке. Я надеюсь что 1С придумает какое-нибудь умное сравнение, которое облегчит сопровождение расширений.

(112) Как будто быть фанатом расширений - это что-то плохое. Расширения - это наше светлое будущее, в которое 1С нас медленно но верно заводит. Перелопаченные в стиле письма из Простоквашино конфигурации - это куда большее зло (чем расширения). Это зло еще можно было терпеть во времена 7.7 и 8.0-8.1, но современные конфигурации изменять все меньше желания.

(116) Не спорю, расширения изначально придумали для другого, но в итоге и для нас (необлачников) оказалась польза.

(114) Если это вопрос ко мне, то я только-только начал это делать и гит еще не прикрутил (когда-то надеялся что EDT успеют напилить, но видимо не судьба). Скажите пожалуйста, где можно почитать про самую безболезненную связку GIT и CF-CFT?

(118) Я очень надеюсь, что сделают трехстороннее сравнение типа "старая конфигурация поставщика-новая-расширение.

(118) Как говорится:
Вот когда сделают тогда и поговорим

(120) вот тут полностью согласен, учитывая что ещё этой осенью на мисте был вал жалоб на вылеты расширений.

(118) Как-будто не будет теперь "писем из Простоквашино" в расширении, бу-га-га

В расширении хотя бы объектов меньше.

(118) "Перелопаченные в стиле письма из Простоквашино конфигурации - это куда большее зло (чем расширения)"

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

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

(124) Я всегда так делаю :)

(123) Ага. какую нибудь-форму добавишь и полконфы в расширение заедет

(127) там фильтр есть - и все попутчики не видны.

(51) Выгрузка из УТ 11 в БП 3, в одну сторону, документы и справочники.

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

А так, расширения прикольно использовать. Мне понравилось. Советую.

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