gifts2017

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

Опубликовал Олег Смирнов (mrdug) в раздел Программирование - Практика программирования

Что важно для руководителя 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. Andrey Moskvin (mmoozzgg) 19.12.14 12:12
все супер, а не мало 2 знака для номеров по порядку?

зы у себя в компании мы еще номера макетам присваиваем и печатаем их вместе с датой последнего изменения отчета/обработки
2. Александр Губанов (gubanoff) 19.12.14 14:37
1. по поводу комментариев: а как быть, если изменения по одному вопросу затрагивают несколько модулей, форм, макетов, объектов? Когда происходит рефакторинг кода? Лично меня даты и фамилии программистов в коде всегда умиляли. Они бесмысленны. По прошествии n-лет мне глубоко безразлично кто и каким числом написал кусок кода, если он не работает, то его нужно переписать и все. Более-менее уместна идея в комментариях писать номер замечания из учетной системы задач. А уже в учетной системе будет виден заказчик, дата, описание задачи и т.п. Но это тоже работает процентов на 50, не более.
2. Заказчики в справке - это тоже умиляет. Если их хотя бы больше 10, то это уже будет проблемой.
3. Номера отчетов - идея нормальная.
4. Префиксы у объектов - идея нормальная.
5. Контроль за исполнением - это хорошо. Именно из-за низкой исполнительской дисциплины или из-за отсутствия контроля за исполнением все предыдущие пункты и не будут работать. Или будут.
Designer1C; awk; +2 Ответить 2
3. Марина Чирина (chmv) 19.12.14 14:43
А мне фамилия в комментарии очень удобна. Я делаю поиск по ней
4. Марина Чирина (chmv) 19.12.14 14:43
5. Александр Губанов (gubanoff) 19.12.14 15:34
(3) chmv, ну отобрали по фамилии, ну увидели, что это был некий Пупкин, уволенный 2 года назад. Что эта информация вам дает? Сделать на основании нее вывод, валиден код или нет невозможно.
6. Brr (brr) 19.12.14 15:55
Префиксы в именах метаданных зло! Я за суфиксы :)
burlakov; sashocq; zaursoft; baton_pk; Lo1jke; Dinara78; uri1978; rtnm; tormozit; vano-ekt; Garrynich; alexscamp; the1; shalimski; Aleksey.Bochkov; +15 Ответить 2
7. Антон Антонов (monkbest) 19.12.14 15:57
Вопрос по предисловию: как так вышло, что раньше у предприятия не было денег на то, чтобы франчи вели документацию, а теперь появились?
8. Александр Губанов (gubanoff) 19.12.14 16:01
(6) brr, по префиксам сортировать удобно :)
9. Марина Чирина (chmv) 19.12.14 16:19
А я отбираю по своей фамилии и ищу что я меняла
10. Александр Губанов (gubanoff) 19.12.14 16:39
(9) chmv, для вашего случая это нормально. А когда несколько программистов дорабатывают конфигурацию, плюс кто-то из них периодически меняется, то эффекта от фамилий в коде ноль.
11. Смирнов Александр (Sander80) 19.12.14 23:30
Советы очень хорошие, но чего мне лично не хватило здесь, это использования хранилища.
В нем как минимум видно, кто из разработчиков в последний раз правил тот или иной отчет.
А если еще и административно затребовать от всех писать комментарии к коммитам (при сдаче в хранилище), то, возможно, и комментарии в коде не нужны.
Чарик; Aleskey_K; zaursoft; 4rtehouse; Герасим; bforce; dimisa; help1Ckr; awk; pythonchik; alexscamp; monkbest; +12 Ответить 2
12. борян петров (TODD22) 20.12.14 19:30
(2) gubanoff,
По прошествии n-лет мне глубоко безразлично кто и каким числом написал кусок кода

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

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

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

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

по контролю: полностью согласен, поэтому на работу берём людей которых можно "выпустить в самостоятельное плавание", у нас 95% работы на доверии основано (среди программеров).
15. Олег Смирнов (mrdug) 20.12.14 22:48
(7) monkbest,
тут дело не в деньгах, а в отношении. Видимо франчам просто не ставилась задача писать документацию. А вот сейчас у нас любой разговор начинается с вопроса будет ли на выходе документация оформленная нужным образом.
16. Олег Смирнов (mrdug) 20.12.14 22:52
(11) Sander80,
да, о хранилище не упомянул, хотя оно у нас конечно есть и работа идет через него. В него вносится информация, но в минимальном виде, только о затронутых объектах. Практика показывает, что когда идет разбор кода - смотреть куда-то кроме текущей конфы крайне неудобно.
17. борян петров (TODD22) 21.12.14 08:23
Ещё удобно номер задачи(тикета) указывать в комментариях. Если изменения в рамках одной задачи будут в нескольких модулях форм, объектов итд.
Можно быстро найти глобальным поиском во всей конфигурации все модули в которые вносились изменения в рамках одной задачи. Экономит время.
zaursoft; Герасим; gradi; dima_home; help1Ckr; Hellisad; h00k; alexscamp; monkbest; +9 Ответить 1
18. Антон Антонов (monkbest) 22.12.14 09:05
(15) mrdug, нет, наверное, дело именно в деньгах. Очень часто наблюдаю картину в жизни у клиентов и на этом форуме часто такое пишут.
Заказчик в бумагах один фиг ничего не понимает в большинстве случаев и тратить денег на них по умолчанию не хочет. Это, кстати, одна из причин начала работ не в крупной франче, а по мельче. В мелких на бумагах не настаивают, а в крупных это типа стандарт, который естественно увеличивает число часов к оплате.
Потом на мой взгляд происходит одно из событий, влекущее передачу дел полностью или частично. Причины видел следующие:
1. рост заказчика, что повлекло появление штатного сотрудника
2. смена руководства заказчика, который не понимает зачем "это было нахреноверчено" (не факт, что "нахреноверчено" было плохо, просто не понятно)
3. смена франча (причин много, от отказа оплаты из-за кризиса, а потом уже назад вернуться стремно, толи франч накосячил как, толи у франча "любимый" специалист уволился, а остальные балбесы...)

Но самостоятельного осознания заказчиком я не встречал. Чтобы вот так позвонил мне клиент со словами:
"Антон, мы тут с тобой наделали делов, а вдруг меня уволят или тебя, давай все задокументируем, я с директором договорился, он все оплатит" - звучит как сказка
uncle_Vasya; ojiojiowka; OdinAss; help1Ckr; blindcat2006; mrdug; +6 Ответить 1
19. andrey dyak (dyak84) 22.12.14 12:09
C Автором согласен на 100%. Порядок должен быть везде. Ну конечно есть нюансы когда описать сложно., но пытатся нужно всегда. И на мой взгляд грамотный коментарий самое то. Ну и отношение тут всегда должно быть на высоте.Но как говорится каждый должен начать из себя.!!!!!!!!!!!
ojiojiowka; +1 Ответить
20. Михаил Афанасьев (mikmike) 22.12.14 14:31
Писать комментарии и справки нужно обязательно - зачастую это помогает четко все сформулировать.
Я проставляю в комментарии отчета номер версии, а в справке - историю версий, сразу за описанием.
dima_home; +1 Ответить
21. Ivan Petrovich (sweeex) 22.12.14 19:07
Толковые советы, только напряжно писать описалово в коде, так как за несколько год будет каша малаша, исправляя код постоянно исправлять описалово везде, можно где то и забыть исправить.
22. Олег Смирнов (mrdug) 22.12.14 21:08
(17) TODD22,
насчет номера задачи: у нас эту роль выполняет первая строка комментария, она уникальна: дата+заказчик+краткое название задачи. Можно искать просто по названию задачи, будет тоже самое.
23. Олег Смирнов (mrdug) 22.12.14 21:11
(21) sweeex,
каша будет если в коде описалова нет. Проверено)))
24. zhuravlik (unichkin) 23.12.14 00:02
Не захотел ИС мой код из разукрашки есть, вот рисунок тогда...
Прикрепленные файлы:
ojiojiowka; +1 Ответить
25. Александр (Иной) 23.12.14 00:58
Хороший пост.

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

В типовых конфигурациях есть справочник "ВнешниеОбработки" туда и заливайте всё ("сохраняются" в хранилище значений и "восстанавливаются" при запуске).
Это снимет проблему с поиском где, что и т.д. Ну и плюс в бекапе базы будут все обработки.
26. борян петров (TODD22) 24.12.14 05:51
Может Хранилище конфигурации не всем нужно. Но вот что точно нужно это читать на ИТС стандарты разработки :)
ojiojiowka; nalivai-chai; +2 Ответить
27. Евгений Кредько (kredko) 24.12.14 06:29
(25) Иной, Мы сохраняем Внешние обработки ещё и в отдельной папке на сервере. Каждая папка соответствует типу обработки: печатная форма, обработка ТЧ или отчет. Имя обработки формируется так: ИмяДокумента - ИмяОбработки.
28. Ivan Khorkov (vano-ekt) 24.12.14 09:17
(6) brr, +
в процедурах/функциях префиксы дб
29. Роман Ложкин (webester) 24.12.14 09:28
Мне кажется, еще немного, и у вы дорастете до http://infostart.ru/public/310640/ и какой нибудь(необязательно) системы управления проектами, в которую можно интегрировать GIT.
JohnyDeath; +1 Ответить 1
30. Борис (sergey82vladik) 24.12.14 10:01
Я в конфигурации создаю специальную подсистему, куда включаю добавленные и измененные объекты.
help1Ckr; blindcat2006; +2 Ответить
31. Игорь Гончаров (SPID) 24.12.14 10:20
По стандартам разработке 1С разве допускается указания в комментариях даты и имена (инициалы)?
Считаю что указания "кто внес внес изменения и когда" не нужны в коде. Комментарий "что и зачем" к коду бесспорно нужен. Квалифицированный разработчик должен понять по коду и этим комментариям зачем данный код, и нет необходимости привязывать изменения к конкретному разработчику. Дата так же не особо информативна - когда внесены изменения она конечно покажет, но когда эти изменения пришли в продуктивную конфигурацию заказчика врятли. Как правило, учет всех задач/трудозатрат/изменений ведется в какой то еще системе, где и нужно отслеживать кто, зачем, когда и что делал.
32. Ivan Khorkov (vano-ekt) 24.12.14 10:37
(31) а если на проекте 10 разработчиков, работающих с одним объектом? оперативно набрать его по телефону и попросить объясниться за код составит 1 минуту...

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

JohnyDeath; awk; +2 Ответить 1
37. Игорь Гончаров (SPID) 24.12.14 12:40
(32) vano-ekt, Какая разница сколько разработчиков (и в этом случае нужно использовать хранилище конфигураций). Так же я сомневаюсь что разработчик за минуту вспомнить что же он там такое делала пару месяцев назад.
38. Андрей Закусов (masterkio) 24.12.14 13:25
1.Комментарии слишком объемные. В идеале одна строка в начале исправления, одна в конце. В противном случае у вас вместо кода будет зеленое полотно.
2.Вносить в справочную информацию какие-то технические комментарии вообще неуважение к пользователям. Тут одно из двух либо вы не приучаете пользователей пользоваться справкой, либо вы их попросту не уважаете. Никому не совету пользоваться данным советом.
Справка должна быть актуальной и понятной для пользователя.
3, 4. Эти советы вообще противоречат стандартам разработки - не советую так делать, куча разных префиксов только внесет бардак в дерево конфигурации и будет очень проблематично что-либо в нем искать. Если нужно сохранять информацию о том, кто добавил данный объект можно воспользоваться полем "Комментарий" - он есть у каждого объекта и виден только в конфигураторе.
dima_home; SPID; awk; +3 Ответить 2
39. Василий Казьмин (awk) 24.12.14 15:26
(38) masterkio, "Кто добавил" А еще лучше сначала ставить задачу в баг-трекере.. И не лазить по коду выясняя кто задачу поставил и где что и кто исправил...
40. Ivan Khorkov (vano-ekt) 24.12.14 16:55
(37) ви так говорите, будто не сравнивали версии из хранилищ и не знаете сколько занимает это времени)))
когда версий у объекта 100, тяжеловато будет найти сравнением поочередно каждой.
я всё так останусь при своем мнении, что при групповой разработке имя автора полезно указывать в комментариях
41. DAnry (DAnry) 24.12.14 17:47
Статья описывает "правильный" подход к внесению изменений в типовую конфигурацию. Хотя на мой скромный взгляд, предлагаемые правила уж слишком объемные и подробные. Впрочем это не догма и каждый вправе сам себе устанавливать правила и принципы...
42. Игорь Гончаров (SPID) 24.12.14 17:51
(40) vano-ekt, Сравнивал конечно - хранилище по разработке конфигурации с нуля и историей более чем за два года непрерывной разработки. Согласен - сравнивать версии долго. Хранилище конфигураций вообще вещь странная :) но не об этом.
Но так же я на своем опыте знаю, что спрашивать разработчика о коде который он написал более пары недель назад на 80% бесполезно - он не помнит зачем вносил изменения.
Разработчик может помнить, что и как в коде, если он один занимается постоянно каким-то небольшим ограниченным количеством объектов/подсистемой. Тут наверно подход позвонить разработчику будет актуальным. Но опять же, если и так известно что этот разработчик занимается этим объектом/подсистемой то зачем комментарий с именем в коде...

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

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


Думаете читабельно?
gubanoff; JohnyDeath; succub1_5; ediks; blindcat2006; +5 Ответить 1
45. Олег Смирнов (mrdug) 25.12.14 08:34
(44) awk,
вы правы, не читабельно. В посте 43 дан ответ на этот вопрос: "со временем эти комментарии теряют свой смысл и их можно просто убирать".
46. Олег Смирнов (mrdug) 25.12.14 08:51
(38) masterkio,
1. Объемные > непонятные :)
2. Кто сказал что в справке техническая информация? Там нет жутких малопонятных терминов. И есть два нюанса: 1. пользователь либо умеет читать справку, либо нет 2. Писать нужно как для себя, и стараться муть не разводить. Кстати, многие ссылаются на стандарты 1С, так вот думаю по части справки им до нас - как хромому до Пекина пешком)) уж простите за прямоту!
3. Вы невнимательно прочитали, нас нет кучи разных префиксов, цитирую: "Префикс всегда один и тот же".

47. Олег Смирнов (mrdug) 25.12.14 09:27
(29) webester,
не дорастем. У нас два критерия: 1. простота 2. эффективность. На первом же пункте мы и остановимся :) возможно для крупных предприятий это нужно, классно, удобно и т.д. Для нас - нет. И задачи у нас другие стоят. Нам нужно понимание того что сделано, а не оптимизация кода (а именно это я увидел в статье по вашей ссылке).
48. blindcat2006 (blindcat2006) 25.12.14 09:31
(18) monkbest,
Чтобы вот так позвонил мне клиент со словами:
"Имярек, мы тут с тобой наделали делов, а вдруг меня уволят или тебя, давай все задокументируем, я с директором договорился, он все оплатит" - звучит как сказка

- было, неделю назад, именно такими словами
49. Олег Смирнов (mrdug) 25.12.14 09:53
(42) SPID,
полностью согласен с вами насчет этого: "спрашивать разработчика о коде который он написал более пары недель назад на 80% бесполезно". ИМЕННО для таких случаев нами сделаны подробные комментарии. По ним то как раз и удается понять что/для чего было сделано!

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

И не смотрите пожалуйста на стандарты как на догму, это всего лишь унификация :)
50. Евгений Сосна (pumbaE) 25.12.14 11:18
51. Олег Смирнов (mrdug) 25.12.14 11:58
(36) dmitry-gr,
вы мне напоминаете выпускника ВУЗа, без обид :), всё правильно говорите, прям как по учебнику, не поспоришь. НО, это не работает :)

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

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

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

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


52. Евгений Сосна (pumbaE) 25.12.14 12:12
по п. 5: круто! но это немного другая тема, более обширная, и нужная опять таки для крупных предприятий с большим штатом программистов.

бред, нужна даже если ты один.
JohnyDeath; baton_pk; ADirks; Bronislav; awk; help1Ckr; +6 Ответить 1
53. Василий Казьмин (awk) 25.12.14 14:58
(51) mrdug, Система контроля версий (не обязательно git) - это не "модная система", это инструмент грамотного программиста.
54. Валентин Бомбин (so-quest) 25.12.14 15:27
(53)Система генерации документации - тоже инструмент, система тестирования - аналогично. расчет метрик и статический анализ - опять таки - для грамотного программиста придумали. Часто вы это в 1С используете? Если не часто - стали ли вы от этого безграмотным?

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

1. Использую, часто. :D Так что будет: "если использую часто"? Не увидел ветки.
2. Не он придумал. Он только статью написал. Это все и до него было...
3. Когда заказчик начитавшись таких статей требует, то "каждый решает для себя", не актуально.
56. Валентин Бомбин (so-quest) 25.12.14 16:36
(55) awk, "Использую, часто." - а вот это уже интересней. На чем построено автодокументирование? тестирование? статический анализ? расчет метрик?
57. Иван Иваныч (dima_home) 25.12.14 16:59
1. Префиксы новым объектам - есть такой грешок...ставлю "_" в начало
2. Оформляю код локанично:
для большого куска кода
Процедура ПриИзмененииТЧТовары()
...
//Мое!!! Начало Дима 25.12.2014 v13
//Проверяем максимальное ограничения скидки
Если НЕ СтрокаТовары.Номенклатура.Пустая() Тогда
 ...
КонецЕсли;
//Мое конец Дима
...Показать Скрыть


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


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


3. Коментарии при записи в хранилище также незабываю.
58. Василий Казьмин (awk) 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) 25.12.14 18:38
(54) so-quest,
Часто вы это в 1С используете? Если не часто - стали ли вы от этого безграмотным?


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



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

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

60. Валентин Бомбин (so-quest) 25.12.14 23:31
(59) awk, таких как вы "девочек" было бы побольше... глядишь и стандарты бы появились.
А так... Одна девочка на весь инфостарт - не смешная шутка
ojiojiowka; +1 Ответить
61. Павел (Yimaida) 26.12.14 01:08
Буквально сегодня с коллегой разбирались в логике работы одного механизма в сильно допиленной (до нас уже) конфигурации. Нашли ценный, на первый взгляд, комментарий, развернутый такой, на 4 строки. Ну и на радостях подумали, что все тут понятно... Ан нет. Комментарий не соответствовал действительности. Все показала отладка и детальное изучение кода. Выводы, конечно, не сделаешь по одному такому случаю (хотя похожие случаи уже встречались), но на мой взгляд, нужно еще уметь использовать в работе всякие методики подходы и т.п. Да и не всегда интересно делать все "по-правилам", оформлять скучным описанием функции и т.п. Если в коде все работает, то чего туда лезть. Если не работает, то комментарий не будет являться основанием для принятия решения. Я всегда делаю "как для себя". Если есть смысл - пишу комментарий (всегда ставлю дату и имя), пишу справку, могу оформить в ворд с картинками инструкцию, показать по тимвьюверу....
P.S. Тема оформления периодически всплывает на инфостарте, и дискутировать по ней можно долго. Интересно было прочитать почему кто-то использует именно этот инструмент (методику), и какие получает от этого преимущества. (т.е. чисто практика, никакой воды). Отдельное спасибо за ссылки на первоисточники и т.п., считаю это хорошим тоном.
62. Вячеслав Корендясов (madfox) 26.12.14 04:29
(11) Sander80, Все верно, комментарии тоже там можно для каждого изменения прописывать
63. Andrew Skotarev (Skotarev) 26.12.14 13:31
Информативно, спасибо, для себя почерпнул что-то
64. Роман Ложкин (webester) 28.12.14 06:09
(47)Не понял где вы там оптимизацию кода увидели.Статья рассказывает как они устроили разработку в соответствии со стандартами принятыми в мире. Когда любое изменение в коде фиксируется, документируется системой автоматически(а значит можно это оформить так как тебе надо, получить состояние системы на любой срез времени, я молчу про ветвления) все этим префиксы и ухищрения покажутся просто лиспедиками.
65. Vlad Matveev (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) 30.12.14 08:20
(66) maxdk9,
к сожалению не все люди умеют быстро понимать код аля "запрос с 8-ю вложенными таблицами", в таких случаях то, что писал "святой причетник из Компенхерсте" часто выручает :)
68. Олег Смирнов (mrdug) 30.12.14 08:31
(64) webester,
прочитал пункт "Позитивные стороны".

Спасибо, взглянул на эту систему шире, действительно интересно... но нужно что-то чуть попроще, пока что у нее вид - "для богов".
69. Олег Смирнов (mrdug) 30.12.14 08:38
(53) awk,
тут я пожалуй с so-quest соглашусь. Инструментов придумано немало, но сложность их использования зачастую просто отпугивает. В идеале хочется получить внятные инструменты "вшитые в 1С", а не сторонние программы.
70. Олег Смирнов (mrdug) 30.12.14 08:46
(52) pumbaE,
судя по категоричности вашего заявления - вы один и вы эффективно используете какую-то систему. Расскажите пожалуйста вкратце чем пользуетесь, плюсы и минусы. Или вы теоретизировали?
71. Василий Казьмин (awk) 30.12.14 16:42
(69) mrdug, Превратив сегодня нормальный читабельный код (8 запросов в пакете), в нечитабельную зеленую массу, я в полной мере прочувствовал ненависть к этому способу документирования изменений. Ждать от 1С очередной "швейцарский топор" можно долго, а результат будет именно швейцарский топор с лезвием для бритья (с вероятностью 99%), а не набор инструментов разработчика. Так что по мне стоит посмотреть в смежные отрасли, почитать, разобраться и прикрутить.
72. Александр (Иной) 30.12.14 16:52
=). Опираясь на свой не очень то и большой опыт в программировании (где-то лет 5) могу предположить, что более-менее человеческий комент можно оформить только на последнее изменение. Ибо оно может существенно покорежить чьи-то предидущие коменты. Сохранить всю историю изменений можно только сохраняя фрагменты кода (а лучше полностью конфигурацию) вовне.
Веду версионный учёт конфигураций. Уже много раз помогало =). Просто перед внесением в конфу правок сохраняю пекущую конфигураци. Нуменрую конфигурации. А в коментировании изменений держим приоритет на объяснение изменения, а не сохранении истории изменений. История в архиве конфигураций хранится =).

Где-то так.
73. Роман Ложкин (webester) 31.12.14 16:06
(68)Вас просто пугает обилие незнакомых терминов. Вы же программируете не только для 1С? Наверняка есть и другой код и скрипты и тд? Попробуйте засунуть их на гитхаб. И все станет просто сразу. Вот небольшой кусочек из разработки одного моего проекта https://api.monosnap.com/image/download?id=cRYOOlYyAm8gWmckX6ejLObtQlqLDd можно в любой момент поднять изменения по каждой конкретной решаемой задаче. По моему когда работает больше чем один человек, это очень нужно.
74. Олег Смирнов (mrdug) 04.01.15 19:29
(71) awk,
у нас есть такие решения, что мне порой сложно глядя в собственный код понять зачем я это сделал... быстро понять... понятно дело что я всё вспомню, но это время, которого иногда нет... поэтому пока всё же склоняюсь к пояснениям в коде...
Это как в автомобиле: я знаю как поменять ремень кондиционера, я знаю где его купить и сколько он стоит, я знаю когда менять его, но я могу забыть что для его замены нужно двигатель домкратить. Небольшой такой нюанс :) Поэтому я хочу в комментах сразу видеть "нужен ли мне домкрат".

насчет 1С согласен полностью, это они "умеют".
75. Олег Смирнов (mrdug) 04.01.15 19:38
(73) webester,
вы правы, пока что пугает. Если покопаться - можно внедрить, но хочется простоты... мне ведь перед внедрением сначала защитить перед руководством это придется... со всеми вытекающими последствиями :)
76. Заур Тарчоков (zaursoft) 06.01.15 21:26
(8) gubanoff, Возможно, но писать код очень неудобно. Особенно, если этих префиксов много в конфигурации. Кроме названия объекта нужно либо помнить префикс, либо искать в дереве объектов. Есть же система стандартов и методик разработки конфигураций для платформы 1С:Предприятие 8.
77. Александр (МимохожийОднако) 07.01.15 21:38
Одно время, когда работал с 77, вставлял в конфигурацию отдельный отчет с фрагментами кода и комментариями, в котором описывал реализованные задачи и внесенные изменения по ним. Там же писал инструкцию сам себе последовательность накатывания обновлений, чтобы не затереть свои наработки.. По структуре этот отчет был аналогичен дополнению к описанию, но по отдельному пункту меню. Это помогало вспомнить что к чему после продолжительного времени и облегчало обновления.
78. Яков Коган (Yashazz) 08.01.15 12:30
Опять описание кучи костылей, вызванных к жизни отсутствием соответствующего инструментария в среде разработки... Грустно это всё.
79. Андрей Вовк (wowkai) 11.01.15 20:23
Интересная и полезная методика. Автору респект.
до 1 пункта сами дошли, а вот 2-3 как раз искали как бы получше сделать
80. Adapter Бахтыреев (adapter) 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) 12.01.15 16:11
(80)
73 звезды.... Статья из серии Капитана Очевидность

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

84. Олег Смирнов (mrdug) 18.01.15 15:03
ДАМЫ И ГОСПОДА!
Я благодарю вас за то, что приняли участие в обсуждении этого вопроса! Ваше мнение, даже если оно кардинально отличалось от моего, было мне очень интересно.

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

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