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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

хм

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

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

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

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