Каталог решений - Открытая просьба разработчикам подсистем

Давайте жить дружно. Письмо буквально мольба человека который приобрел несколько подсистем и теперь пытается их банально внедрить. Итого 4 подсистемы 1 приобретена тут одна поставлена франчами и 2 открытые с ограниченным функционалом.

И из 4 только две имеют префиксы подсистем и объектов для них.

Только 1 документацию по которой удалось поставит не беспокоя разработчиков

И у двух оказались одинаковым  имя объекта справочника

Результат 2 недели разнообразного и утомительного секса.

Я прошу ВАС 

Делайте префиксы и документацию! ПОЖАЛСТА!!! 

Если есть функции и процедуры — ОБЯЗАТЕЛЬНО КОММЕНТИРУЙТЕ (бывает версия разработчика системы отстает от актуальной на 2-3 обновления) И в документацию их.

Для своих подсистем делайте доп интерфейсы.  

Пишите версии к файлам обновления (и если не сильно сложно — изменения основные).

Давайте придерживаться хоть каких-то правил…

И как от продавца ПЛИЗЗЗ ДОГОВОРА И ДОКУМЕНТЫ оформляйте правильно . их не принимают вы же сами знаете что бухгалтерам хоть танк купи но чтоб с документами. Мне трижды пришлось писать самому то что было в продаже но без документов (за исключением ООО «Инфостарт», вот у них все в порядке, документы принимаются без проблем). 

Записывайте видео презентации такие продукты берут в РАЗЫ больше чем просто текстовое описание. И это 2-3 минутные ролики для быстрой презентации продукта и 6-9 минут для более глубокой демонстрации.

Я очень прошу не смотреть на грамматику просто 2 недели бесполезного труда для того чтобы запустить продукты «готовые» к использованию. 

Я продаю ВАШИ продукты , я пишу свои но я не изобретаю велосипеды я ищу подходящие.

Я даже проценты не прошу.

Я прошу делать продукты Удобные не только Пользователям.

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

УТОЧНЕНИЕ — Я НИЧЕГО НЕ ИМЕЮ С ПРОДАЖИ ГОТОВЫХ РЕШЕНИЙ — ТОЛЬКО ЗА ДОРАБОТКИ. 

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

ВСТУПИТЬ В ГРУППУ

Что есть стандартизация это -[URL=http://ru.wikipedia.org/wiki/Стандартизация]http://ru.wikipedia.org/wiki/стандартизация[/URL]

Вообщем для получения более качественного и совместимого товара нужно делать так чтобы этот товар был максимально удобен.

Стандарты не всегда- удобно но привычно. (как то раз я наткнулся на ручку установленную «наоборот» для открытия её нужно было поднять вверх. дело было в гос учреждении в итоге я был 5 в очереди из 20 человек. Пока оттуда не вышла баба МанЯ уборщица. Итого — 45 минут жизни из-за того что не стандарт).А сколько времени тратите вы на разбирательства с не стандартом?

(Наполнение по принципу вики будет беру из каментов пишу сюда- обсуждается- исправляю на победивший вариант)

Итак  приступим.

1 [U][B]Прописные истины[/B][/U]

— Комментирование кода.// Без комментариев

— Комментирование переменных. // ВЕЗДЕ

— Комментирование вызовов процедур и функций // расписываем параметры и возвращаемые значения!!!

— Указание версий конфигураций для которых работоспособность проверена // зачастую обновления опаздывают от версии основной конфигурации  !!!Критично!!!

— Указание версии подсистемы или обработки //как на форме (если есть форма) так и через переменные или константы (переменные — более желательно)

— Содержание пакета поставки («продукт» + справка + тех данные (версия дата выпуска изменения по версиям контакты для указания ошибок) ).

— Архивирование в zip (rar — платный продукт если что) и в имени архива ОБЯЗАТЕЛЬНО версию и наименование продукта.

— У infostart.ru есть возможность создавать группы — создавайте как например группу и форум пожелания- ошибки — доработки — примеры. (ибо искать ответ пороше в структурированной системе).

2 [B][U]НЕ очевидное — Вероятное[/U] [/B]

— Префиксы к полям, ролям, процедурам, справочникам, документам // Вообщем везде везде Все что при обновлении необходимо ручками корректировать — ПРЕФИКСЫ.

 — И не просто префиксы а например МПР_001_Номенклатура 

— МПР (моя первая разработка) (любая комбинация букв)

— 0001 (версия глобальная)

—- пример 0002 — (платформа 8.1) 0003- (платформа 8.1) 0012- (платформа 8.1 УТ ) 0022 (платформа 8.1 БП) и так далее…

0000 — первая цифра (пользовательская) -вторая и третья (код конфигурации) — четвертая (код платформы)

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

— [I][B]Глобальные изменения в подсистеме[/B][/I] (с изменением/удалением/реструктуризацией объектов метаданных ).

— не удаляйте сразу  добавьте префикс (del_6.13.5) что дословно будет удалено в версии  6.13.5 // это позволит тем кто что-то дописал под себя- не потерять данные (при добавлении объектов метаданных не разработчиком подсистемы).

— При изменении типов/видов метаданных с «потерей данных» (делайте дубликат этого поля с копированием данных) межверсионную обработку // например добавьте обработку или авто копирование в Аналогичный Вид метаданных для того чтобы эти данные были доступны несколько версий (при указании этого в документации внедренец или администратор или программист сам выберет оставлять ему или удалить). Да это два раза объединять но зато позволит максимально уменьшить риск потерь критичных данных.

— реструктуризация (изменение взаимосвязей/подчиненностей и иных критичных данных ) ОБЯЗАТЕЛЬНОЕ УКАЗАНИЕ  НА такой тип изменений.// желательно еще на стадии решения изменения.

Итак первые сформулированные тезисы

Промышленное производство — это не 40 прогеров а ПОДХОД.  И совершенно верный — сначала документация — потом код!

{awk} 

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

 Кустарное программирование: «Комментарий не соответствует функции». Промышленное программирование: «Функция не соответствует документации». В кустарном варианте будет исправлен комментарий, в промышленном — код.

с разрешения автора (Алексей Иванов) добавляю его статью без изменений 

Предлагается система префиксов для именования переменных при написании программ на 1С. Сам пользуюсь этой системой более 10 лет

 Префиксы имен переменных в программных модулях

Правила именования переменных при разработке конфигураций на платформе 1С:Предприятие 7.7.

Префикс отделяется от основного имени переменной символом «_» для лучшей читаемости программы.
Гл_ — глобальная переменная, процедура или функция. Описана в глобальном модуле с ключевым словом ЭКСПОРТ.
м_ — переменная, описанная явно или неявно в текущем программном модуле. Рекомендуется всегда явно описывать переменные модуля в начале текста модуля с помощью оператора Перем.
л_ — переменная, описанная явно или неявно в текущей процедуре или функции. Рекомендуется никогда явно не описывать локальные переменные процедур и функций, а создавать их с помощью оператора присваивания, например: л_НомерСтроки=0.
п_ — параметр текущей процедуры или функции.
рд_ — реквизит диалога. Описан в форме диалога.
яч_ — ячейка таблицы в режиме ввода данных. Определена в таблице. Может использоваться в тексте программы в качестве переменных. Является первичной ячейкой и/или группой соседних ячеек, объединенных командой «объединить ячейки». Представляет собой единую неделимую единицу ввода и/или отображения информации в таблице.
от_ — область таблицы. Определена в таблице. Представляет собой группу ячеек таблицы. Используется, как правило, для форматирования ячеек области.
Отсутствие префикса означает, что переменная является реквизитом того объекта (справочника, документа, …), модулем которого является фрагмент программы. Как следствие, в модулях отчетов и обработок, в том числе и внешних, не должны встречаться переменные без префикса.

Правила именования переменных при разработке конфигураций на платформе 1С:Предприятие 8.

Гл_ — глобальная переменная, процедура или функция для основного режима работы конфигурации. Описана в модуле приложения с ключевым словом ЭКСПОРТ.
ГлВС_ — глобальная переменная, процедура или функция для работы конфигурации в режиме внешнего соединения. Описана в модуле внешнего соединения с ключевым словом ЭКСПОРТ.
м_ — (переменная модуля) переменная, описанная явно или неявно в текущем программном модуле. Рекомендуется всегда явно описывать переменные модуля в начале текста модуля с помощью оператора Перем.
л_ — переменная, описанная явно или неявно в текущей процедуре или функции. Рекомендуется никогда явно не описывать локальные переменные процедур и функций, а создавать их с помощью оператора присваивания, например: л_НомерСтроки=0. 
п_ — параметр текущей процедуры или функции.
рф_ — реквизит формы. Определен как реквизит формы (на закладке «Реквизиты»).
Отсутствие префикса означает, что переменная является реквизитом того объекта (справочника, документа, …), модулем которого является фрагмент программы. Как следствие, в модулях отчетов и обработок, в том числе и внешних, не должны встречаться переменные без префикса.

Комментарий.
Давно пользуюсь этой системой и уже не могу с ней расстаться.
Природа префиксов — «по месту рождения» переменной. Префикс отлично дополняет смысл, который можно узнать из имени переменной. Потому что всегда полезно знать, является переменная локальной или объявлена в модуле или это параметр процедуры (функции) или вообще является реквизитом объекта, к которому модуль относится. Когда писал на 7.7 до этой системы,был у меня случай (и потом еще пара случаев, когда другим помогал), когда объявлена переменная в модуле формы и с таким же именем реквизит диалога на форме. Первый раз очень трудно такую ошибку найти. 
При использовании префиксов такое просто невозможно.
Когда ко мне обращались за помощью в поиске ошибки и показывают модуль без префиксов, я часто говорю: «префиксов нет, поэтому и не работает». И на самом деле ошибка находится сама, стоит только расставить префиксы в модуле. Ну не все ошибки, конечно, а те, которые не позволяли двигаться дальше.

Для 8-ки практически все то же самое, что и для 7.7. Только в 8 реквизит диалога отделен от данных, поэтому префикса «рд_» нет. Обращение к элементам формы возможно только через свойство формы «ЭлементыФормы», так что префикс не нужен, и так ни с чем не спутаешь. Зато в форме могут быть реквизиты (которые определены на закладке формы «реквизиты»). Для них префикс «рф_».
Еще пока не пришлось пользоваться префиксами «Гл_» и «ГлВС_» — для этого надо конфигурацию с нуля писать.

Хотел еще суффиксы ввести, «Ссылка» и «Объект». Но не прижились: писать долго, и хотя для смысла они очень полезны, но острой проблемы нет. Поэтому я их использую, но только в случаях, когда это необходимо, поэтому в систему для обязательного применения они не записаны. Но требуются они довольно часто, потому что все-таки важно понимать, переменная «л_Контрагент», например, является «л_КонтрагентСсылка» или «л_КонтрагентОбъект».

8-ка правда немного мешает применению этой системе. В 8-ке помощник ввода текстов гораздо мощнее, чем в 7.7. Например, при вставке предопределенных процедур модуля мы получаем заголовок процедуры вместе с параметрами, которые, к сожалению моему, без префиксов «п_». И ставить их мне иногда лень, Поэтому в текстах моих можно встретить небольшие процедуры без префиксов, если очень тороплюсь. Но в большинстве случаев все-таки меняю. И чем больше и сложнее текст процедуры, тем больше важно поставить префиксы у параметров.

Сейчас и разработчики 1С стали использовать префикс «м» в переменных модулей, правда без подчеркивания. На мой вкус с подчеркиванием лучше. Но все равно, когда читаешь текст какой-нибудь процедуры (функции) и сразу не понимаешь, локальная это переменная, параметр процедуры (функции) или реквизит объекта у меня возникает раздражение. Ну если уж пришли к префиксу «м_», то дальше просто просятся префиксы «п_» и «л_», с моей точки зрения, конечно.

В общем, попробуйте сами, не пожалеете.