Предисловие
Общепринято считать, что изменение конфигураций всегда выполняется по ранее написанному техническому заданию, требования четко проработаны, что все доработки четко продуманы и последствия изменений заранее известны.
Но вернемся с небес на землю! Во многих компаниях разработка / доработка конфигураций ведется в таком ритме, что бумага просто не поспевает за ними (или вместо бумаги Jira, Confluence, Redmine и т.д.). Когда в неделю выполняются десятки доработок и изменений - технические задания отпадают сами собой. Их, конечно, могут писать и в таких ситуациях, но в основном это делают только для фиксации результатов, когда задача уже вышла на рабочее окружение (ну или для "разведения бюрократии"), а также чтобы передать всю старую кипу бумаг новому программисту в будущем. Вникать в курс дела, так сказать. Но сами понимаете, что, если ТЗ писались только потому, что "так надо", никакой практической пользы они не принесут.
Учитывая специфику работы многих российских компаний, в которых изменение информационной системы можно сравнить с гаечным ключом, который "совершенствуется" прямо в руках автомобилиста, напрашивается вывод о невозможности использования технических заданий и четкой проработки требований. Да и сам бизнес не всегда готов сказать, что же он желает получить в результате, чего уж тут говорить об аналитиках, пытающихся весь поток мыслей формализовать.
Мы не будем рассказывать о специфике работы таких компаний и о причинах происходящего. На эти темы отлично пишет Иван Белокаменцев. Очень интересной была одна из последних публикаций. Рассмотрим другую сторону вопроса. Что нужно сделать программисту / разработчику, чтобы сохранить стабильность работы системы при таком наплыве непротестированных на 100% доработок. Что необходимо сделать нам, разработчикам, чтобы снизить риски при высоких темпах разработки. Вот об этом и пойдет речь далее.
Нет, мы не будем говорить об изменении процессов отдела разработки, внедрения автотестирования и т.д. Это другая история. Мы рассмотрим классические способы решения, известные еще со времен 7.7.
Коллапс
Рассмотрим простой пример, с которым в той или иной степени сталкивался каждый из разработчиков. Торговая организация, все работают в единой базе. Самым используемым по частоте записи / проведения документом является "Чек ККМ". Оно и понятно, в день по всем филиалам происходит много продаж. Кассиры трудятся в поте лица, за что им большое спасибо.
И вот, пришло небольшое задание. По нажатию на кнопке "Пробить" в чеке необходимо выводить итоговую сумму чека в сообщении. Примерно вот таким образом (см. скриншот справа). Да-да, странная задача и она выдумана, просто для примера. Вряд ли Вы столкнетесь с таким в реальности (хотя кто знает...).
Плевое дело! В начале процедуры-обработчика команды "ПробитьЧек", связанной с одноименной кнопкой на форме, нам всего на всего нужно выводить сообщение с привязкой к текущему объекту документа и полю реквизита "СуммаДокумента" на форме. Что может быть проще!
Но день был тяжелый, программист выполнял параллельно десять задач (многоядерные программисты дороже стоят, т.к. лицензируются на одно ядро :)), да еще параллельно консультировал бухгалтеров о порядке расчет себестоимости (мало ли...). В результате написанный код содержал опечатку.
// ........
// ++
Сообщение = Новый СообщениеПользователю;
Сообщение.Текст = "Сумма чека к оплате "
+ Объект.СумаДокумента // !!! ОПЕЧАТКА !!!
+ "(руб.)";
Сообщение.УстановитьДанные(Объект);
Сообщение.Поле = "СуммаДокумента";
Сообщение.Сообщить();
// --
ЧекПробит = ПробитьЧекНаКлиенте();
Если ЧекПробит Тогда
ТолькоПросмотр = Истина;
КонецЕсли;
// ........
И после очередного вечернего обновления информационной базы на следующее утро начался шквал звонков от растерянных кассиров и других пользователей, которые не могу продать товар, так как, цитирую, "У нас чек не работает!".
Всего одна опечатка создала чрезвычайную ситуацию. Конечно, вмешательство программиста позволило решить проблему в считанные минуты. Было проведено динамическое обновление обновление информационной базы с предварительным завершением сеансов. Все пришло в норму.
Как же мы, разработчики, можем застраховать себя от подобных сюрпризов? Конечно, конечно! Вы можете сказать, что нужны прямые руки или тестировщики. Или и то и другое. Но что, если у нас есть только прямые руки, а руководство скупится на зарплаты тестировщика в штате? Вариант просыпаться в 8 утра, когда начинают работать магазины и исправлять баги - не для нас. А уж тем более по выходным!
Рассмотрим варианты решения, которые может использовать разработчик, находящийся в подобной ситуации.
Вся ответственность на разработчике
И так, Вы программист / разработчик или группа программистов / разработчиков. Не важно. Главное, что ответственность за стабильность работы информационной системы, и в частотности за ошибки, баги в большей степени лежит на Вас, при этом интенсивность внесения доработок очень высокая. В таких случаях для подстраховки можно использовать следующие подходы в работе.
Скажи эксепшенам нет!
Начнем с самого простого. Мы могли бы поставить новый программный код в обработку исключений "Попытка...Исключение...". Тогда новый функционал конечно не работал бы, но нам бы удалось избежать шквала звонков и полной остановки работоспособности касс организации. Пользователи и дальше бы пробивали чеки, а программист позже бы заметил ошибку и поправил ее в нормальном режиме работы.
// ........
// ++
Попытка
Сообщение = Новый СообщениеПользователю;
Сообщение.Текст = "Сумма чека к оплате "
+ Объект.СумаДокумента // !!! ОПЕЧАТКА !!!
+ "(руб.)";
Сообщение.УстановитьДанные(Объект);
Сообщение.Поле = "СуммаДокумента";
Сообщение.Сообщить();
Исключение
// Ничего не делаем
КонецПопытки;
// --
ЧекПробит = ПробитьЧекНаКлиенте();
Если ЧекПробит Тогда
ТолькоПросмотр = Истина;
КонецЕсли;
// ........
В примере выше мы никак не обрабатываем исключение. В настоящей ситуации можно либо выводить сообщение об ошибке пользователю, либо отправлять программисту на электронную почту. Или использовать множество других вариантов. Все зависит только от воображения. В любом случае мы сохраним работоспособность системы и сбережем нервную систему себе и пользователям.
"Выключатели"
Еще один способ сохранения относительной стабильности - "выключатели". Покажу на примере.
В конфигурации создаем справочник "Разработка" с реквизитом "Флаг" булевого типа. Для всех пользователей добавим право на чтение / изменение этого справочника.
В справочнике будут содержаться предопределенные элементы для каждой доработки / разработки, изменения по которым вносятся в рабочую информационную базу.
Для нашего примера добавим предопределенный элемент с именем "СообщитьОСуммеЧекаПриПробитии".
В соответствии с этим необходимо изменить программный код в обработчике команды "ПробитьЧек" и добавить кэширование значение реквизита "Флаг" для добавленного предопределенного элемента. Первым делом добавим реквизит формы "СообщитьОСуммеЧекаПриПробитии" с типом "булево", а в обработчике формы "ПриСозданииНаСервере" запишем в этот реквизит соответствующее значение.
Примечание: кэширование значения реквизита "Флаг" выполняем для того, чтобы исключить повторные обращения к серверу по команде "ПробитьЧек".
В соответствии с описанными изменениями программный код процедуры-обработчика команды "ПробитьЧек" примет следующий вид:
// ........
// ++
Если СообщитьОСуммеЧекаПриПробитии Тогда
Сообщение = Новый СообщениеПользователю;
Сообщение.Текст = "Сумма чека к оплате "
+ Объект.СумаДокумента // !!! ОПЕЧАТКА !!!
+ "(руб.)";
Сообщение.УстановитьДанные(Объект);
Сообщение.Поле = "СуммаДокумента";
Сообщение.Сообщить();
КонецЕсли;
// --
ЧекПробит = ПробитьЧекНаКлиенте();
Если ЧекПробит Тогда
ТолькоПросмотр = Истина;
КонецЕсли;
// ........
Таким образом, если будет обнаружена ошибка, то разработчик с легкостью уберет флаг в предопределенном элементе "СообщитьОСуммеЧекаПриПробитии" справочника "Разработки" и ветка с программным кодом вообще перестанет выполняться. Никаких экстренных обновлений базы не потребуется, работа нормализуется. Главное форму чека переоткрыть после отключения функционала.
Предложенный вариант позволит отменить использование внесенной доработки без обновления информационной базы, однако ошибка у пользователей все равно единожды появится и потребуется вмешательство специалиста. Может и не программиста, но любого другого сотрудника, способного отключить эту разработку, точно.
Уже не плохо. Для временного исправления ситуации уже не нужно обновлять информационную базу, но вставать в 8 утра все же пришлось бы! Но у нас есть еще интересный вариант в копилке!
Полная автоматизация
Доработав предыдущий вариант, мы можем полностью автоматически отправлять сообщение о возникшей ошибке программисту, а также отключить добавленный программный код автоматически. Для этого доработаем программный код процедуры-обработчика команды "ПробитьЧек" следующим образом:
&НаКлиенте
Процедура ПробитьЧек(Команда)
// ++
Если СообщитьОСуммеЧекаПриПробитии Тогда
Попытка
Сообщение = Новый СообщениеПользователю;
Сообщение.Текст = "Сумма чека к оплате "
+ Объект.СумаДокумента // !!! ОПЕЧАТКА !!!
+ "(руб.)";
Сообщение.УстановитьДанные(Объект);
Сообщение.Поле = "СуммаДокумента";
Сообщение.Сообщить();
Исключение
ИнформацияОбОшибке = ПодробноеПредставлениеОшибки(ИнформацияОбОшибке());
// Тут сохраняем каким-либо образом информацию об ошибке
// Отключаем доработку с ошибкой
ОтключитьФлаг("СообщитьОСуммеЧекаПриПробитии");
КонецПопытки;
КонецЕсли;
// --
ЧекПробит = ПробитьЧекНаКлиенте();
Если ЧекПробит Тогда
ТолькоПросмотр = Истина;
КонецЕсли;
КонецПроцедуры
&НаСервереБезКонтекста
Процедура ОтключитьФлаг(ИмяПредопределенногоЭлемента)
// Сбрасываем значение в кэше данных формы
СообщитьОСуммеЧекаПриПробитии = Ложь;
ОбъектФлаг = Справочники.Разработки[ИмяПредопределенногоЭлемента].ПолучитьОбъект();
ОбъектФлаг.Флаг = Ложь;
Попытка
ОбъектФлаг.Записать();
Исключение
КонецПопытки;
КонецПроцедуры
К-к-к-к-к-к-комбо!
Теперь при возникновении ошибки флаг включения нового программного кода будет сброшен в ЛОЖЬ автоматически и при последующих вызовах команды "ПробитьЧек" ошибка вообще не будет воспроизводится.
Как-раз то, чего мы добивались. Ошибки не будут сыпаться бедным пользователям, те будут продолжать как обычно продолжать работать с программой, ничего не подозревая о "пролетевшем мимо метеорите".
А что, если ...
...если программист допустит ошибку в подстраховывающем алгоритме? Все возможно. Чтобы снизить риски лучше всего вынести этот код в общий модуль и после его использовать во всех подобных ситуациях. Тогда постоянно его писать не придется и риск опечаток сведется к минимуму.
Если ЕстьОпечатки Тогда
Сообщить("Ошибки в коде!");
Иначе
Сообщить("Ошибок нет!");
КонецЕсли;
А если ошибка будет не синтаксическая, а логическая! Да, тогда автоматически алгоритм не отключится. Нужно будет руками отключить флаг использования разработки. Но никто не обещал создать на платформе 1С:Предприятие искусственный интеллект! Зачем же тогда мы нужны были бы!
Не берусь утверждать, что подход идеальный, но в подобных ситуациях, о которых шла речь в начале статьи, реально спасает. Правильней, конечно, было бы проверять доработки пользователями от бизнеса, тестировщикам или, на худой конец, другими программистами. Но это не всегда реально. Последнее скорее прерогатива крупных компаний, где есть отдел программистов и постановщиков, тестировщиков задач.
А каков Ваш идеальных подход в такой ситуации?
Другие ссылки
-
Динамические константы или избавляемся от поиска по наименованию
-
[Расширение] Новый справочник "Константы", для хранения неизменяемых значений
Авторские разработки
-
Анализ производительности APDEX - отчет для просмотра и анализа замеров производительности в конфигурациях на базе БСП.
-
Путеводитель по истории релизов - отчет по истории выпуска релизов продуктов фирмы "1С" и анализа информации по обновлениям.
-
Просмотр и анализ структуры базы данных (отчет на СКД) - отчет для просмотра и анализа структуры базы данных с поддержкой файловых баз (ограниченный режим), а также баз на SQL Server и PostgreSQL.
-
Просмотр и анализ журнала регистрации (отчет на СКД) - отчет на базе системы компоновки данных (СКД) для просмотра записей журнала регистрации.
-
Обозреватель криптографии - отчет для просмотра доступных провайдеров и сертификатов криптографии на сервере и клиенте.
-
Пакетная выгрузка / загрузка внешних отчетов и обработок - пакетная выгрузка / загрузка внешних отчетов и обработок для массовый манипуляций с ними.
