Как красиво и профессионально вести (оформлять) разработку в 1С

19.12.14

Разработка - Рефакторинг и качество кода

Что важно для руководителя IT...
За чем нужно следить ведущему программисту...
Что будет помогать программисту...
Что сэкономит вам массу времени...
Что сделает вашу работу профессиональнее...

Идея - Константин Илларионов, Глеб Дунаев

 

Краткая предыстория


В 2012 году мне досталась в наследство база с сильно измененной конфигурацией УТ 10.3. Эта база дорабатывалась в течении нескольких лет многими программистами (и штатными, и франчайзи). Документации практически никакой не велось, комментарии в коде были скудны и неинформативны, пользователи внедряющие тот или иной функционал уже давно уволились, спросить было не у кого... В некоторых случаях было совершенно непонятно что и для чего делалось и как это работает... И мы решили это прекратить. Были сделаны первые шаги, которые в дальнейшем привели к созданию небольшой системы оформления разработки. Данная система уже два с лишним года успешно функционирует в нашем холдинге и с лихвой окупает время потраченное на нее.

 

 Из чего состоит эта система?


1. Комментарии в коде

2. Справочная информация

3. Цифровые обозначения отчетов/обработок

4. Добавление/изменение объектов

5. Контроль за исполнением


 

 А теперь детально, по пунктам:


1. Комментарии в коде


О чём пойдёт речь. Комментарии в коде делают практически все программисты. Думаю всем понятно для чего они нужны. Комментарий - это признак произведенного изменения и описание этого изменения.

В чём проблема. Часто по комментарию можно понять только одно, то что было сделано изменение :) При этом  искать описание этого изменения крайне проблематично (имеется ввиду описание доработки, техзадание), я думаю многие с этим сталкивались: кто-то его сделал и где-то сохранил... надо знать это место... потом умудриться найти нужную информацию... суметь увязать с тем что фактически есть в конфигурации... а может описание и не сохранилось... плюс исполнители часто забывают обновлять информацию об изменениях и она становится неактуальной. В итоге, все эти факторы мешают быстро понять кто, что, когда делал, и что нужно сделать сейчас (и в каком месте!)... А если посмотреть на проблему глобально, то выяснится что подобное ведение дел не позволяет быстро оценить отличия вашей конфигурации от типовой, какие контуры затронуты, насколько серьёзны эти изменения и т.д...

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

Наше решение. Сначала прошу сравнить комментарии трех программистов (примеры из рабочей базы):

    

     Пример 1:

// voeк 30.20.2008 begin 

//----------------------
 
// voeк 30.20.2008 end

     Пример 2:  

//AТ addon [14.04.2011]
    
//---------------------------------
 
//AТ addon [14.04.2011]   

     Пример 3 (наше решение):

//начало-ДГ.08.04.2014. Заказчик Пономаренков П. Запись реквизита ДД_Наименование_для_сайта_прайса.
//Нужно чтобы при любой записи элемента в этот реквизит записывалось полное наименование
//(
если реквизит не заполнен).

//----------------------

//конец-ДГ

Проанализируем:

       1. В первом примере видно:

- где начинается комментарий и где заканчивается

- кто сделал изменения

- когда сделаны изменения (правда ошибка в дате)

2. Во втором примере видно:

- кто сделал изменения

- когда сделаны изменения

       3. В третьем примере (наше решение) видно:

- где начало комментария и где он заканчивается

- кто сделал изменения

- когда сделаны изменения

- кто заказчик

- название задачи

- описание задачи

Очевидно что третий пример содержит более информативный комментарий, который в полной мере выполняет свою функцию. И самое главное, для чего собственно это всё нужно, оформляя внесенные изменения подобным образом, вы сохраняете их в одном месте. В самом надежном и доступном. В базе данных. Не в файликах Word и Excel, не в сторонних программах типа Итилиума, не в головах пользователей и программистов, а ВМЕСТЕ с вашей базой данных... И даже по прошествию нескольких лет, можно легко извлечь все изменения, провести "инвентаризацию" системы и понять как сейчас она работает!

Как реализовать:

1. Все комментарии делаем однотипными и начинаем строго с символов "//начало-" (//начало-ДГ). Таким образом можно легко найти комментарии ВСЕХ программистов. Если нужно найти комментарии только ОДНОГО программиста - в поиске задаётся "//начало-ДГ". "ДГ" - это инициалы фамилии и имени программиста.

(Примечание: а теперь представьте ситуацию где один программист пишет "begin-end", другой пишет "начало-конец", а третий вообще рисует символы ">> <... будет очень сложно их найти.)

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

3. Указываем кто заказывал это изменение (Заказчик Пономаренков П.). По прошествии времени, очень часто забывается кто и зачем придумал это, указание заказчика поможет восстановить в памяти эту задачу. А если вы совсем забыли, или не участвовали в её реализации, можно получить дополнительную информацию непосредственно у заказчика :)

4. Даём краткое название задаче (Запись реквизита ДД_Наименование_для_сайта_прайса). Нужно для краткого указания того что делалось, какие были изменения (1) и для идентификации задачи (2). В этом примере, по краткому названию, видно что изменения касаются определенного реквизита (а не движений по регистру накопления например). А также краткое название позволяет найти ВСЕ места, где код менялся по этой задаче (используем копирование при вставке комментария).

5. Делаем подробное описание задачи (//Нужно чтобы при любой записи элемента, в этот реквизит... и далее). Нужно для понимания того, что и для чего делалось. Для каждого изменения делается свой комментарий (но первая строка у всех одинаковая!), если требуется сделать общее описание, то оно делается в одном месте. Например:


//начало-ОС.23.10.2014. Заказчик Смирнов О. Задача по написанию публикации.

//здесь описание №1
//конец-ОС

............

//начало-ОС.23.10.2014. Заказчик Смирнов О. Задача по написанию публикации.
//здесь описание №2
//конец-ОС

............

//начало-ОС.23.10.2014. Заказчик Смирнов О. Задача по написанию публикации.

//здесь описание №3
//и
//общее описание по всей задаче, потом программист поиском по названию задачи
//найдет это описание и прочтёт.
//конец-ОС


 


2. Справочная информация


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

В чём проблема. У пользователей очень часто возникают вопросы типа: "откуда берет данные отчет", "как считает эта обработка", "что проверяется в документе" и т.д. А самое интересное то, что они уже не первый раз работают с этим отчетом/ обработкой/документом... они просто забыли... или сделали вид что забыли... 

Как обычно решается. Что в таких случаях делает программист? Начинает вспоминать или лезет в конфигуратор... И хорошо если это делалось недавно, или алгоритм расчета какой-то простой... А если делалось давно, например несколько месяцев назад? Сколько времени надо потратить, чтобы полностью вспомнить реализованный функционал? Иногда до нескольких часов...

Наше решение. В каждом добавленном или измененном объекте есть нами добавленная справочная информация, и именно она позволяет быстро и красиво (прям на глазах у пользователя) ответить на все интересующие вопросы!

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


Справка в программе


Справка внешней обработки


3. Цифровые обозначения отчетов/обработок


О чём пойдёт речь. Поговорим о удобстве работы с внешними отчетами и обработками. 

В чём проблема. В один прекрасный день мы поняли что у нас в базе содержится огромное количество обработок и отчетов непонятно кем и для кого написанных, и главное, непонятно что они делают. И кроме этого, с ними крайне неудобно работать. Например: звонит пользователь и говорит что у него в отчете (далее следует какое-то название, что-то вроде с продажами) не появляются какие-то данные. Ваши действия: 1. найти отчет 2. вникнуть в то как он работает 3. понять что дальше делать (менять настройки, доработать его, ничего не трогать или что-то еще).

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

Тут начинается самое интересное, хорошо если отчет типовой или написан вами, вы хоть будете знать что он делает, а если нет? Нужно как то быстро вникнуть в его суть, можно конечно спросить у пользователя, но пользователь вдруг оказался финансовым директором и ему некогда рассказывать вам об этом отчете, и скорее всего придется лезть в конфигуратор. Открыв отчет в конфигураторе вы вдруг понимаете что... ничего не понимаете... а комментариев в коде как правило немного. А иногда чтобы ответить на вопрос пользователя - нужно очень хорошо понять принцип работы отчета, а это значит досконально вникнуть в его содержимое. И тут многим (особенно начинающим программистам) приходит в голову достаточно простое решение - взять и переписать этот отчет. Но это не всегда возможно, а иногда просто невозможно (поэтому то и ценится умение читать чужой код)... В общем решение вопроса начинает затягиваться на неопределенный срок. А тут еще пользователь вас торопит. Наконец-то разобрались, но это еще не всё, нужно еще третий пункт отработать... А через месяц.... вам опять звонит этот пользователь и снова задает этот же вопрос, и вы снова проходите по этому кругу... Да-да, так к сожалению очень часто бывает.

Наше решение.

1. Чтобы быстро идентифицировать отчет (или обработку) мы присваиваем ему трехзначный цифровой код, где первая цифра закреплена за программистом, а две последующие - номер по порядку. А также присвается буквенное наименование показывающее назначение отчета. И когда пользователь говорит вам: "Посмотрите пожалуйста 516 отчет". Вы моментально находите его по цифре "516" и при этом знаете что под цифрой "5" у вас разработку ведет программист Иванов, к которому можно при случае обратиться за разъяснением.

2. Для понимания того как работает отчет, существует справочная информация, она записывается в сам отчет, а также в txt-файл. Файл этот нужен для просмотра справки без открытия отчета в 1С. В справке подробно описывается: принцип работы отчета (1), откуда берет данные (2), как их выводит (3), какие настройки нужно сделать (4), обязательные для заполнения поля (5), различные нюансы (6). В 90% случаев справочная информация позволяет дать ответ пользователю не прибегая к открытию отчета в конфигураторе.

Как реализовать:

1. Название (1), синоним (2), имя на форме (3), название каталога (4) и название  txt-файла (5) всегда должны быть одинаковы. Например: DD_UT_741_Установка_доп_прав_у_пользователей. Где: DD – название компании, UT – название конфигурации, 741 – цифровой код отчета/обработки, «Установка_доп_прав_у_пользователей» - что делает данная обработка. Для удобства копирования слова разделены не пробелами, а нижними дефисами (всё название выделяется одним кликом мыши).

2. Цифровой код состоит из двух частей: 7 – цифра закрепленная за определенным программистом, 41 – номер обработки/отчета по порядку. 1С-вские обработки (измененные типовые) начинаются с «0», обработки неизвестных программистов – начинаются с «8».

3. В каждой обработке/отчете должна быть справочная информация, которая должна быть описана в txt-файле. Также создан специальный каталог для разработчиков где хранятся каталоги с отчетами/обработками. См. скриншот:


Каталог с внешними отчетами и обработками


4. Добавление/изменение объектов


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

2. Все новые объекты (и реквизиты) добавляются с префиксом. Префикс всегда один и тот же и не привязан к программисту, нас это сокращенное название фирмы - "ДД_". Например: «ДД_Заявка_покупателя». Благодаря префиксу мы сразу понимаем какой функционал задействован, наш или типовой. Измененные и добавленные объекты добавляются в отдельную подсистему.

3. После изменения типовых объектов (или добавления новых), таких как справочники, документы – в них добавляется справочная информация с описанием произведенных изменений. Желательно вставлять их выше типовой справки, чтобы в первую очередь читались наши изменения.


5. Контроль за исполнением

 

Контроль осуществляется периодически, раз в два - три месяца. Для этого выборочно открываются объекты (документы, справочники, обработки),  смотрится:

- справочная информация,

- названия отчетов/обработок в каталоге

- запускается глобальный поиск инициалов/ФИО программистов

Но лучший контроль - это конечно совесть исполнителя Laughing поэтому желательно работать с людьми ответственными, за которыми не надо следить!


Ну и напоследок, вернемся к началу:

Нужно ли это руководителю IT... Что будет если уйдут программисты (или пользователи) "носители знаний"? Если возникнет разбирательство кто, зачем, когда внедрил функционал? Если нужно быстро провести ревизию конфигурации? Как быстро передать информацию другим специалистам?

Нужно ли это ведущему программисту... Что будет когда пользователи начнут задавать вопросы по тому функционалу который писал не он, а молодые специалисты или франчайзи? Сможет он быстро ответить на эти вопросы? А если это его доработки, то сможет ли он вспомнить то что делал полгода назад?

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

Нужно ли это пользователю... Как свести к минимуму количество обращений к программистам если у пользователя элементарно нет справочной информации? Как ему максимально быстро получить ответ на свой вопрос если программисту надо много времени на то чтобы найти его?

Мы для себя давно ответили на эти вопросы. Теперь ваша очередь по новой взглянуть на них :)

Всего вам доброго!

разработка оформление

См. также

Когда понадобился новый оператор

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Когда понадобился новый оператор, но его нет в синтакс-помощнике, что делать?

18.03.2024    1154    ZhokhovM    2    

4

Когда разработчик платформы не добавил проверку препроцессоров

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Когда разработчик платформы решил пойти на кухню за кофе, а проверку препроцессоров не добавил, и вот тут-то и началось: "Что, опять все сломалось? Ну и кофе же я забыл сделать!".😅

18.03.2024    2681    ZhokhovM    4    

8

Реструктуризация - бесконечная история

Рефакторинг и качество кода Платформа 1С v8.3 Бесплатно (free)

При разработке программ требуемый функционал ставят на первое место, но есть еще и архитектура программы. На горизонте 5-10 лет она становится важнее функционала, который должен работать при масштабировании и росте данных. Реструктуризация 5 терабайтной базы 1С 8.2 в формат 1С 8.3, складывает весь пазл архитектурных просчетов, которые сделали ради функционала. Как это исправить? - для разработки правильной архитектуры, нужно всего лишь сместить фокус с функционала и подумать о «вечном».

29.09.2023    1909    1CUnlimited    15    

22

Чистый код. Мой взгляд на жизнь в макаронных джунглях. Часть 2

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

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

27.09.2023    6968    Lemmonbri    136    

36

Чистый код. Мой взгляд на жизнь в макаронных джунглях. Часть 1

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

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

19.09.2023    4346    Lemmonbri    16    

31

5 подходов при доработке конфигурации 1С, чтобы в будущем не было мучительно больно её обновлять

Архитектура Рефакторинг и качество кода Обновление 1С Платформа 1С v8.3 Бесплатно (free)

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

10.08.2023    9586    0    1c-izhtc    37    

21

Задача на ошибки и неоптимальности при проведении приходной накладной

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Задачу эту дают на собеседованиях, видимо, те франчи, которые не в состоянии оценить человека по резюме и в ходе беседы. По идее задачи, подобные этой, должны давать начинающим студентам. Но дают всем подряд. Итак: мои 5 копеек. Критика приветствуется.

11.07.2023    2214    magic1s    32    

11
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. mmoozzgg 19.12.14 12:12 Сейчас в теме
все супер, а не мало 2 знака для номеров по порядку?

зы у себя в компании мы еще номера макетам присваиваем и печатаем их вместе с датой последнего изменения отчета/обработки
13. mrdug 759 20.12.14 22:32 Сейчас в теме
(1) mmoozzgg,
пока что 2-ух знаков хватает, например программист, работающий более 2-х лет, "своих" отчетов/обработок создал порядка 40 штук, то есть занял всего 40 номеров.
2. gubanoff 63 19.12.14 14:37 Сейчас в теме
1. по поводу комментариев: а как быть, если изменения по одному вопросу затрагивают несколько модулей, форм, макетов, объектов? Когда происходит рефакторинг кода? Лично меня даты и фамилии программистов в коде всегда умиляли. Они бесмысленны. По прошествии n-лет мне глубоко безразлично кто и каким числом написал кусок кода, если он не работает, то его нужно переписать и все. Более-менее уместна идея в комментариях писать номер замечания из учетной системы задач. А уже в учетной системе будет виден заказчик, дата, описание задачи и т.п. Но это тоже работает процентов на 50, не более.
2. Заказчики в справке - это тоже умиляет. Если их хотя бы больше 10, то это уже будет проблемой.
3. Номера отчетов - идея нормальная.
4. Префиксы у объектов - идея нормальная.
5. Контроль за исполнением - это хорошо. Именно из-за низкой исполнительской дисциплины или из-за отсутствия контроля за исполнением все предыдущие пункты и не будут работать. Или будут.
begemot; Артано; Designer1C; awk; +4 Ответить
12. TODD22 18 20.12.14 19:30 Сейчас в теме
(2) gubanoff,
По прошествии n-лет мне глубоко безразлично кто и каким числом написал кусок кода

Даты доработок очень нужная информация даже по прошествии n-лет. Например сталкивался с доработками в типовой сделанными в 12 году. В 13 году 1С доработала функционал и необходимость в "дописках" пропала. Именно по дате доработки и определили что функционал больше не нужен.
Более-менее уместна идея в комментариях писать номер замечания из учетной системы задач.

Это когда есть такая система учета задач! тут не на каждом предприятие есть элементарно список доработок в word формате... не говоря уже о системе учёта задач.
ну отобрали по фамилии, ну увидели, что это был некий Пупкин, уволенный 2 года назад. Что эта информация вам дает? Сделать на основании нее вывод, валиден код или нет невозможно.

Ещё варианты предложить? Например я звонил Пупкиным и просил прокоментировать некоторые сделанные ими доработки. Люди были вполне адекватными и рассказывали что, как и для чего было сделано.
uncle_Vasya; +1 Ответить
14. mrdug 759 20.12.14 22:44 Сейчас в теме
(2) gubanoff,
по части дат и фамилий: отчасти соглашусь, по прошествию времени многое становится не нужным, но в текущем времени - это ооооочень хорошо работает. А даты и со временем востребованы, когда "чистили" бухгалтерию от изменений по датам понимали оставлять изменения или нет.

заказчики в справке: это тоже для текущей работы.

по контролю: полностью согласен, поэтому на работу берём людей которых можно "выпустить в самостоятельное плавание", у нас 95% работы на доверии основано (среди программеров).
93. Pryanishnikov_Vladimir 10.11.20 09:39 Сейчас в теме
(2) по первому пункту хранилище конфигурации куда более информативно
3. chmv 19.12.14 14:43 Сейчас в теме
А мне фамилия в комментарии очень удобна. Я делаю поиск по ней
5. gubanoff 63 19.12.14 15:34 Сейчас в теме
(3) chmv, ну отобрали по фамилии, ну увидели, что это был некий Пупкин, уволенный 2 года назад. Что эта информация вам дает? Сделать на основании нее вывод, валиден код или нет невозможно.
Артано; +1 Ответить
4. chmv 19.12.14 14:43 Сейчас в теме
6. brr 182 19.12.14 15:55 Сейчас в теме
Префиксы в именах метаданных зло! Я за суфиксы :)
Артано; burlakov; sashocq; zaursoft; dmpas; Lo1jke; Dinara78; uri1978; rtnm; tormozit; vano-ekt; Garrynich; alexscamp; ixijixi; shalimski; Aleksey.Bochkov; +16 Ответить
8. gubanoff 63 19.12.14 16:01 Сейчас в теме
(6) brr, по префиксам сортировать удобно :)
76. zaursoft 19 06.01.15 21:26 Сейчас в теме
(8) gubanoff, Возможно, но писать код очень неудобно. Особенно, если этих префиксов много в конфигурации. Кроме названия объекта нужно либо помнить префикс, либо искать в дереве объектов. Есть же система стандартов и методик разработки конфигураций для платформы 1С:Предприятие 8.
Артано; +1 Ответить
28. vano-ekt 123 24.12.14 09:17 Сейчас в теме
(6) brr, +
в процедурах/функциях префиксы дб
7. monkbest 115 19.12.14 15:57 Сейчас в теме
Вопрос по предисловию: как так вышло, что раньше у предприятия не было денег на то, чтобы франчи вели документацию, а теперь появились?
15. mrdug 759 20.12.14 22:48 Сейчас в теме
(7) monkbest,
тут дело не в деньгах, а в отношении. Видимо франчам просто не ставилась задача писать документацию. А вот сейчас у нас любой разговор начинается с вопроса будет ли на выходе документация оформленная нужным образом.
18. monkbest 115 22.12.14 09:05 Сейчас в теме
(15) нет, наверное, дело именно в деньгах. Очень часто наблюдаю картину в жизни у клиентов и на этом форуме часто такое пишут.
Заказчик в бумагах один фиг ничего не понимает в большинстве случаев и тратить денег на них по умолчанию не хочет. Это, кстати, одна из причин начала работ не в крупной франче, а по мельче. В мелких на бумагах не настаивают, а в крупных это типа стандарт, который естественно увеличивает число часов к оплате.
Потом на мой взгляд происходит одно из событий, влекущее передачу дел полностью или частично. Причины видел следующие:
1. рост заказчика, что повлекло появление штатного сотрудника
2. смена руководства заказчика, который не понимает зачем "это было нахреноверчено" (не факт, что "нахреноверчено" было плохо, просто не понятно)
3. смена франча (причин много, от отказа оплаты из-за кризиса, а потом уже назад вернуться стремно, толи франч накосячил как, толи у франча "любимый" специалист уволился, а остальные балбесы...)

Но самостоятельного осознания заказчиком я не встречал. Чтобы вот так позвонил мне клиент со словами:
"Антон, мы тут с тобой наделали делов, а вдруг меня уволят или тебя, давай все задокументируем, я с директором договорился, он все оплатит" - звучит как сказка
rusmil; uncle_Vasya; ojiojiowka; OdinAss; help1Ckr; blindcat2006; mrdug; +7 Ответить
48. blindcat2006 88 25.12.14 09:31 Сейчас в теме
(18) monkbest,
Чтобы вот так позвонил мне клиент со словами:
"Имярек, мы тут с тобой наделали делов, а вдруг меня уволят или тебя, давай все задокументируем, я с директором договорился, он все оплатит" - звучит как сказка

- было, неделю назад, именно такими словами
9. chmv 19.12.14 16:19 Сейчас в теме
А я отбираю по своей фамилии и ищу что я меняла
10. gubanoff 63 19.12.14 16:39 Сейчас в теме
(9) chmv, для вашего случая это нормально. А когда несколько программистов дорабатывают конфигурацию, плюс кто-то из них периодически меняется, то эффекта от фамилий в коде ноль.
Артано; +1 Ответить
94. Pryanishnikov_Vladimir 10.11.20 09:41 Сейчас в теме
(9)
(10) Еще меньше эффекта от фамилий женщин программистов, меняющих их с разной частотой)
11. Sander80 82 19.12.14 23:30 Сейчас в теме
Советы очень хорошие, но чего мне лично не хватило здесь, это использования хранилища.
В нем как минимум видно, кто из разработчиков в последний раз правил тот или иной отчет.
А если еще и административно затребовать от всех писать комментарии к коммитам (при сдаче в хранилище), то, возможно, и комментарии в коде не нужны.
begemot; RustIG; Артано; talych; Чарик; Aleskey_K; zaursoft; RomanMartynenko; Герасим; bforce; dimisa; help1Ckr; awk; pythonchik; alexscamp; monkbest; +16 Ответить
16. mrdug 759 20.12.14 22:52 Сейчас в теме
(11) Sander80,
да, о хранилище не упомянул, хотя оно у нас конечно есть и работа идет через него. В него вносится информация, но в минимальном виде, только о затронутых объектах. Практика показывает, что когда идет разбор кода - смотреть куда-то кроме текущей конфы крайне неудобно.
62. madfox 4 26.12.14 04:29 Сейчас в теме
(11) Sander80, Все верно, комментарии тоже там можно для каждого изменения прописывать
17. TODD22 18 21.12.14 08:23 Сейчас в теме
Ещё удобно номер задачи(тикета) указывать в комментариях. Если изменения в рамках одной задачи будут в нескольких модулях форм, объектов итд.
Можно быстро найти глобальным поиском во всей конфигурации все модули в которые вносились изменения в рамках одной задачи. Экономит время.
begemot; RustIG; talych; zaursoft; Герасим; gradi; dima_home; help1Ckr; Hellisad; h00k; alexscamp; monkbest; +12 Ответить
22. mrdug 759 22.12.14 21:08 Сейчас в теме
(17) TODD22,
насчет номера задачи: у нас эту роль выполняет первая строка комментария, она уникальна: дата+заказчик+краткое название задачи. Можно искать просто по названию задачи, будет тоже самое.
19. dyak84 22.12.14 12:09 Сейчас в теме
C Автором согласен на 100%. Порядок должен быть везде. Ну конечно есть нюансы когда описать сложно., но пытатся нужно всегда. И на мой взгляд грамотный коментарий самое то. Ну и отношение тут всегда должно быть на высоте.Но как говорится каждый должен начать из себя.!!!!!!!!!!!
ojiojiowka; +1 Ответить
20. mikmike 8 22.12.14 14:31 Сейчас в теме
Писать комментарии и справки нужно обязательно - зачастую это помогает четко все сформулировать.
Я проставляю в комментарии отчета номер версии, а в справке - историю версий, сразу за описанием.
dima_home; +1 Ответить
21. sweeex 10 22.12.14 19:07 Сейчас в теме
Толковые советы, только напряжно писать описалово в коде, так как за несколько год будет каша малаша, исправляя код постоянно исправлять описалово везде, можно где то и забыть исправить.
23. mrdug 759 22.12.14 21:11 Сейчас в теме
(21) sweeex,
каша будет если в коде описалова нет. Проверено)))
24. unichkin 1559 23.12.14 00:02 Сейчас в теме
Не захотел ИС мой код из разукрашки есть, вот рисунок тогда...
Прикрепленные файлы:
ojiojiowka; +1 Ответить
25. Иной 23.12.14 00:58 Сейчас в теме
Хороший пост.

От себя добавлю, внешние обработки лучше сохранять в хранилище =).

В типовых конфигурациях есть справочник "ВнешниеОбработки" туда и заливайте всё ("сохраняются" в хранилище значений и "восстанавливаются" при запуске).
Это снимет проблему с поиском где, что и т.д. Ну и плюс в бекапе базы будут все обработки.
27. kredko 20 24.12.14 06:29 Сейчас в теме
(25) Иной, Мы сохраняем Внешние обработки ещё и в отдельной папке на сервере. Каждая папка соответствует типу обработки: печатная форма, обработка ТЧ или отчет. Имя обработки формируется так: ИмяДокумента - ИмяОбработки.
26. TODD22 18 24.12.14 05:51 Сейчас в теме
Может Хранилище конфигурации не всем нужно. Но вот что точно нужно это читать на ИТС стандарты разработки :)
ojiojiowka; nalivai-chai; +2 Ответить
29. webester 26 24.12.14 09:28 Сейчас в теме
Мне кажется, еще немного, и у вы дорастете до http://infostart.ru/public/310640/ и какой нибудь(необязательно) системы управления проектами, в которую можно интегрировать GIT.
JohnyDeath; +1 Ответить
47. mrdug 759 25.12.14 09:27 Сейчас в теме
(29) webester,
не дорастем. У нас два критерия: 1. простота 2. эффективность. На первом же пункте мы и остановимся :) возможно для крупных предприятий это нужно, классно, удобно и т.д. Для нас - нет. И задачи у нас другие стоят. Нам нужно понимание того что сделано, а не оптимизация кода (а именно это я увидел в статье по вашей ссылке).
64. webester 26 28.12.14 06:09 Сейчас в теме
(47)Не понял где вы там оптимизацию кода увидели.Статья рассказывает как они устроили разработку в соответствии со стандартами принятыми в мире. Когда любое изменение в коде фиксируется, документируется системой автоматически(а значит можно это оформить так как тебе надо, получить состояние системы на любой срез времени, я молчу про ветвления) все этим префиксы и ухищрения покажутся просто лиспедиками.
68. mrdug 759 30.12.14 08:31 Сейчас в теме
(64) webester,
прочитал пункт "Позитивные стороны".

Спасибо, взглянул на эту систему шире, действительно интересно... но нужно что-то чуть попроще, пока что у нее вид - "для богов".
73. webester 26 31.12.14 16:06 Сейчас в теме
(68)Вас просто пугает обилие незнакомых терминов. Вы же программируете не только для 1С? Наверняка есть и другой код и скрипты и тд? Попробуйте засунуть их на гитхаб. И все станет просто сразу. Вот небольшой кусочек из разработки одного моего проекта https://api.monosnap.com/image/download?id=cRYOOlYyAm8gWmckX6ejLObtQlqLDd можно в любой момент поднять изменения по каждой конкретной решаемой задаче. По моему когда работает больше чем один человек, это очень нужно.
75. mrdug 759 04.01.15 19:38 Сейчас в теме
(73) webester,
вы правы, пока что пугает. Если покопаться - можно внедрить, но хочется простоты... мне ведь перед внедрением сначала защитить перед руководством это придется... со всеми вытекающими последствиями :)
30. sergey82vladik 6 24.12.14 10:01 Сейчас в теме
Я в конфигурации создаю специальную подсистему, куда включаю добавленные и измененные объекты.
ZOMI; help1Ckr; blindcat2006; +3 Ответить
31. SPID 24.12.14 10:20 Сейчас в теме
По стандартам разработке 1С разве допускается указания в комментариях даты и имена (инициалы)?
Считаю что указания "кто внес внес изменения и когда" не нужны в коде. Комментарий "что и зачем" к коду бесспорно нужен. Квалифицированный разработчик должен понять по коду и этим комментариям зачем данный код, и нет необходимости привязывать изменения к конкретному разработчику. Дата так же не особо информативна - когда внесены изменения она конечно покажет, но когда эти изменения пришли в продуктивную конфигурацию заказчика врятли. Как правило, учет всех задач/трудозатрат/изменений ведется в какой то еще системе, где и нужно отслеживать кто, зачем, когда и что делал.
32. vano-ekt 123 24.12.14 10:37 Сейчас в теме
(31) а если на проекте 10 разработчиков, работающих с одним объектом? оперативно набрать его по телефону и попросить объясниться за код составит 1 минуту...

//Дата, Сотрудник, Ссылка на ТЗ или на заявку/инцидент с системе регистрации и учета заявок/инцидентов
37. SPID 24.12.14 12:40 Сейчас в теме
(32) vano-ekt, Какая разница сколько разработчиков (и в этом случае нужно использовать хранилище конфигураций). Так же я сомневаюсь что разработчик за минуту вспомнить что же он там такое делала пару месяцев назад.
40. vano-ekt 123 24.12.14 16:55 Сейчас в теме
(37) ви так говорите, будто не сравнивали версии из хранилищ и не знаете сколько занимает это времени)))
когда версий у объекта 100, тяжеловато будет найти сравнением поочередно каждой.
я всё так останусь при своем мнении, что при групповой разработке имя автора полезно указывать в комментариях
42. SPID 24.12.14 17:51 Сейчас в теме
(40) vano-ekt, Сравнивал конечно - хранилище по разработке конфигурации с нуля и историей более чем за два года непрерывной разработки. Согласен - сравнивать версии долго. Хранилище конфигураций вообще вещь странная :) но не об этом.
Но так же я на своем опыте знаю, что спрашивать разработчика о коде который он написал более пары недель назад на 80% бесполезно - он не помнит зачем вносил изменения.
Разработчик может помнить, что и как в коде, если он один занимается постоянно каким-то небольшим ограниченным количеством объектов/подсистемой. Тут наверно подход позвонить разработчику будет актуальным. Но опять же, если и так известно что этот разработчик занимается этим объектом/подсистемой то зачем комментарий с именем в коде...

У Вас часто получается позвонить указанному в комментариях разработчику, и что бы он сразу вам рассказал зачем этот кусок кода?
43. masterkio 334 24.12.14 20:22 Сейчас в теме
(42) SPID, если речь идет о разработке в одной конфигурации нескольких человек, то комментарии об авторстве исправления имеют довольно большое значение, особенно если ведется хоть какой-то контроль качества кода, например если на рабочую конфигурацию выкатывает какой-то ответственный человек. тогда он сразу может понимать к кому относится той или иной кривой код.
Понятно что со временем эти комментарии теряют свой смысл и их можно просто убирать.
44. awk 741 24.12.14 22:39 Сейчас в теме
(43) masterkio, Ну узнали кто разбилдяй и что? Со временем я вижу вот такие комменты:

//{ Сидоров 2014-07-01 удалено
////{ Петров 2013-05-30 Изменено
//////{ Иванов 2011-05-30 добавлено
////...
///Заменен на:
//...
//////}
////}
//}
Показать


Думаете читабельно?
gubanoff; JohnyDeath; succub1_5; ediks; blindcat2006; +5 Ответить
45. mrdug 759 25.12.14 08:34 Сейчас в теме
(44) awk,
вы правы, не читабельно. В посте 43 дан ответ на этот вопрос: "со временем эти комментарии теряют свой смысл и их можно просто убирать".
49. mrdug 759 25.12.14 09:53 Сейчас в теме
(42) SPID,
полностью согласен с вами насчет этого: "спрашивать разработчика о коде который он написал более пары недель назад на 80% бесполезно". ИМЕННО для таких случаев нами сделаны подробные комментарии. По ним то как раз и удается понять что/для чего было сделано!

Что касается ФИО и стандартов: да, возможно стандартами это не предусмотрено, НО, у нас есть производственная необходимость и значит мы имеем полное моральное право это применять. К тому же ничего крамольного в этом нет.

И не смотрите пожалуйста на стандарты как на догму, это всего лишь унификация :)
50. pumbaE 25.12.14 11:18 Сейчас в теме
33. so-quest 140 24.12.14 10:38 Сейчас в теме
Не понял из публикации - извлечение комментариев и построение документации - как-то автоматизировано или руками?
34. tormozit 7136 24.12.14 11:52 Сейчас в теме
Много работал с метаданными и кодом, где были как суффиксы так и префиксы. В итоге для меня однозначно суффиксы имеют больше плюсов, чем префиксы.
35. grand.pers 24.12.14 12:05 Сейчас в теме
статья полезна не только при групповой разработке, но и персональной. дисциплинирует, облегчает. спасибо.
36. dmitry-gr 24.12.14 12:21 Сейчас в теме
Сколько же проблем с организацией разработки и контролю за ней решится когда 1С выпустит eclipse-версию конфигуратора и все эти велосипеды можно будет заменить на отлично зарекомендовавшие себя инструменты!
Теперь по сути:
1. Комментарии в коде конечно важны, только они должны плавно перетекать в комментарии к коммитам, а код стремится к самодокументируемости.
2. Справка или документация важна для пользователя, разработчику надо заглядывать в ТЗ.
3. Страх и ужас! Такая система говорит о прежде всего неумении организовать и каталогизировать собственное рабочее пространство. откройте для себя git
4. Страх и ужас №2! Используйте подсистемы и только их. 1С - скорее вводи расширения!!!
5. Почитайте что такое коде-ревью, какие есть практики и ваш ежемесячный контроль отпадет сам собой.

JohnyDeath; awk; +2 Ответить
51. mrdug 759 25.12.14 11:58 Сейчас в теме
(36) dmitry-gr,
вы мне напоминаете выпускника ВУЗа, без обид :), всё правильно говорите, прям как по учебнику, не поспоришь. НО, это не работает :)

по п.2: справка - это то что находится "под рукой", а попробуйте в условиях отсутствия времени и крайней нервозности пользователей (а в таких условиях работают многие 1с-программисты) - найти ТЗ и ответить на все их вопросы. Думаю у вас это не получится.

по п.3: зачем нам git? чтобы быть модными? наша задача простая: 1. хранить отдельно (диск бэкапируется, ничего не пропадет, всё доступно, описание открывается обычными блокнотами) 2. пронумеровать. Ни для для первого пункта, не для второго нет смысла заводить модную программу.

по п. 4: пункт 2 вы читали? или что-то другое имелось ввиду?

по п. 5: круто! но это немного другая тема, более обширная, и нужная опять таки для крупных предприятий с большим штатом программистов.


53. awk 741 25.12.14 14:58 Сейчас в теме
(51) Система контроля версий (не обязательно git) - это не "модная система", это инструмент грамотного программиста.
54. so-quest 140 25.12.14 15:27 Сейчас в теме
(53)Система генерации документации - тоже инструмент, система тестирования - аналогично. расчет метрик и статический анализ - опять таки - для грамотного программиста придумали. Часто вы это в 1С используете? Если не часто - стали ли вы от этого безграмотным?

И, в принципе, придумал себе ТС набор действий для заполнения пустот во времени - порадуемся за него. А использовать или нет у себя - тут каждый для себя решает.
pumbaE; nihfalck; +2 Ответить
55. awk 741 25.12.14 16:05 Сейчас в теме
(54) so-quest,

1. Использую, часто. :D Так что будет: "если использую часто"? Не увидел ветки.
2. Не он придумал. Он только статью написал. Это все и до него было...
3. Когда заказчик начитавшись таких статей требует, то "каждый решает для себя", не актуально.
56. so-quest 140 25.12.14 16:36 Сейчас в теме
(55) awk, "Использую, часто." - а вот это уже интересней. На чем построено автодокументирование? тестирование? статический анализ? расчет метрик?
58. awk 741 25.12.14 17:33 Сейчас в теме
(56) so-quest,

1. Автодокументирование Doxigen (http://infostart.ru/public/181935/)
2. Тестирование http://infostart.ru/public/180743/
3. 1С:Автоматизированная проверка конфигураций
4. Не использую... Типового нет писать влом.
59. awk 741 25.12.14 18:38 Сейчас в теме
(54) so-quest,
Часто вы это в 1С используете? Если не часто - стали ли вы от этого безграмотным?


Напомнило анекдот:



3 Часа ночи. Звонок в службу поддержки (5 летней девочки).

- Доброй ночи.
- Дяденька, а вы не подскажите как настроить интернет?
- А взрослые рядом есть?
- Есть, но они пьяные.
- Нажимаем кнопку "Пуск"...
- Дяденька, дяденька. Вы не поняли. У меня FreeBSD...

60. so-quest 140 25.12.14 23:31 Сейчас в теме
(59) awk, таких как вы "девочек" было бы побольше... глядишь и стандарты бы появились.
А так... Одна девочка на весь инфостарт - не смешная шутка
ojiojiowka; +1 Ответить
69. mrdug 759 30.12.14 08:38 Сейчас в теме
(53) awk,
тут я пожалуй с so-quest соглашусь. Инструментов придумано немало, но сложность их использования зачастую просто отпугивает. В идеале хочется получить внятные инструменты "вшитые в 1С", а не сторонние программы.
71. awk 741 30.12.14 16:42 Сейчас в теме
(69) Превратив сегодня нормальный читабельный код (8 запросов в пакете), в нечитабельную зеленую массу, я в полной мере прочувствовал ненависть к этому способу документирования изменений. Ждать от 1С очередной "швейцарский топор" можно долго, а результат будет именно швейцарский топор с лезвием для бритья (с вероятностью 99%), а не набор инструментов разработчика. Так что по мне стоит посмотреть в смежные отрасли, почитать, разобраться и прикрутить.
74. mrdug 759 04.01.15 19:29 Сейчас в теме
(71) awk,
у нас есть такие решения, что мне порой сложно глядя в собственный код понять зачем я это сделал... быстро понять... понятно дело что я всё вспомню, но это время, которого иногда нет... поэтому пока всё же склоняюсь к пояснениям в коде...
Это как в автомобиле: я знаю как поменять ремень кондиционера, я знаю где его купить и сколько он стоит, я знаю когда менять его, но я могу забыть что для его замены нужно двигатель домкратить. Небольшой такой нюанс :) Поэтому я хочу в комментах сразу видеть "нужен ли мне домкрат".

насчет 1С согласен полностью, это они "умеют".
EugeneR1c; +1 Ответить
38. masterkio 334 24.12.14 13:25 Сейчас в теме
1.Комментарии слишком объемные. В идеале одна строка в начале исправления, одна в конце. В противном случае у вас вместо кода будет зеленое полотно.
2.Вносить в справочную информацию какие-то технические комментарии вообще неуважение к пользователям. Тут одно из двух либо вы не приучаете пользователей пользоваться справкой, либо вы их попросту не уважаете. Никому не совету пользоваться данным советом.
Справка должна быть актуальной и понятной для пользователя.
3, 4. Эти советы вообще противоречат стандартам разработки - не советую так делать, куча разных префиксов только внесет бардак в дерево конфигурации и будет очень проблематично что-либо в нем искать. Если нужно сохранять информацию о том, кто добавил данный объект можно воспользоваться полем "Комментарий" - он есть у каждого объекта и виден только в конфигураторе.
dima_home; SPID; awk; +3 Ответить
39. awk 741 24.12.14 15:26 Сейчас в теме
(38) masterkio, "Кто добавил" А еще лучше сначала ставить задачу в баг-трекере.. И не лазить по коду выясняя кто задачу поставил и где что и кто исправил...
46. mrdug 759 25.12.14 08:51 Сейчас в теме
(38) masterkio,
1. Объемные > непонятные :)
2. Кто сказал что в справке техническая информация? Там нет жутких малопонятных терминов. И есть два нюанса: 1. пользователь либо умеет читать справку, либо нет 2. Писать нужно как для себя, и стараться муть не разводить. Кстати, многие ссылаются на стандарты 1С, так вот думаю по части справки им до нас - как хромому до Пекина пешком)) уж простите за прямоту!
3. Вы невнимательно прочитали, нас нет кучи разных префиксов, цитирую: "Префикс всегда один и тот же".

41. DAnry 8 24.12.14 17:47 Сейчас в теме
Статья описывает "правильный" подход к внесению изменений в типовую конфигурацию. Хотя на мой скромный взгляд, предлагаемые правила уж слишком объемные и подробные. Впрочем это не догма и каждый вправе сам себе устанавливать правила и принципы...
52. pumbaE 25.12.14 12:12 Сейчас в теме
по п. 5: круто! но это немного другая тема, более обширная, и нужная опять таки для крупных предприятий с большим штатом программистов.

бред, нужна даже если ты один.
JohnyDeath; dmpas; ADirks; Bronislav; awk; help1Ckr; +6 Ответить
70. mrdug 759 30.12.14 08:46 Сейчас в теме
(52) pumbaE,
судя по категоричности вашего заявления - вы один и вы эффективно используете какую-то систему. Расскажите пожалуйста вкратце чем пользуетесь, плюсы и минусы. Или вы теоретизировали?
57. dima_home 238 25.12.14 16:59 Сейчас в теме
1. Префиксы новым объектам - есть такой грешок...ставлю "_" в начало
2. Оформляю код локанично:
для большого куска кода
Процедура ПриИзмененииТЧТовары()
...
//Мое!!! Начало Дима 25.12.2014 v13
//Проверяем максимальное ограничения скидки
Если НЕ СтрокаТовары.Номенклатура.Пустая() Тогда
 ...
КонецЕсли;
//Мое конец Дима
Показать


для малого куска кода
Объект.Ответственный = ?(...); //Мое!!! Дима 25.12.14 БЫЛО: Объект.Ответственный = ...;  


И само-сабой описание функций и процедур
//Мое!!! Дима 25.12.14 Вся функция
//Описание: Выискивает в строке "СтрокаДляПоиска" вырезку ограниченную символом "СимволРазрыва"
//          с порядковым номером "ПорядкНомерОтрезка"
//Возвращает Найденную символьную вырезку, или "" если не нашла по любой причине.
Функция ПолучитьСтрокуМеждуСимволами(СтрокаДляПоиска, ПорядковыйНомерОтрезка, Разделитель=",")
...
КонецФункции //ПолучитьСтрокуМеждуСимволами(СтрокаДляПоиска, ПорядковыйНомерОтрезка, Разделитель=",")
Показать


3. Коментарии при записи в хранилище также незабываю.
61. Yimaida 37 26.12.14 01:08 Сейчас в теме
Буквально сегодня с коллегой разбирались в логике работы одного механизма в сильно допиленной (до нас уже) конфигурации. Нашли ценный, на первый взгляд, комментарий, развернутый такой, на 4 строки. Ну и на радостях подумали, что все тут понятно... Ан нет. Комментарий не соответствовал действительности. Все показала отладка и детальное изучение кода. Выводы, конечно, не сделаешь по одному такому случаю (хотя похожие случаи уже встречались), но на мой взгляд, нужно еще уметь использовать в работе всякие методики подходы и т.п. Да и не всегда интересно делать все "по-правилам", оформлять скучным описанием функции и т.п. Если в коде все работает, то чего туда лезть. Если не работает, то комментарий не будет являться основанием для принятия решения. Я всегда делаю "как для себя". Если есть смысл - пишу комментарий (всегда ставлю дату и имя), пишу справку, могу оформить в ворд с картинками инструкцию, показать по тимвьюверу....
P.S. Тема оформления периодически всплывает на инфостарте, и дискутировать по ней можно долго. Интересно было прочитать почему кто-то использует именно этот инструмент (методику), и какие получает от этого преимущества. (т.е. чисто практика, никакой воды). Отдельное спасибо за ссылки на первоисточники и т.п., считаю это хорошим тоном.
63. Skotarev 15 26.12.14 13:31 Сейчас в теме
Информативно, спасибо, для себя почерпнул что-то
65. psamt1k 28.12.14 23:25 Сейчас в теме
1. Комментарии делаю, но указываю лишь, где
- начало/конец
- кто/когда
- код доработки, например, "д001" (об этом ниже)

2. Более информативно, с моей точки зрения, делать подсистемы.
Например, есть общая подсистема "Префикс_ВнесенныеИзменения".
А "в ней", есть подчиненные подсистемы вида "д001_АвтоформированиеДокумента", где
"д" - это значит доработки (еще есть "и" - изменение типового функционала)
"001" - порядковый номер.
"АвтоформированиеДокумента" - краткое описание доработки.
Далее в составе этой подсистемы указываются объекты, которые менялись/добавлялись, а в справочной информации более детально описывается задача.

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

Из "минусов": данный подход не работает с версиями 8.1 и ниже, где не было понятия "Подсистемы".
66. maxdk9 29.12.14 10:33 Сейчас в теме
По поводу комментов уже давно все написано у Мартина (Чистый код). Когда принимаешь конфу от комментов "Писано 01.01.01 у большого сборного дуба святым причетником из Компенхерсте" рябит в глазах. Один раз посчитал -принял обработку импорта из аксапты -удалил все комменты типа "писано темто" и закомментированный код. Убрал 1700 строк из 6000 в модуле объекта.

Кстати пример 3 -коммент не нужен. В принципе. Там из кода все должно быть понятно.
67. mrdug 759 30.12.14 08:20 Сейчас в теме
(66) maxdk9,
к сожалению не все люди умеют быстро понимать код аля "запрос с 8-ю вложенными таблицами", в таких случаях то, что писал "святой причетник из Компенхерсте" часто выручает :)
72. Иной 30.12.14 16:52 Сейчас в теме
=). Опираясь на свой не очень то и большой опыт в программировании (где-то лет 5) могу предположить, что более-менее человеческий комент можно оформить только на последнее изменение. Ибо оно может существенно покорежить чьи-то предидущие коменты. Сохранить всю историю изменений можно только сохраняя фрагменты кода (а лучше полностью конфигурацию) вовне.
Веду версионный учёт конфигураций. Уже много раз помогало =). Просто перед внесением в конфу правок сохраняю пекущую конфигураци. Нуменрую конфигурации. А в коментировании изменений держим приоритет на объяснение изменения, а не сохранении истории изменений. История в архиве конфигураций хранится =).

Где-то так.
77. МимохожийОднако 141 07.01.15 21:38 Сейчас в теме
Одно время, когда работал с 77, вставлял в конфигурацию отдельный отчет с фрагментами кода и комментариями, в котором описывал реализованные задачи и внесенные изменения по ним. Там же писал инструкцию сам себе последовательность накатывания обновлений, чтобы не затереть свои наработки.. По структуре этот отчет был аналогичен дополнению к описанию, но по отдельному пункту меню. Это помогало вспомнить что к чему после продолжительного времени и облегчало обновления.
78. Yashazz 4709 08.01.15 12:30 Сейчас в теме
Опять описание кучи костылей, вызванных к жизни отсутствием соответствующего инструментария в среде разработки... Грустно это всё.
79. wowkai 4 11.01.15 20:23 Сейчас в теме
Интересная и полезная методика. Автору респект.
до 1 пункта сами дошли, а вот 2-3 как раз искали как бы получше сделать
80. adapter 417 12.01.15 11:03 Сейчас в теме
73 звезды..... Статья из серии Капитана Очевидность - хочешь потом разобраться описывай сейчас. Чем лучше камент в коде тем удобнее © Кличко. А уж в текстовых файликах все держать или в вордовых уже не важно. ИМХО удобнее всего делать доработки чтобы в 80% обновлений они вообще не мешались, а в 20 использовать ссылки на внешнюю базу данных техподдержки (как и сказали выше).
Единственный плюс статьи - показать важность момента, тем кто до этого еще пока не дошел. Ну и если уж про опыт, то предлагаю размяться от обратного:

1. куча франчей и фикси меняется в конфе за несколько лет. В итоге получаем "специалистов", которым надо объяснять про каменты в коде....
Заказчику стоит пересмотреть кадровую политику. ГБ и и дир тоже меняется несколько раз в год? Может они тоже для себя систему тайных записей придумают?
Хотя рыба гниет с головы, возможно на первом пункте лучше все и закончить. Пристрелить эту старую лошадь, чтобы не мучалась.

2. Справочная информация.
судя по рассказанному справочная система отсутствует. Набор лоскутных текстовых файликов... это лучше чем ноль, но меньше чем необходимо. Справка должна быть полная, внятная, со скриншотами, взаимосвязями. Иначе техподдержка будет требоваться постоянно (покрасневший телефон). Даже на базе типовой конфы должна быть справочная система, которая описывает все изменения. Организовать ее можно кучей способов, например:
- встроить в конфу свой справочник, который содержит описания, организовать удобный вывод пользователю
- Внутренний сайт базы знаний, из конфы кнопка которая открывает ссылку. Простейший вариант - на сервере 1С ставим appserv + wordpress. Сайт можно поделить разделами под каждую БД 1С
- на сетевом диске положить файл (word\pdf\html\*..), открывать кнопкой из конфы.

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

3. Техподдержка.
Если по обращению пользователя можно переписать отчет полностью, значит нет у вас ТПД. Есть программеры, которых заставляют работать на ТПД. Песня про бегуна на короткие дистанции, которого заставили бежать на длинные.... а он не хотел. © Высоцкий

Если нет 1 и 2, то 3 могло бы решить проблему. 1,2,3 это три черепахи на которых стоит ИТ система. Хватит штукатурить здание в котором нет фундамента.
81. webester 26 12.01.15 16:11 Сейчас в теме
(80)
73 звезды.... Статья из серии Капитана Очевидность

Это вы еще статей про то как добавить на форму переключатель(111) не видели, или про то как пользоваться винраром(всего 24 но каков размах мысли). По сравнению с ними статья на уровне 80лвл по "экспертности".
83. mrdug 759 18.01.15 14:59 Сейчас в теме
(80) adapter,
спасибо за содержательный ответ, критика у нас приветствуется :) Отвечать не буду, вы увидели то что хотели увидеть.... к сожалению.

82. Stim213 415 15.01.15 11:08 Сейчас в теме
Комментарии в коде это само по себе хорошо, а вот ведение хранилища разработки с обязательным заполнением комментариев при помещении измененного объекта в хранилище - это еще лучше.
84. mrdug 759 18.01.15 15:03 Сейчас в теме
ДАМЫ И ГОСПОДА!
Я благодарю вас за то, что приняли участие в обсуждении этого вопроса! Ваше мнение, даже если оно кардинально отличалось от моего, было мне очень интересно.

Да, эта система не идеальна. Да, есть вещи более профессиональные. Да, что-то в ней можно и нужно пересмотреть... НО, это всего лишь набор приемов, главное же в этой статье - привлечь ваше внимание к этой проблеме. Проблеме которую можно охарактеризовать фразой: "после нас - хоть трава не расти".

Прошу вас, думайте о своем завтрашнем дне, о комфорте в работе, о вашей эффективности, о вашем развитии, и наконец о людях которые придут вам на смену! Вот что главное в этой статье!
w22u; dj_serega; marsovna; k4rimov; Cat43r; +5 Ответить
85. Артано 760 26.08.20 02:08 Сейчас в теме
С благими желаниями согласен, но в 12м году уже было хранилище. Знаю точно, так как в 1с пришел в 11м году. Тот фарш который образуется в коде по вашей системе комментирования не может ничем хорошим уже перекрыт. Ставлю минус.

Комментарий нужен не для фиксации факта правки - для этого есть системы контроля версий. Комментариями описывается то, что не является очевидным при прочтении кода посторонним человеком.
86. mrdug 759 29.10.20 12:50 Сейчас в теме
(85) покажите мне тех кто пользуется системами контроля версий? единицы. на 99% предприятий их просто нет.
87. Артано 760 30.10.20 02:01 Сейчас в теме
(86) Хранилище 1с, как наиболее примитивная из упомянутых систем используется, вероятно везде
89. mrdug 759 03.11.20 11:19 Сейчас в теме
(87) извините, вы меня рассмешили)))) вы наверное теоретик 1С, без обид)))) я вам точно говорю, 99% предприятий НЕ используют хранилище - это просто бессмысленно, трата времени и ничего больше. Люди сидят на своих базах и знают их вдоль и поперек, и "делиться" информацией об этом они тоже не будут, и поддерживать хранилище им тоже не интересно, и времени у них на эти телодвижения тоже нет.
88. FatPanzer 30.10.20 08:11 Сейчас в теме
(86) Я даже когда в одно рыло работал (не групповая разработка) - и то всегда разворачивал хранилище. Именно для контроля версий.
so-quest; Артано; +2 Ответить
90. mrdug 759 03.11.20 11:28 Сейчас в теме
(88) я тоже работал с хранилищем, и у нас на предприятии оно стоит, и мы с ним работали одно время, только сейчас им уже никто не пользуется. Потому что времени на него нет. В те времена когда программистов было много и можно было в носу ковырять неспеша, да, им пользовались. А сейчас "все для фронта все для победы": минимум ТЗ и бюрократизма, гибкие методологии разработки используются в полный рост, все отвлекающие факторы отбрасываются, все вспомогательные проекты типа хранилища, итилиума и прочее законсервированы. Работать надо, а не хранилище вести.
Плюс вы свои разработки в конфе найдете обычным способом гораздо быстрее, и откатываться на другие версии врятли будете, 1С не та система где это прокатывает, проще закомментировать код прям на месте изменения и потом при случае посмотреть в чем отличие вашей версии от той что была, нежели откатываться на прошлую и прочие умные штуки делать. И это с учетом того что с базой работают несколько программистов.
91. Артано 760 08.11.20 10:53 Сейчас в теме
(90) Вы описываете хаос и анархию как преимущество. Но в результате таких подходов конфигурация приходит в несопровождаемое состояние и "bus factor" становится критическим. В моей истории есть опыт, где человек, раскаявшись наконец, и решив начать учиться профессиональной разработке, а не костылингу на коленке, потом долго не мог уволиться - его просто не отпускали вплоть до угроз расправой. Ибо конфу сопровождать было почти невозможно, вменяемых программистов в отдел было не найти. Даже если человек и устраивался по ошибке, то разобравшись что к чему писал заявление. К счастью для того парня, что хотел уволиться, решение в итоге было найдено. Но компании оно стоило на порядок больше, чем экономия на отказе от хранилища и дополнительных работ по поддержанию качества кода. Хотя я так и не понял где там экономия времени, если просветите тёмных теоретиков, то буду благодарен.

P.S. Просто закомментить старый код - сколько нервов я потратил скролля тысячи строк закоменнтированного кода в попытке найти код действующий. Горите в аду!
o.nikolaev; FatPanzer; +2 Ответить
92. FatPanzer 08.11.20 11:31 Сейчас в теме
(91) В моей практике пришлось тупо перевнедряться с нуля. Никто не думает о последствиях при программировании. Никаких стратегических решений, только сиюминутные "все для фронта, все для победы", ага...
o.nikolaev; +1 Ответить
100. mrdug 759 03.12.21 14:15 Сейчас в теме
(91)думаю если посмотрите наши базы, то вы измените свое мнение))
прошло семь лет, я описал в (99) что изменилось за это время. А если в двух словах то: все что тут описано это по сути тактические приемы, при глобальной разработке конечно требуются хранилище и прочее. Но вот что интересно, в наших базах порядка и понятности больше (в разы больше), чем в тех что я видел на хранилищах.
101. Артано 760 04.12.21 15:59 Сейчас в теме
(100) А вы просто лукавите. Я ведь в своём предложении не только про хранилища писал. Хранилище это всего лишь средство хранения истории версий и облегчение совместной разработки. Так то, я и в ООП проектах видел, что люди СП не знают. Так что пример опирающийся только на использование или отказ от хранилища, мягко говоря, ни о чем не говорит.

Про сообщение предыдущее. Ну вы опять лукавите. Если какая-то логика обработки данных хранится у вас в коде и требует сохранения всей истории кода в виде закомментированного кода для её понимания, то "bus factor" висит над вами дамокловым мечом.

По своим подходам, как понятно, не раскаиваюсь. Мнение не поменялось, скорее наоборот укрепилось. Иллюстраций с тех пор насмотрелся в разы больше.
98. o.nikolaev 211 24.11.21 11:41 Сейчас в теме
(90) Создатель, какой ужас. Можно узнать - жива еще база и конфигурация, которая "дорабатывается" вот таким образом?
99. mrdug 759 03.12.21 14:01 Сейчас в теме
(98) расскажу про наши конфигурации, прошло семь лет результат вот такой:

1. Комментарии в коде (единственное внятное средство вспомнить кто и зачем всё это сделал когда уже все забыли).
2. Справочная информация (сейчас перешла на подсказки полей и отдельные закладки на форме, так ближе к пользователю).
3. Цифровые обозначения отчетов/обработок (имба до сих пор, говоришь цифру и всем все понятно).
4. Добавление/изменение объектов (тоже рабочая тема, префикс стал короче, но всегда используется, сразу понимаешь чей объект).
5. Контроль за исполнением (контроль сейчас не выполняется, будущее наступило).
------------------------------------
А теперь про штатные средства:
- EDT для богов
- хранилище используется когда людей много и совсем друг друга не знают
- Git это чтобы себя успокоить, как правило ни у кого времени на него нет.
------------------------------------
И вот что получается: наши так называемые "поделки" до сих пор успешно применяются и все также выручают, пока чьи-то космические корабли все еще бороздят просторы мирового океана, а люди тем временем спорят и умничают о их применении.
102. o.nikolaev 211 08.12.21 00:04 Сейчас в теме
(99) А что это за конфигурации? Что они автоматизируют?
Оставьте свое сообщение