<?php // Полная загрузка сервисных книжек, создан 2024-01-05 12:44:55
global $wpdb2;
global $failure;
global $file_hist;
///// echo '<H2><b>Старт загрузки</b></H2><br>';
$failure=FALSE;
//подключаемся к базе
$wpdb2 = include_once 'connection.php'; ; // подключаемся к MySQL
// если не удалось подключиться, и нужно оборвать PHP с сообщением об этой ошибке
if (!empty($wpdb2->error))
{
///// echo '<H2><b>Ошибка подключения к БД, завершение.</b></H2><br>';
$failure=TRUE;
wp_die( $wpdb2->error );
}
$m_size_file=0;
$m_mtime_file=0;
$m_comment='';
/////проверка существования файлов выгрузки из 1С
////файл выгрузки сервисных книжек
$file_hist = ABSPATH.'/_1c_alfa_exchange/AA_hist.csv';
if (!file_exists($file_hist))
{
///// echo '<H2><b>Файл обмена с сервисными книжками не существует.</b></H2><br>';
$m_comment='Файл обмена с сервисными книжками не существует';
$failure=TRUE;
}
/////инициируем таблицу лога
/////если не существует файла то возврат и ничего не делаем
if ($failure){
///включает защиту от SQL инъекций и данные можно передавать как есть, например: $_GET['foo']
///// echo '<H2><b>Попытка вставить запись в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>$m_comment));
wp_die();
///// echo '<H2><b>Возврат в начало.</b></H2><br>';
return $failure;
}
/////проверка лога загрузки, что бы не загружать тоже самое
$masiv_data_file=stat($file_hist); ////передаем в массив свойство файла
$m_size_file=$masiv_data_file[7]; ////получаем размер файла
$m_mtime_file=$masiv_data_file[9]; ////получаем дату модификации файла
////создаем запрос на получение последней удачной загрузки
////выбираем по штампу времени создания (редактирования) файла загрузки AA_hist.csv, $m_mtime_file
///// echo '<H2><b>Размер файла: '.$m_size_file.'</b></H2><br>';
///// echo '<H2><b>Штамп времени файла: '.$m_mtime_file.'</b></H2><br>';
///// echo '<H2><b>Формирование запроса на выборку из лога</b></H2><br>';
////препарируем запрос
$text_zaprosa=$wpdb2->prepare("SELECT * FROM `vin_logs` WHERE `last_mtime_upload` = %s", $m_mtime_file);
$results=$wpdb2->get_results($text_zaprosa);
if ($results)
{ foreach ( $results as $r)
{
////если штамп времени и размер файла совпадают, возврат
if (($r->last_mtime_upload==$m_mtime_file) && ($r->last_size_upload==$m_size_file))
{////echo '<H2><b>Возврат в начало, т.к. найдена запись в логе.</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>'Загрузка отменена, новых данных нет, т.к. найдена запись в логе.'));
wp_die();
return $failure;
}
}
}
////если данные новые, пишем в лог запись о начале загрузки
/////echo '<H2><b>Попытка вставить запись о начале загрузки в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>0, 'last_size_upload'=>$m_size_file, 'comment'=>'Начало загрузки'));
////очищаем таблицу
$clear_tbl_zap=$wpdb2->prepare("TRUNCATE TABLE %s", 'vin_history');
$clear_tbl_zap_repl=str_replace("'","`",$clear_tbl_zap);
$results=$wpdb2->query($clear_tbl_zap_repl);
///// echo '<H2><b>Очистка таблицы сервисных книжек</b></H2><br>';
if (empty($results))
{
///// echo '<H2><b>Ошибка очистки таблицы книжек, завершение.</b></H2><br>';
//// если очистка не удалась, возврат
$failure=TRUE;
wp_die();
return $failure;
}
////загружаем данные
$table='vin_history'; // Имя таблицы для импорта
//$file_hist Имя CSV файла, откуда берется информация // (путь от корня web-сервера)
$delim=';'; // Разделитель полей в CSV файле
$enclosed='"'; // Кавычки для содержимого полей
$escaped='\
все супер, а не мало 2 знака для номеров по порядку?
зы у себя в компании мы еще номера макетам присваиваем и печатаем их вместе с датой последнего изменения отчета/обработки
1. по поводу комментариев: а как быть, если изменения по одному вопросу затрагивают несколько модулей, форм, макетов, объектов? Когда происходит рефакторинг кода? Лично меня даты и фамилии программистов в коде всегда умиляли. Они бесмысленны. По прошествии n-лет мне глубоко безразлично кто и каким числом написал кусок кода, если он не работает, то его нужно переписать и все. Более-менее уместна идея в комментариях писать номер замечания из учетной системы задач. А уже в учетной системе будет виден заказчик, дата, описание задачи и т.п. Но это тоже работает процентов на 50, не более.
2. Заказчики в справке — это тоже умиляет. Если их хотя бы больше 10, то это уже будет проблемой.
3. Номера отчетов — идея нормальная.
4. Префиксы у объектов — идея нормальная.
5. Контроль за исполнением — это хорошо. Именно из-за низкой исполнительской дисциплины или из-за отсутствия контроля за исполнением все предыдущие пункты и не будут работать. Или будут.
А мне фамилия в комментарии очень удобна. Я делаю поиск по ней
В комментарии модуля
(3) chmv, ну отобрали по фамилии, ну увидели, что это был некий Пупкин, уволенный 2 года назад. Что эта информация вам дает? Сделать на основании нее вывод, валиден код или нет невозможно.
Префиксы в именах метаданных зло! Я за суфиксы 🙂
Вопрос по предисловию: как так вышло, что раньше у предприятия не было денег на то, чтобы франчи вели документацию, а теперь появились?
(6) brr, по префиксам сортировать удобно 🙂
А я отбираю по своей фамилии и ищу что я меняла
(9) chmv, для вашего случая это нормально. А когда несколько программистов дорабатывают конфигурацию, плюс кто-то из них периодически меняется, то эффекта от фамилий в коде ноль.
Советы очень хорошие, но чего мне лично не хватило здесь, это использования хранилища.
В нем как минимум видно, кто из разработчиков в последний раз правил тот или иной отчет.
А если еще и административно затребовать от всех писать комментарии к коммитам (при сдаче в хранилище), то, возможно, и комментарии в коде не нужны.
(2) gubanoff,
Даты доработок очень нужная информация даже по прошествии n-лет. Например сталкивался с доработками в типовой сделанными в 12 году. В 13 году 1С доработала функционал и необходимость в «дописках» пропала. Именно по дате доработки и определили что функционал больше не нужен.
Это когда есть такая система учета задач! тут не на каждом предприятие есть элементарно список доработок в word формате… не говоря уже о системе учёта задач.
Ещё варианты предложить? Например я звонил Пупкиным и просил прокоментировать некоторые сделанные ими доработки. Люди были вполне адекватными и рассказывали что, как и для чего было сделано.
(1) mmoozzgg,
пока что 2-ух знаков хватает, например программист, работающий более 2-х лет, «своих» отчетов/обработок создал порядка 40 штук, то есть занял всего 40 номеров.
(2) gubanoff,
по части дат и фамилий: отчасти соглашусь, по прошествию времени многое становится не нужным, но в текущем времени — это ооооочень хорошо работает. А даты и со временем востребованы, когда «чистили» бухгалтерию от изменений по датам понимали оставлять изменения или нет.
заказчики в справке: это тоже для текущей работы.
по контролю: полностью согласен, поэтому на работу берём людей которых можно «выпустить в самостоятельное плавание», у нас 95% работы на доверии основано (среди программеров).
(7) monkbest,
тут дело не в деньгах, а в отношении. Видимо франчам просто не ставилась задача писать документацию. А вот сейчас у нас любой разговор начинается с вопроса будет ли на выходе документация оформленная нужным образом.
(11) Sander80,
да, о хранилище не упомянул, хотя оно у нас конечно есть и работа идет через него. В него вносится информация, но в минимальном виде, только о затронутых объектах. Практика показывает, что когда идет разбор кода — смотреть куда-то кроме текущей конфы крайне неудобно.
Ещё удобно номер задачи(тикета) указывать в комментариях. Если изменения в рамках одной задачи будут в нескольких модулях форм, объектов итд.
Можно быстро найти глобальным поиском во всей конфигурации все модули в которые вносились изменения в рамках одной задачи. Экономит время.
(15) нет, наверное, дело именно в деньгах. Очень часто наблюдаю картину в жизни у клиентов и на этом форуме часто такое пишут.
Заказчик в бумагах один фиг ничего не понимает в большинстве случаев и тратить денег на них по умолчанию не хочет. Это, кстати, одна из причин начала работ не в крупной франче, а по мельче. В мелких на бумагах не настаивают, а в крупных это типа стандарт, который естественно увеличивает число часов к оплате.
Потом на мой взгляд происходит одно из событий, влекущее передачу дел полностью или частично. Причины видел следующие:
1. рост заказчика, что повлекло появление штатного сотрудника
2. смена руководства заказчика, который не понимает зачем «это было нахреноверчено» (не факт, что «нахреноверчено» было плохо, просто не понятно)
3. смена франча (причин много, от отказа оплаты из-за кризиса, а потом уже назад вернуться стремно, толи франч накосячил как, толи у франча «любимый» специалист уволился, а остальные балбесы…)
Но самостоятельного осознания заказчиком я не встречал. Чтобы вот так позвонил мне клиент со словами:
«Антон, мы тут с тобой наделали делов, а вдруг меня уволят или тебя, давай все задокументируем, я с директором договорился, он все оплатит» — звучит как сказка
C Автором согласен на 100%. Порядок должен быть везде. Ну конечно есть нюансы когда описать сложно., но пытатся нужно всегда. И на мой взгляд грамотный коментарий самое то. Ну и отношение тут всегда должно быть на высоте.Но как говорится каждый должен начать из себя.!!!!!!!!!!!
Писать комментарии и справки нужно обязательно — зачастую это помогает четко все сформулировать.
Я проставляю в комментарии отчета номер версии, а в справке — историю версий, сразу за описанием.
Толковые советы, только напряжно писать описалово в коде, так как за несколько год будет каша малаша, исправляя код постоянно исправлять описалово везде, можно где то и забыть исправить.
(17) TODD22,
насчет номера задачи: у нас эту роль выполняет первая строка комментария, она уникальна: дата+заказчик+краткое название задачи. Можно искать просто по названию задачи, будет тоже самое.
(21) sweeex,
каша будет если в коде описалова нет. Проверено)))
Не захотел ИС мой код из разукрашки есть, вот рисунок тогда…
Хороший пост.
От себя добавлю, внешние обработки лучше сохранять в хранилище =).
В типовых конфигурациях есть справочник «ВнешниеОбработки» туда и заливайте всё («сохраняются» в хранилище значений и «восстанавливаются» при запуске).
Это снимет проблему с поиском где, что и т.д. Ну и плюс в бекапе базы будут все обработки.
Может Хранилище конфигурации не всем нужно. Но вот что точно нужно это читать на ИТС стандарты разработки 🙂
(25) Иной, Мы сохраняем Внешние обработки ещё и в отдельной папке на сервере. Каждая папка соответствует типу обработки: печатная форма, обработка ТЧ или отчет. Имя обработки формируется так: ИмяДокумента — ИмяОбработки.
(6) brr, +
в процедурах/функциях префиксы дб
Мне кажется, еще немного, и у вы дорастете до и какой нибудь(необязательно) системы управления проектами, в которую можно интегрировать GIT.
Я в конфигурации создаю специальную подсистему, куда включаю добавленные и измененные объекты.
По стандартам разработке 1С разве допускается указания в комментариях даты и имена (инициалы)?
Считаю что указания «кто внес внес изменения и когда» не нужны в коде. Комментарий «что и зачем» к коду бесспорно нужен. Квалифицированный разработчик должен понять по коду и этим комментариям зачем данный код, и нет необходимости привязывать изменения к конкретному разработчику. Дата так же не особо информативна — когда внесены изменения она конечно покажет, но когда эти изменения пришли в продуктивную конфигурацию заказчика врятли. Как правило, учет всех задач/трудозатрат/изменений ведется в какой то еще системе, где и нужно отслеживать кто, зачем, когда и что делал.
(31) а если на проекте 10 разработчиков, работающих с одним объектом? оперативно набрать его по телефону и попросить объясниться за код составит 1 минуту…
//Дата, Сотрудник, Ссылка на ТЗ или на заявку/инцидент с системе регистрации и учета заявок/инцидентов
Не понял из публикации — извлечение комментариев и построение документации — как-то автоматизировано или руками?
Много работал с метаданными и кодом, где были как суффиксы так и префиксы. В итоге для меня однозначно суффиксы имеют больше плюсов, чем префиксы.
статья полезна не только при групповой разработке, но и персональной. дисциплинирует, облегчает. спасибо.
Сколько же проблем с организацией разработки и контролю за ней решится когда 1С выпустит eclipse-версию конфигуратора и все эти велосипеды можно будет заменить на отлично зарекомендовавшие себя инструменты!
Теперь по сути:
1. Комментарии в коде конечно важны, только они должны плавно перетекать в комментарии к коммитам, а код стремится к самодокументируемости.
2. Справка или документация важна для пользователя, разработчику надо заглядывать в ТЗ.
3. Страх и ужас! Такая система говорит о прежде всего неумении организовать и каталогизировать собственное рабочее пространство. откройте для себя git
4. Страх и ужас №2! Используйте подсистемы и только их. 1С — скорее вводи расширения!!!
5. Почитайте что такое коде-ревью, какие есть практики и ваш ежемесячный контроль отпадет сам собой.
(32) vano-ekt, Какая разница сколько разработчиков (и в этом случае нужно использовать хранилище конфигураций). Так же я сомневаюсь что разработчик за минуту вспомнить что же он там такое делала пару месяцев назад.
1.Комментарии слишком объемные. В идеале одна строка в начале исправления, одна в конце. В противном случае у вас вместо кода будет зеленое полотно.
2.Вносить в справочную информацию какие-то технические комментарии вообще неуважение к пользователям. Тут одно из двух либо вы не приучаете пользователей пользоваться справкой, либо вы их попросту не уважаете. Никому не совету пользоваться данным советом.
Справка должна быть актуальной и понятной для пользователя.
3, 4. Эти советы вообще противоречат стандартам разработки — не советую так делать, куча разных префиксов только внесет бардак в дерево конфигурации и будет очень проблематично что-либо в нем искать. Если нужно сохранять информацию о том, кто добавил данный объект можно воспользоваться полем «Комментарий» — он есть у каждого объекта и виден только в конфигураторе.
(38) masterkio, «Кто добавил» А еще лучше сначала ставить задачу в баг-трекере.. И не лазить по коду выясняя кто задачу поставил и где что и кто исправил…
(37) ви так говорите, будто не сравнивали версии из хранилищ и не знаете сколько занимает это времени)))
когда версий у объекта 100, тяжеловато будет найти сравнением поочередно каждой.
я всё так останусь при своем мнении, что при групповой разработке имя автора полезно указывать в комментариях
Статья описывает «правильный» подход к внесению изменений в типовую конфигурацию. Хотя на мой скромный взгляд, предлагаемые правила уж слишком объемные и подробные. Впрочем это не догма и каждый вправе сам себе устанавливать правила и принципы…
(40) vano-ekt, Сравнивал конечно — хранилище по разработке конфигурации с нуля и историей более чем за два года непрерывной разработки. Согласен — сравнивать версии долго. Хранилище конфигураций вообще вещь странная 🙂 но не об этом.
Но так же я на своем опыте знаю, что спрашивать разработчика о коде который он написал более пары недель назад на 80% бесполезно — он не помнит зачем вносил изменения.
Разработчик может помнить, что и как в коде, если он один занимается постоянно каким-то небольшим ограниченным количеством объектов/подсистемой. Тут наверно подход позвонить разработчику будет актуальным. Но опять же, если и так известно что этот разработчик занимается этим объектом/подсистемой то зачем комментарий с именем в коде…
У Вас часто получается позвонить указанному в комментариях разработчику, и что бы он сразу вам рассказал зачем этот кусок кода?
(42) SPID, если речь идет о разработке в одной конфигурации нескольких человек, то комментарии об авторстве исправления имеют довольно большое значение, особенно если ведется хоть какой-то контроль качества кода, например если на рабочую конфигурацию выкатывает какой-то ответственный человек. тогда он сразу может понимать к кому относится той или иной кривой код.
Понятно что со временем эти комментарии теряют свой смысл и их можно просто убирать.
(43) masterkio, Ну узнали кто разбилдяй и что? Со временем я вижу вот такие комменты:
//{ Сидоров 2014-07-01 удалено ////{ Петров 2013-05-30 Изменено //////{ Иванов 2011-05-30 добавлено ////… ///Заменен на: //… //////} ////} //}Показать
Думаете читабельно?
(44) awk,
вы правы, не читабельно. В посте 43 дан ответ на этот вопрос: «со временем эти комментарии теряют свой смысл и их можно просто убирать».
(38) masterkio,
1. Объемные > непонятные 🙂
2. Кто сказал что в справке техническая информация? Там нет жутких малопонятных терминов. И есть два нюанса: 1. пользователь либо умеет читать справку, либо нет 2. Писать нужно как для себя, и стараться муть не разводить. Кстати, многие ссылаются на стандарты 1С, так вот думаю по части справки им до нас — как хромому до Пекина пешком)) уж простите за прямоту!
3. Вы невнимательно прочитали, нас нет кучи разных префиксов, цитирую: «Префикс всегда один и тот же».
(29) webester,
не дорастем. У нас два критерия: 1. простота 2. эффективность. На первом же пункте мы и остановимся 🙂 возможно для крупных предприятий это нужно, классно, удобно и т.д. Для нас — нет. И задачи у нас другие стоят. Нам нужно понимание того что сделано, а не оптимизация кода (а именно это я увидел в статье по вашей ссылке).
(18) monkbest,
«Имярек, мы тут с тобой наделали делов, а вдруг меня уволят или тебя, давай все задокументируем, я с директором договорился, он все оплатит» — звучит как сказка
— было, неделю назад, именно такими словами
(42) SPID,
полностью согласен с вами насчет этого: «спрашивать разработчика о коде который он написал более пары недель назад на 80% бесполезно». ИМЕННО для таких случаев нами сделаны подробные комментарии. По ним то как раз и удается понять что/для чего было сделано!
Что касается ФИО и стандартов: да, возможно стандартами это не предусмотрено, НО, у нас есть производственная необходимость и значит мы имеем полное моральное право это применять. К тому же ничего крамольного в этом нет.
И не смотрите пожалуйста на стандарты как на догму, это всего лишь унификация 🙂
(42) SPID,
git blame
(36) dmitry-gr,
вы мне напоминаете выпускника ВУЗа, без обид :), всё правильно говорите, прям как по учебнику, не поспоришь. НО, это не работает 🙂
по п.2: справка — это то что находится «под рукой», а попробуйте в условиях отсутствия времени и крайней нервозности пользователей (а в таких условиях работают многие 1с-программисты) — найти ТЗ и ответить на все их вопросы. Думаю у вас это не получится.
по п.3: зачем нам git? чтобы быть модными? наша задача простая: 1. хранить отдельно (диск бэкапируется, ничего не пропадет, всё доступно, описание открывается обычными блокнотами) 2. пронумеровать. Ни для для первого пункта, не для второго нет смысла заводить модную программу.
по п. 4: пункт 2 вы читали? или что-то другое имелось ввиду?
по п. 5: круто! но это немного другая тема, более обширная, и нужная опять таки для крупных предприятий с большим штатом программистов.
бред, нужна даже если ты один.
(51) Система контроля версий (не обязательно git) — это не «модная система», это инструмент грамотного программиста.
(53)Система генерации документации — тоже инструмент, система тестирования — аналогично. расчет метрик и статический анализ — опять таки — для грамотного программиста придумали. Часто вы это в 1С используете? Если не часто — стали ли вы от этого безграмотным?
И, в принципе, придумал себе ТС набор действий для заполнения пустот во времени — порадуемся за него. А использовать или нет у себя — тут каждый для себя решает.
(54) so-quest,
1. Использую, часто. 😀 Так что будет: «если использую часто»? Не увидел ветки.
2. Не он придумал. Он только статью написал. Это все и до него было…
3. Когда заказчик начитавшись таких статей требует, то «каждый решает для себя», не актуально.
(55) awk, «Использую, часто.» — а вот это уже интересней. На чем построено автодокументирование? тестирование? статический анализ? расчет метрик?
1. Префиксы новым объектам — есть такой грешок…ставлю «_» в начало
2. Оформляю код локанично:
для большого куска кода
Показать
для малого куска кода
И само-сабой описание функций и процедур
Показать
3. Коментарии при записи в хранилище также незабываю.
(56) so-quest,
1. Автодокументирование Doxigen (
2. Тестирование
3. 1С:Автоматизированная проверка конфигураций
4. Не использую… Типового нет писать влом.
(54) so-quest,
Напомнило анекдот:
3 Часа ночи. Звонок в службу поддержки (5 летней девочки).
— Доброй ночи.
— Дяденька, а вы не подскажите как настроить интернет?
— А взрослые рядом есть?
— Есть, но они пьяные.
— Нажимаем кнопку «Пуск»…
— Дяденька, дяденька. Вы не поняли. У меня FreeBSD…
(59) awk, таких как вы «девочек» было бы побольше… глядишь и стандарты бы появились.
А так… Одна девочка на весь инфостарт — не смешная шутка
Буквально сегодня с коллегой разбирались в логике работы одного механизма в сильно допиленной (до нас уже) конфигурации. Нашли ценный, на первый взгляд, комментарий, развернутый такой, на 4 строки. Ну и на радостях подумали, что все тут понятно… Ан нет. Комментарий не соответствовал действительности. Все показала отладка и детальное изучение кода. Выводы, конечно, не сделаешь по одному такому случаю (хотя похожие случаи уже встречались), но на мой взгляд, нужно еще уметь использовать в работе всякие методики подходы и т.п. Да и не всегда интересно делать все «по-правилам», оформлять скучным описанием функции и т.п. Если в коде все работает, то чего туда лезть. Если не работает, то комментарий не будет являться основанием для принятия решения. Я всегда делаю «как для себя». Если есть смысл — пишу комментарий (всегда ставлю дату и имя), пишу справку, могу оформить в ворд с картинками инструкцию, показать по тимвьюверу….
P.S. Тема оформления периодически всплывает на инфостарте, и дискутировать по ней можно долго. Интересно было прочитать почему кто-то использует именно этот инструмент (методику), и какие получает от этого преимущества. (т.е. чисто практика, никакой воды). Отдельное спасибо за ссылки на первоисточники и т.п., считаю это хорошим тоном.
(11) Sander80, Все верно, комментарии тоже там можно для каждого изменения прописывать
Информативно, спасибо, для себя почерпнул что-то
(47)Не понял где вы там оптимизацию кода увидели.Статья рассказывает как они устроили разработку в соответствии со стандартами принятыми в мире. Когда любое изменение в коде фиксируется, документируется системой автоматически(а значит можно это оформить так как тебе надо, получить состояние системы на любой срез времени, я молчу про ветвления) все этим префиксы и ухищрения покажутся просто лиспедиками.
1. Комментарии делаю, но указываю лишь, где
— начало/конец
— кто/когда
— код доработки, например, «д001» (об этом ниже)
2. Более информативно, с моей точки зрения, делать подсистемы.
Например, есть общая подсистема «Префикс_ВнесенныеИзменения».
А «в ней», есть подчиненные подсистемы вида «д001_АвтоформированиеДокумента», где
«д» — это значит доработки (еще есть «и» — изменение типового функционала)
«001» — порядковый номер.
«АвтоформированиеДокумента» — краткое описание доработки.
Далее в составе этой подсистемы указываются объекты, которые менялись/добавлялись, а в справочной информации более детально описывается задача.
В итоге, всегда можно быстро вывести элементы, которые были изменены по каждой доработке и при необходимости прочитать что за изменение и зачем оно нужно
Из «минусов»: данный подход не работает с версиями 8.1 и ниже, где не было понятия «Подсистемы».
По поводу комментов уже давно все написано у Мартина (Чистый код). Когда принимаешь конфу от комментов «Писано 01.01.01 у большого сборного дуба святым причетником из Компенхерсте» рябит в глазах. Один раз посчитал -принял обработку импорта из аксапты -удалил все комменты типа «писано темто» и закомментированный код. Убрал 1700 строк из 6000 в модуле объекта.
Кстати пример 3 -коммент не нужен. В принципе. Там из кода все должно быть понятно.
(66) maxdk9,
к сожалению не все люди умеют быстро понимать код аля «запрос с 8-ю вложенными таблицами», в таких случаях то, что писал «святой причетник из Компенхерсте» часто выручает 🙂
(64) webester,
прочитал пункт «Позитивные стороны».
Спасибо, взглянул на эту систему шире, действительно интересно… но нужно что-то чуть попроще, пока что у нее вид — «для богов».
(53) awk,
тут я пожалуй с so-quest соглашусь. Инструментов придумано немало, но сложность их использования зачастую просто отпугивает. В идеале хочется получить внятные инструменты «вшитые в 1С», а не сторонние программы.
(52) pumbaE,
судя по категоричности вашего заявления — вы один и вы эффективно используете какую-то систему. Расскажите пожалуйста вкратце чем пользуетесь, плюсы и минусы. Или вы теоретизировали?
(69) Превратив сегодня нормальный читабельный код (8 запросов в пакете), в нечитабельную зеленую массу, я в полной мере прочувствовал ненависть к этому способу документирования изменений. Ждать от 1С очередной «швейцарский топор» можно долго, а результат будет именно швейцарский топор с лезвием для бритья (с вероятностью 99%), а не набор инструментов разработчика. Так что по мне стоит посмотреть в смежные отрасли, почитать, разобраться и прикрутить.
=). Опираясь на свой не очень то и большой опыт в программировании (где-то лет 5) могу предположить, что более-менее человеческий комент можно оформить только на последнее изменение. Ибо оно может существенно покорежить чьи-то предидущие коменты. Сохранит
(68)Вас просто пугает обилие незнакомых терминов. Вы же программируете не только для 1С? Наверняка есть и другой код и скрипты и тд? Попробуйте засунуть их на гитхаб. И все станет просто сразу. Вот небольшой кусочек из разработки одного моего проекта можно в любой момент поднять изменения по каждой конкретной решаемой задаче. По моему когда работает больше чем один человек, это очень нужно.
(71) awk,
у нас есть такие решения, что мне порой сложно глядя в собственный код понять зачем я это сделал… быстро понять… понятно дело что я всё вспомню, но это время, которого иногда нет… поэтому пока всё же склоняюсь к пояснениям в коде…
Это как в автомобиле: я знаю как поменять ремень кондиционера, я знаю где его купить и сколько он стоит, я знаю когда менять его, но я могу забыть что для его замены нужно двигатель домкратить. Небольшой такой нюанс 🙂 Поэтому я хочу в комментах сразу видеть «нужен ли мне домкрат».
насчет 1С согласен полностью, это они «умеют».
(73) webester,
вы правы, пока что пугает. Если покопаться — можно внедрить, но хочется простоты… мне ведь перед внедрением сначала защитить перед руководством это придется… со всеми вытекающими последствиями 🙂
(8) gubanoff, Возможно, но писать код очень неудобно. Особенно, если этих префиксов много в конфигурации. Кроме названия объекта нужно либо помнить префикс, либо искать в дереве объектов. Есть же система стандартов и методик разработки конфигураций для платформы 1С:Предприятие 8.
Одно время, когда работал с 77, вставлял в конфигурацию отдельный отчет с фрагментами кода и комментариями, в котором описывал реализованные задачи и внесенные изменения по ним. Там же писал инструкцию сам себе последовательность накатывания обновлений, чтобы не затереть свои наработки.. По структуре этот отчет был аналогичен дополнению к описанию, но по отдельному пункту меню. Это помогало вспомнить что к чему после продолжительного времени и облегчало обновления.
Опять описание кучи костылей, вызванных к жизни отсутствием соответствующего инструментария в среде разработки… Грустно это всё.
Интересная и полезная методика. Автору респект.
до 1 пункта сами дошли, а вот 2-3 как раз искали как бы получше сделать
73 звезды….. Статья из серии Капитана Очевидность — хочешь потом разобраться описывай сейчас. Чем лучше камент в коде тем удобнее © Кличко. А уж в текстовых файликах все держать или в вордовых уже не важно. ИМХО удобнее всего делать доработки чтобы в 80% обновлений они вообще не мешались, а в 20 использовать ссылки на внешнюю базу данных техподдержки (как и сказали выше).
Единственный плюс статьи — показать важность момента, тем кто до этого еще пока не дошел. Ну и если уж про опыт, то предлагаю размяться от обратного:
1. куча франчей и фикси меняется в конфе за несколько лет. В итоге получаем «специалистов», которым надо объяснять про каменты в коде….
Заказчику стоит пересмотреть кадровую политику. ГБ и и дир тоже меняется несколько раз в год? Может они тоже для себя систему тайных записей придумают?
Хотя рыба гниет с головы, возможно на первом пункте лучше все и закончить. Пристрелить эту старую лошадь, чтобы не мучалась.
2. Справочная информация.
судя по рассказанному справочная система отсутствует. Набор лоскутных текстовых файликов… это лучше чем ноль, но меньше чем необходимо. Справка должна быть полная, внятная, со скриншотами, взаимосвязями. Иначе техподдержка будет требоваться постоянно (покрасневший телефон). Даже на базе типовой конфы должна быть справочная система, которая описывает все изменения. Организовать ее можно кучей способов, например:
— встроить в конфу свой справочник, который содержит описания, организовать удобный вывод пользователю
— Внутренний сайт базы знаний, из конфы кнопка которая открывает ссылку. Простейший вариант — на сервере 1С ставим appserv + wordpress. Сайт можно поделить разделами под каждую БД 1С
— на сетевом диске положить файл (wordpdfhtml*..), открывать кнопкой из конфы.
Например добавленный отчет (все равно внешний он или внутренний) должен быть описан примерно так:
Название отчета (в шапке, форме, файле, справке — единое, тогда не нужны коды, шифры, и пр. пляшущие человечки)
Функционал (кратко, больше одного предложения, на пару абзацев) — что показывает, какие могут быть варианты, чем отличается от похожих (ссылки)
Скриншот — (чтобы не было половины вызовов чтобы просто посмотреть на его форму, вид)
3. Техподдержка.
Если по обращению пользователя можно переписать отчет полностью, значит нет у вас ТПД. Есть программеры, которых заставляют работать на ТПД. Песня про бегуна на короткие дистанции, которого заставили бежать на длинные…. а он не хотел. © Высоцкий
Если нет 1 и 2, то 3 могло бы решить проблему. 1,2,3 это три черепахи на которых стоит ИТ система. Хватит штукатурить здание в котором нет фундамента.
(80)
Это вы еще статей про то не видели, или про то . По сравнению с ними статья на уровне 80лвл по «экспертности».
Комментарии в коде это само по себе хорошо, а вот ведение хранилища разработки с обязательным заполнением комментариев при помещении измененного объекта в хранилище — это еще лучше.
(80) adapter,
спасибо за содержательный ответ, критика у нас приветствуется 🙂 Отвечать не буду, вы увидели то что хотели увидеть…. к сожалению.
ДАМЫ И ГОСПОДА!
Я благодарю вас за то, что приняли участие в обсуждении этого вопроса! Ваше мнение, даже если оно кардинально отличалось от моего, было мне очень интересно.
Да, эта система не идеальна. Да, есть вещи более профессиональные. Да, что-то в ней можно и нужно пересмотреть… НО, это всего лишь набор приемов, главное же в этой статье — привлечь ваше внимание к этой проблеме. Проблеме которую можно охарактеризовать фразой: «после нас — хоть трава не расти».
Прошу вас, думайте о своем завтрашнем дне, о комфорте в работе, о вашей эффективности, о вашем развитии, и наконец о людях которые придут вам на смену! Вот что главное в этой статье!