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

Публикация № 292511

Разработка - Практика программирования

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

102
Что важно для руководителя 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... Что будет если уйдут программисты (или пользователи) "носители знаний"? Если возникнет разбирательство кто, зачем, когда внедрил функционал? Если нужно быстро провести ревизию конфигурации? Как быстро передать информацию другим специалистам?

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

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

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

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

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

102

Специальные предложения

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

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

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

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

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

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

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

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

- было, неделю назад, именно такими словами
9. chmv 19.12.14 16:19 Сейчас в теме
А я отбираю по своей фамилии и ищу что я меняла
10. gubanoff 46 19.12.14 16:39 Сейчас в теме
(9) chmv, для вашего случая это нормально. А когда несколько программистов дорабатывают конфигурацию, плюс кто-то из них периодически меняется, то эффекта от фамилий в коде ноль.
11. Sander80 77 19.12.14 23:30 Сейчас в теме
Советы очень хорошие, но чего мне лично не хватило здесь, это использования хранилища.
В нем как минимум видно, кто из разработчиков в последний раз правил тот или иной отчет.
А если еще и административно затребовать от всех писать комментарии к коммитам (при сдаче в хранилище), то, возможно, и комментарии в коде не нужны.
talych; Чарик; Aleskey_K; zaursoft; Rego1337h; Герасим; bforce; dimisa; help1Ckr; awk; pythonchik; alexscamp; monkbest; +13 Ответить
16. mrdug 718 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 Сейчас в теме
Ещё удобно номер задачи(тикета) указывать в комментариях. Если изменения в рамках одной задачи будут в нескольких модулях форм, объектов итд.
Можно быстро найти глобальным поиском во всей конфигурации все модули в которые вносились изменения в рамках одной задачи. Экономит время.
talych; zaursoft; Герасим; gradi; dima_home; help1Ckr; Hellisad; h00k; alexscamp; monkbest; +10 Ответить
22. mrdug 718 22.12.14 21:08 Сейчас в теме
(17) TODD22,
насчет номера задачи: у нас эту роль выполняет первая строка комментария, она уникальна: дата+заказчик+краткое название задачи. Можно искать просто по названию задачи, будет тоже самое.
19. dyak84 22.12.14 12:09 Сейчас в теме
C Автором согласен на 100%. Порядок должен быть везде. Ну конечно есть нюансы когда описать сложно., но пытатся нужно всегда. И на мой взгляд грамотный коментарий самое то. Ну и отношение тут всегда должно быть на высоте.Но как говорится каждый должен начать из себя.!!!!!!!!!!!
ojiojiowka; +1 Ответить
20. mikmike 5 22.12.14 14:31 Сейчас в теме
Писать комментарии и справки нужно обязательно - зачастую это помогает четко все сформулировать.
Я проставляю в комментарии отчета номер версии, а в справке - историю версий, сразу за описанием.
dima_home; +1 Ответить
21. sweeex 10 22.12.14 19:07 Сейчас в теме
Толковые советы, только напряжно писать описалово в коде, так как за несколько год будет каша малаша, исправляя код постоянно исправлять описалово везде, можно где то и забыть исправить.
23. mrdug 718 22.12.14 21:11 Сейчас в теме
(21) sweeex,
каша будет если в коде описалова нет. Проверено)))
24. unichkin 23.12.14 00:02 Сейчас в теме
Не захотел ИС мой код из разукрашки есть, вот рисунок тогда...
Прикрепленные файлы:
ojiojiowka; +1 Ответить
25. Иной 23.12.14 00:58 Сейчас в теме
Хороший пост.

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

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

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

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

У Вас часто получается позвонить указанному в комментариях разработчику, и что бы он сразу вам рассказал зачем этот кусок кода?
43. masterkio 207 24.12.14 20:22 Сейчас в теме
(42) SPID, если речь идет о разработке в одной конфигурации нескольких человек, то комментарии об авторстве исправления имеют довольно большое значение, особенно если ведется хоть какой-то контроль качества кода, например если на рабочую конфигурацию выкатывает какой-то ответственный человек. тогда он сразу может понимать к кому относится той или иной кривой код.
Понятно что со временем эти комментарии теряют свой смысл и их можно просто убирать.
44. awk 692 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 718 25.12.14 08:34 Сейчас в теме
(44) awk,
вы правы, не читабельно. В посте 43 дан ответ на этот вопрос: "со временем эти комментарии теряют свой смысл и их можно просто убирать".
49. mrdug 718 25.12.14 09:53 Сейчас в теме
(42) SPID,
полностью согласен с вами насчет этого: "спрашивать разработчика о коде который он написал более пары недель назад на 80% бесполезно". ИМЕННО для таких случаев нами сделаны подробные комментарии. По ним то как раз и удается понять что/для чего было сделано!

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

И не смотрите пожалуйста на стандарты как на догму, это всего лишь унификация :)
50. pumbaE 628 25.12.14 11:18 Сейчас в теме
33. so-quest 130 24.12.14 10:38 Сейчас в теме
Не понял из публикации - извлечение комментариев и построение документации - как-то автоматизировано или руками?
34. tormozit 5621 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 718 25.12.14 11:58 Сейчас в теме
(36) dmitry-gr,
вы мне напоминаете выпускника ВУЗа, без обид :), всё правильно говорите, прям как по учебнику, не поспоришь. НО, это не работает :)

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

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

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

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


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

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

1. Использую, часто. :D Так что будет: "если использую часто"? Не увидел ветки.
2. Не он придумал. Он только статью написал. Это все и до него было...
3. Когда заказчик начитавшись таких статей требует, то "каждый решает для себя", не актуально.
56. so-quest 130 25.12.14 16:36 Сейчас в теме
(55) awk, "Использую, часто." - а вот это уже интересней. На чем построено автодокументирование? тестирование? статический анализ? расчет метрик?
58. awk 692 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 692 25.12.14 18:38 Сейчас в теме
(54) so-quest,
Часто вы это в 1С используете? Если не часто - стали ли вы от этого безграмотным?


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



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

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

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

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

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

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


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


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


3. Коментарии при записи в хранилище также незабываю.
61. Yimaida 35 26.12.14 01:08 Сейчас в теме
Буквально сегодня с коллегой разбирались в логике работы одного механизма в сильно допиленной (до нас уже) конфигурации. Нашли ценный, на первый взгляд, комментарий, развернутый такой, на 4 строки. Ну и на радостях подумали, что все тут понятно... Ан нет. Комментарий не соответствовал действительности. Все показала отладка и детальное изучение кода. Выводы, конечно, не сделаешь по одному такому случаю (хотя похожие случаи уже встречались), но на мой взгляд, нужно еще уметь использовать в работе всякие методики подходы и т.п. Да и не всегда интересно делать все "по-правилам", оформлять скучным описанием функции и т.п. Если в коде все работает, то чего туда лезть. Если не работает, то комментарий не будет являться основанием для принятия решения. Я всегда делаю "как для себя". Если есть смысл - пишу комментарий (всегда ставлю дату и имя), пишу справку, могу оформить в ворд с картинками инструкцию, показать по тимвьюверу....
P.S. Тема оформления периодически всплывает на инфостарте, и дискутировать по ней можно долго. Интересно было прочитать почему кто-то использует именно этот инструмент (методику), и какие получает от этого преимущества. (т.е. чисто практика, никакой воды). Отдельное спасибо за ссылки на первоисточники и т.п., считаю это хорошим тоном.
63. Skotarev 9 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 718 30.12.14 08:20 Сейчас в теме
(66) maxdk9,
к сожалению не все люди умеют быстро понимать код аля "запрос с 8-ю вложенными таблицами", в таких случаях то, что писал "святой причетник из Компенхерсте" часто выручает :)
72. Иной 30.12.14 16:52 Сейчас в теме
=). Опираясь на свой не очень то и большой опыт в программировании (где-то лет 5) могу предположить, что более-менее человеческий комент можно оформить только на последнее изменение. Ибо оно может существенно покорежить чьи-то предидущие коменты. Сохранить всю историю изменений можно только сохраняя фрагменты кода (а лучше полностью конфигурацию) вовне.
Веду версионный учёт конфигураций. Уже много раз помогало =). Просто перед внесением в конфу правок сохраняю пекущую конфигураци. Нуменрую конфигурации. А в коментировании изменений держим приоритет на объяснение изменения, а не сохранении истории изменений. История в архиве конфигураций хранится =).

Где-то так.
77. МимохожийОднако 129 07.01.15 21:38 Сейчас в теме
Одно время, когда работал с 77, вставлял в конфигурацию отдельный отчет с фрагментами кода и комментариями, в котором описывал реализованные задачи и внесенные изменения по ним. Там же писал инструкцию сам себе последовательность накатывания обновлений, чтобы не затереть свои наработки.. По структуре этот отчет был аналогичен дополнению к описанию, но по отдельному пункту меню. Это помогало вспомнить что к чему после продолжительного времени и облегчало обновления.
78. Yashazz 2889 08.01.15 12:30 Сейчас в теме
Опять описание кучи костылей, вызванных к жизни отсутствием соответствующего инструментария в среде разработки... Грустно это всё.
79. wowkai 4 11.01.15 20:23 Сейчас в теме
Интересная и полезная методика. Автору респект.
до 1 пункта сами дошли, а вот 2-3 как раз искали как бы получше сделать
80. adapter 514 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 29 12.01.15 16:11 Сейчас в теме
(80)
73 звезды.... Статья из серии Капитана Очевидность

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

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

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

Прошу вас, думайте о своем завтрашнем дне, о комфорте в работе, о вашей эффективности, о вашем развитии, и наконец о людях которые придут вам на смену! Вот что главное в этой статье!
w22u; dj_serega; marsovna; k4rimov; Cat43r; +5 Ответить
Оставьте свое сообщение

См. также

Приватный блокчейн и 1С популярно 6

Статья no Нет файла Бесплатно (free) Практика программирования Блокчейн

Две предыдущие публикации на эту тему были сфокусированы преимущественно на технической стороне вопроса. Кроме того, их содержание оказалось понятным не каждому специалисту. В этой статье я постараюсь обяснить для всех и, что говорится, «на пальцах»: что такое приватный блокчейн, когда и зачем его следует применять и на что обратить внимание при использовании этой технологии в 1С.

02.09.2019    1899    mkalimulin    140       

Кодогенерация и метагенерация в 1С 26

Статья Программист Нет файла Бесплатно (free) Практика программирования Математика и алгоритмы Разработка

В своем докладе на конференции INFOSTART EVENT 2018 EDUCATION Дмитрий Белозеров рассказал о разработке инструмента, позволяющего программно работать с метаданными 1С и писать скрипты для выполнения тех же действий, которые выполняет разработчик в конфигураторе –  с какими сложностями и нюансами пришлось столкнуться, и что получилось в итоге.

26.08.2019    4554    kirovsbis    28       

Интеграция сценарного тестирования в процесс разработки 81

Статья Программист Нет файла Бесплатно (free) Практика программирования Разработка

Разработчик системы «Тестер» Дмитрий Решитко в своем докладе на конференции INFOSTART EVENT 2018 EDUCATION показывает, что процесс тестирования можно очень плотно интегрировать в процесс разработки, что внедрение тестирования – это возможность развития программиста как такового, позволяющая ему упорядочивать ход мыслей и оставаться «в фокусе». Навыки построения процесса кодирования на стыке с тестированием сокращают время на концентрацию, освобождают от страха перед изменениями и улучшают память разработчика.

08.07.2019    4946    grumagargler    7       

Управляй качеством кода 1С с помощью SonarQube 239

Статья Программист Нет файла Россия Бесплатно (free) Практика программирования

Управляй техническом долгом проектов 1С с помощью SonarQube. В статье рассматривается пример применения SonarQube при разработке.

07.07.2019    18895    olegtymko    197       

Выгрузка документа по условию 5

Статья Программист Нет файла v8 Бесплатно (free) Практика программирования Разработка

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

25.04.2019    6397    m-rv    2       

Как прикрутить ГУИД к регистру сведений 23

Статья Программист Нет файла v8 Бесплатно (free) Практика программирования Перенос данных из 1C8 в 1C8 Разработка

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

16.04.2019    9049    m-rv    16       

О времени и 1С 208

Статья Программист Нет файла Бесплатно (free) Практика программирования Разработка

Основы и особенности работы со временем в 1С. Как избавиться от боли при работе в разных часовых поясах. Что такое момент времени. И другое.

01.04.2019    17428    YPermitin    59       

Пример создания bridge (http api - tcp) для ККТ "Касса №1" ("К1-Ф") 5

Статья Системный администратор Программист Нет файла Россия Кассовые операции Бесплатно (free) Практика программирования Разработка ККМ

Пример создания bridge (http api - tcp) для ККТ "Касса №1" ("К1-Ф"). Данная статья будет полезна интеграторам, программистам, тем кто работает (интегрирует, разрабатывает) различное ТО либо железки. Версия и релиз технологической платформы не имеет значения.

17.03.2019    3346    dmarenin    0       

Быстрее чем INSERT! BULK-операции и примеры использования 112

Статья Системный администратор Программист Нет файла Бесплатно (free) Производительность и оптимизация (HighLoad) Практика программирования Разработка Внешние источники данных Перенос данных из 1C8 в 1C8

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

09.03.2019    11144    YPermitin    38       

Как писать понятные коммиты 68

Статья Программист Нет файла Россия Бесплатно (free) Практика программирования Разработка

Как писать сообщения коммитов так, чтобы потом не было мучительно больно.

06.03.2019    8354    Scorpion4eg    35       

Расширяем свой багаж 2

Статья Программист Нет файла Бесплатно (free) Практика программирования Разработка

Алгоритм решения возможной нетиповой задачи на собеседовании.

29.01.2019    3687    scientes    15       

Подготовка ребёнка* к ЕГЭ по информатике. Часть четвертая 4

Статья Программист Нет файла Бесплатно (free) Практика программирования Разработка

Решение систем логических уравнений повышенного уровня сложности.

25.01.2019    3391    vasilev2015    0       

Подготовка ребенка* к ЕГЭ по информатике. Часть вторая 2

Статья Программист Нет файла Бесплатно (free) Практика программирования

Примеры на Паскале. Если сам родитель* - поддержи ! Если сам водила - посигналь !

19.01.2019    3786    vasilev2015    0       

Подготовка к ЕГЭ сына - школьника (по информатике) 9

Статья Программист Нет файла Бесплатно (free) Практика программирования

Примеры на Паскале. Если сам отец - поддержи ! Если сам водила - посигналь !

17.01.2019    4206    vasilev2015    50       

Быстрая отладка экранных форм документов и справочников 19

Статья Программист Нет файла Бесплатно (free) Практика программирования

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

18.12.2018    4931    milkers    19       

1С + asterisk (автоматический обзвон) часть 1 38

Статья Системный администратор Программист Нет файла Россия Бесплатно (free) Практика программирования WEB Телефония, SIP

Пример реализации автообзвона (с обработкой ответа на отвечающей стороне) с использованием ami asterisk. Данная статья может быть полезна программистам, интеграторам, администраторам. Версия и релиз технологической платформы не имеет значения.

29.11.2018    7862    dmarenin    9       

Автоматические и управляемые блокировки применительно к типовым конфигурациям 1С 127

Статья Программист Нет файла v8 v8::blocking 1cv8.cf Бесплатно (free) Математика и алгоритмы Практика программирования

Основные принципы работы с режимами автоматических и управляемых блокировок в 1С Предприятие 8. Теория и применение в типовых конфигурациях: БП, УТ, ЕРП

10.11.2018    22553    ids79    40       

Развитие 1С программиста 51

Статья Программист Нет файла Бесплатно (free) Практика программирования Личная эффективность

Делюсь своим опытом и видением развития 1С программиста.

17.10.2018    14663    pashamak    62       

Вспомогательные инструкции в коде 1С 106

Статья Программист Нет файла v8 1cv8.cf Бесплатно (free) Практика программирования

Помогаем редактору кода 1С помогать нам писать и анализировать код.

15.10.2018    21729    tormozit    100       

Записки про metadata.js 54

Статья Программист Нет файла Бесплатно (free) Практика программирования

Отличительные особенности разработки на metadata.js

31.07.2018    9721    1c-intelligence    59       

Учебный курс. Повышение качества разработки. Ошибки программы 97

Статья Программист Нет файла Бесплатно (free) Практика программирования Математика и алгоритмы Рефакторинг и качество кода

Учебный курс по теории и практике программирования. Бесплатно. В виде структурированного текста. Лекции № 3,4,5. Эти лекции посвящены ошибкам программ, их классификации и способам исправления

10.07.2018    16326    Артано    92       

Автоматизируй это! 150

Статья Системный администратор Программист Нет файла Бесплатно (free) Практика программирования

Здравствуйте. Меня зовут Виталий Онянов. Я работаю в компании ФТО. Мы занимаемся внедрением и поддержкой ERP-систем, в том числе и на 1С. Сегодня я хотел бы поделиться нашим опытом автоматизации своих задач и рассказать о том, какие регламентные задания мы настраиваем на серверах наших клиентов. Возможно, кому-то покажется, что это совсем простые и очевидные вещи, но я в своей работе периодически вижу разработчиков, которые делают какие-то задачи руками изо дня в день, и мне бы хотелось донести до них мысль о том, что многие из этих задач можно и нужно автоматизировать.

02.07.2018    16810    Tavalik    12       

Повышаем эффективность разработки правил обмена 125

Статья Программист Нет файла v8 КД ОС Бесплатно (free) Практика программирования Перенос данных из 1C8 в 1C8

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

25.06.2018    20496    olegtymko    47       

Как сделать запрос на изменение данных 75

Статья Программист Нет файла v8 v8::Запросы 1cv8.cf Бесплатно (free) Практика программирования

В статье приведены особенности внутренней архитектуры и примеры работы с расширением языка запросов 1С.

01.06.2018    22437    m-rv    21       

Учебный курс. Повышение качества разработки. Вводная лекция, часть 2 49

Статья Программист Нет файла Бесплатно (free) Практика программирования Математика и алгоритмы

Учебный курс по теории и практике программирования. Бесплатно. В виде структурированного текста. Лекция №2. Эта лекция посвящена абстракциям, их свойствами и практическому применению в рамках классических парадигм программирования.

24.05.2018    11140    Артано    36       

Строим графы средствами 1С (без GraphViz) 43

Статья Программист Нет файла v8 Бесплатно (free) Практика программирования

Множество статей на Инфостарте описывают, как работать с компонентой GraphViz, чтобы построить ориентированный граф. Но практически нет материалов, как работать с такими графами средствами 1С. Сегодня я расскажу, как красиво строить графы с минимальным пересечением. Нам этот метод пригодился для отрисовки алгоритмов в БИТ.Финансе, т.к. типовой механизм не устраивал. Еще это может быть полезно для визуализации различных зависимостей: расчета себестоимости, графы аффилированности компаний и т.д. Надеюсь, эта статья поможет сделать мир 1С красивее и гармоничней:) Итак, поехали...

23.05.2018    18211    slozhenikin_com    19       

Распределение расходов пропорционально продажам 9

Статья Программист Пользователь Нет файла v8 v8::ОУ УТ10 УУ Финансовый учет и бюджетирование (FRP) Учет доходов и расходов Бесплатно (free) Практика программирования

Финансовая модель. Распределение административных расходов по подразделениям пропорционально продажам за месяц. Дополнительные реквизиты против бизнес-процессов!

13.05.2018    12232    Rustig    9       

Велостыли: Регламентные задания 17

Статья Программист Нет файла Россия Бесплатно (free) Практика программирования

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

09.05.2018    10700    dsdred    28       

Веб-разработка на 1Script. Глава 2 64

Статья Программист Нет файла Бесплатно (free) Практика программирования WEB

Продолжение учебника по веб-разработке с помощью фреймворка Oscript.Web. Структура приложения, основные объекты, URL-маршрутизация, универсальная консоль серверов 1С.

22.04.2018    12596    Evil Beaver    27       

Доброе программирование, или сказки для программистов 8

Статья Программист Нет файла Бесплатно (free) Практика программирования

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

03.03.2018    6517    Gladkov_Anton    9       

Минимализмы 3 356

Статья Программист Нет файла v8 Бесплатно (free) Практика программирования Универсальные функции

Очередная серия "минимализмов" [http://infostart.ru/public/306536/, https://infostart.ru/public/460935/]. Также, как и в предыдущих статьях, здесь приведена подборка коротких оригинальных авторских решений некоторых задач. Ранее эти решения были разбросаны по моим комментариям к чужим публикациям.

19.02.2018    37466    ildarovich    44       

Веб-разработка на 1Script. Глава 1 251

Статья Программист Нет файла Бесплатно (free) Практика программирования

Разрабатывать веб-приложения должно быть просто. И для этого 1С-ник не должен страдать, изучая десятки и сотни побочных технологий. В конце прошлого года я анонсировал разработку движка веб-приложений на языке 1С. Я планирую выпустить серию статей, оформленных в виде книги, или серии блог-постов, в которых постепенно будут описаны методики разработки сайтов на нашем любимом языке программирования – 1С.

12.02.2018    26234    Evil Beaver    97       

Версионирование правил обмена в Git 65

Статья Программист Нет файла Windows Бесплатно (free) Практика программирования

Статья рассказывает о принципах работы скриптов, позволяющих применять систему контроля версий git и подход gitflow для версионирования правил обмена.

15.12.2017    13313    bforce    22