Комментарии
Избранное
Подписка
Сортировка:
Древо развёрнутое
Свернуть все
У нас подобный подход встречается для крупных блоков доработок. Например есть приказ, что с 1 ноября все сотрудники работают по такой-то схеме бизнес-процесса. Чтобы эту новую логику заложить на старых метаданных требуется доработка, которая не должна влиять на работу до 1 ноября. Так вот подобный выключатель полезен первые пару дней после перехода. Просто сдвигаем дату с 1 ноября на 2 ноября, люди продолжают работать как и работали, пока разработчики в срочном порядке исправляют критичные баги, которые всплывают только у пользователей с ограниченными правами и только в тонком клиенте и когда созвездие Стрельца находится в Деве.
(16) В Астрономии может даже и быть, но если правильно выбрать точку (не на земле, а во вселенной). А в Астрологии так вообще любые чудеса могут происходить )) А так это скорее ситуация, которая по мнению программиста случиться никогда не должна была бы...
(21) если выбрать точку (этак в паре десятков световых лет, полагаю), то предположу, что звездный узор не будет похож уже ни на Деву, на на Стрельца (или кто там был?)
А в астро(логии? Правда?) - вообще любой бред может быть, и пытливый ум всегда найдет, как это притянуть за уши к окружающей действительности. Есть же универсальные рецепты, да?)))
А в астро(логии? Правда?) - вообще любой бред может быть, и пытливый ум всегда найдет, как это притянуть за уши к окружающей действительности. Есть же универсальные рецепты, да?)))
У нас такой подход использовался при независимой работе нескольких разработчиков без выделенного руководителя проекта. Можно предположить, что код вызова сообщения/комментария об ошибке например содержит информацию о разработчике данной доработки и "шквал звонков" или электронной почты обрушивается на автора доработки.
Когда есть руководитель проекта и у него есть возможность заменить накосячившего исполнителя этот подход теряет смысл.
Когда есть руководитель проекта и у него есть возможность заменить накосячившего исполнителя этот подход теряет смысл.
Проблема понятна, и от опечаток никто не застрахован. Но фича-флаги (импровизированные "функциональные опции") при такой гонке за временем навсегда остаются в конфигурации. И конфигурация обрастает бесконечными вставками вида:
Главная проблема такого кода - он потом месяцами, если не годами, не вычищается из конфигурации. И условия наслаиваются друг на друга. Как-то надо за этим следить, иначе код превращается в лапшу. Но на практике что-то желающих заниматься последующей "уборкой" не находится )) А если и находятся смельчаки вычищать старые условия, то они только повышают риск нарваться на ошибку уже после удаления старых условных операторов и смелость их быстро пропадает )
С другой стороны вот всего за две минуты почти автоматически записал сценарий, который избавит от необходимости обрамлять этот код. И с высокой долей вероятности любой другой код, связанный с пробитием чека. Стабилизация и установка нужной цены для товара заняла бы еще 2 минуты. Сложно придумать аргументы, чтобы сэкономить 4 минуты, если стабильность действительно является ценностью. И никаких бессмысленных условных операторов в коде. Разве что однажды написанные механизмы, позволяющие автоматически запускать тесты. Да и то, сохраняется возможность полениться и не делать автоматический запуск, а запускать сценарии один раз перед релизом вручную )) Хотелось бы чтобы больше в этом направлении коллеги смотрели. 2020 год близится как никак ))
Если ХранилищеНашихНастроек.ПолучитьНастройку("Сообщения о цене при пробитии чека по просьбе бабы Маши включены") Тогда
// Две строки полезного кода
КонецЕслиГлавная проблема такого кода - он потом месяцами, если не годами, не вычищается из конфигурации. И условия наслаиваются друг на друга. Как-то надо за этим следить, иначе код превращается в лапшу. Но на практике что-то желающих заниматься последующей "уборкой" не находится )) А если и находятся смельчаки вычищать старые условия, то они только повышают риск нарваться на ошибку уже после удаления старых условных операторов и смелость их быстро пропадает )
С другой стороны вот всего за две минуты почти автоматически записал сценарий, который избавит от необходимости обрамлять этот код. И с высокой долей вероятности любой другой код, связанный с пробитием чека. Стабилизация и установка нужной цены для товара заняла бы еще 2 минуты. Сложно придумать аргументы, чтобы сэкономить 4 минуты, если стабильность действительно является ценностью. И никаких бессмысленных условных операторов в коде. Разве что однажды написанные механизмы, позволяющие автоматически запускать тесты. Да и то, сохраняется возможность полениться и не делать автоматический запуск, а запускать сценарии один раз перед релизом вручную )) Хотелось бы чтобы больше в этом направлении коллеги смотрели. 2020 год близится как никак ))
Функционал: Отображение суммы чека после его пробития в панели сообщений пользователю
Как Продавец розничного магазина
Я хочу Видеть сумму чека при пробитии в панели сообщений пользователю
Чтобы Иметь вомзожность быстро сравнить сумму чека на бумажном корешке с суммой чека в 1С
Контекст:
Дано я подключаю TestClient "Этот клиент" логин "Продавец1" пароль ""
Сценарий: Пробитие чека с сообщением суммы
Когда Я открываю смену
Когда В командном интерфейсе я выбираю 'Продажи' 'Чеки ККМ'
Тогда открылось окно 'Чеки ККМ'
И из выпадающего списка с именем "КассаККМОтбор" я выбираю точное значение 'Фискальный регистратор (Торговый зал)'
И я нажимаю на кнопку 'Открыть смену'
И Выполняю продажу товара по цене двести одинадцать рублей
Тогда В панели разделов я выбираю 'Продажи'
И В панели функций я выбираю 'Рабочее место кассира'
И я выбираю пункт контекстного меню "Добавить" на элементе формы с именем "Товары"
И в таблице "Товары" из выпадающего списка "Номенклатура" я выбираю по строке 'Товар по цене 211 рублей'
И в таблице "Товары" в поле 'Количество' я ввожу текст '1,000'
И я нажимаю на кнопку с именем 'ОплатитьНаличнымиДубль'
Тогда открылось окно 'Оплата наличными'
И я перехожу к закладке "Группа страница прочее"
И я нажимаю на кнопку 'Команда2'
И я нажимаю на кнопку 'Команда1'
И я нажимаю на кнопку 'Команда1'
И я нажимаю на кнопку 'Пробить чек (Alt+F2)'
Тогда в логе сообщений TestClient есть строка "Продан товар за 211 рублей"
Показать
(5) ну уж это полнейший абсурд и ложь про две минуты. До этого пришлось сколько недель/месяцев изучать этот функционал тестирования?
Тем более, текст был уже готов, за две минуты разве что пару строк там подправить можно было, но не все с нуля писать.
Что это такое вообще? Для чего скрипт?
Тем более, текст был уже готов, за две минуты разве что пару строк там подправить можно было, но не все с нуля писать.
Что это такое вообще? Для чего скрипт?
(32) Две минуты занимает запись и воспроизведение. Ну еще описать фичу понятными человеку словами и сделать отступы секунд 30-60. Это серьезно то, о чём нужно спорить?
Почему это Вы решили, что тест был уже готов? Я не занимаюсь розницей в данный момент, у меня нет готовых для этого фича-файлов. Вот, засекайте время. Не жалко потратить еще 2 минуты, чтобы показать как это работает.
А то что технологии и инструменты требуют обучения и навыка... Ну как бы да, есть такой большой недостаток у этих гадких технологий и инструментов.
Среди пришедших в 1С за легким заработком ходят слухи, что для 1С-ника вообще достаточно навыка два раза кликать на ярлыке конфигуратора. Но даже после его открытия нужен навык набора на клавиатуре )) Хотя... можно обойтись и без него. Достаточно обернуть весь написанный код в Попытку - Исключение. Всё равно половину никто проверять не будет )) Довольно частый случай кстати на наших предприятиях. Не раз уже видел как так работают сторонники мнения "ревью и тесты не для нас, они только мешаютломать работать".
Уф, хорошо, что в этот раз статья про код в попытках, а не про всякие бесполезные планы запросов )) Чтоб тут началось..... )
Почему это Вы решили, что тест был уже готов? Я не занимаюсь розницей в данный момент, у меня нет готовых для этого фича-файлов. Вот, засекайте время. Не жалко потратить еще 2 минуты, чтобы показать как это работает.
А то что технологии и инструменты требуют обучения и навыка... Ну как бы да, есть такой большой недостаток у этих гадких технологий и инструментов.
Среди пришедших в 1С за легким заработком ходят слухи, что для 1С-ника вообще достаточно навыка два раза кликать на ярлыке конфигуратора. Но даже после его открытия нужен навык набора на клавиатуре )) Хотя... можно обойтись и без него. Достаточно обернуть весь написанный код в Попытку - Исключение. Всё равно половину никто проверять не будет )) Довольно частый случай кстати на наших предприятиях. Не раз уже видел как так работают сторонники мнения "ревью и тесты не для нас, они только мешают
Уф, хорошо, что в этот раз статья про код в попытках, а не про всякие бесполезные планы запросов )) Чтоб тут началось..... )
Мы делам доработки через "включатели". Во всех доработанных базах у нас есть справочник Доработки с одним предопределенным элементом, чтобы удобно было обращаться. Туда заносим флаги на доработанные функции, а также любые другие данные, которые нужно хранить для удобства.
Метод подходит только если добавляется что-то новое в одном месте. А если вы, например, в запрос добавляете новое условие или запрос в пакет запросов, а после используете это далее по коду? В каждом месте ставить Попытка - Исключение?
Мы во всех базах, где это возможно, используем расширения конфигурации. А где нельзя - тестирование пользователем на копии. А если и это невозможно (подразделения раскиданы территориально и в каждом своя база) - тестирование разработчиком на копии, затем алгоритм для разработчика "накатил на рабочку - протестируй" (и накатываем постепенно, а не на все сразу)
Мы во всех базах, где это возможно, используем расширения конфигурации. А где нельзя - тестирование пользователем на копии. А если и это невозможно (подразделения раскиданы территориально и в каждом своя база) - тестирование разработчиком на копии, затем алгоритм для разработчика "накатил на рабочку - протестируй" (и накатываем постепенно, а не на все сразу)
Уже как-то была статья на инфостарте про криворуких программистов в ней упоминалась конструкция попытка/исключение как показатель "криворукости", я тогда не согласился и не соглашусь сейчас. Да кувалда это не очень хороший инструмент но иногда без него никак. Мало того есть даже случаи когда такая конструкция оправдана с точки зрения уменьшения количество правок типовой конфигурации.
Попытка исключение это зло
Оно только усложняет отладку
При исключении рушится транзакция, вложенных транзакций в 1с нет и если вы уже находитесь в транзакции на момент ошибки то никакой флаг уже не снимете. В данной транзакции уже происходили ошибки - вот сообщение которое вы увидите
А если попытка вложенная в другую попытку то отладка такого решения становится веселой задачей, такое любил рарус в своих конфигурациях альфа авто да будет вечно здоров тот кто там это придумал
В свое время чтобы побороть такие ошибки тот же рарус грозился написать внешнюю компоненту которая возьмёт на себя все сообщения в исключениях, отфильтрует их для пользователей и выведет только те которые являются важными\ключевыми в данный момент
Таким образом они выводили сообщения даже если транзакции уже нет в живых
Оно только усложняет отладку
При исключении рушится транзакция, вложенных транзакций в 1с нет и если вы уже находитесь в транзакции на момент ошибки то никакой флаг уже не снимете. В данной транзакции уже происходили ошибки - вот сообщение которое вы увидите
А если попытка вложенная в другую попытку то отладка такого решения становится веселой задачей, такое любил рарус в своих конфигурациях альфа авто да будет вечно здоров тот кто там это придумал
В свое время чтобы побороть такие ошибки тот же рарус грозился написать внешнюю компоненту которая возьмёт на себя все сообщения в исключениях, отфильтрует их для пользователей и выведет только те которые являются важными\ключевыми в данный момент
Таким образом они выводили сообщения даже если транзакции уже нет в живых
Тот случай, когда комментарии ценнее публикации. Потому что публикация очевидна, как набор утверждений "2*2=4", банальна и нового ничего не содержит (ну разве только для совсем нубов, но их на боевые важные участки обычно не ставят). А вот комменты имеют шанс раскрыть вопрос по-настоящему.
Я помню ещё со времён комплексной 7.7 константы, которые отключают бухгалтерский учёт и расчет в конфигурации. В идеале они должны превратить комплексную в однокомпонентную конфигурацию (торговля? бухгалтерия? - и главное зачем?)
В 8 ке от компонент отказались, но константы использовать или нет склады, партнёров, кассы или зарплату остались даже в ерп.
Причем ответственность за их использование возлагается на программиста, поскольку после включения функциональных опций (а если предприятие несколько лет работало с единственным складом а теперь решило добавить такую аналитику?) требуется вмешательство программиста с изменением данных задним числом, что в ерп системах просто недопустимо, или по меньшей мере не по таким банальным причинам.
Сами функциональные опции это очень крутой функционал, но имхо он в качестве таких регуляторов использоваться не должен, а комплексная или ерп вовсе не обязаны повторять болезнь роста торговли.
В 8 ке от компонент отказались, но константы использовать или нет склады, партнёров, кассы или зарплату остались даже в ерп.
Причем ответственность за их использование возлагается на программиста, поскольку после включения функциональных опций (а если предприятие несколько лет работало с единственным складом а теперь решило добавить такую аналитику?) требуется вмешательство программиста с изменением данных задним числом, что в ерп системах просто недопустимо, или по меньшей мере не по таким банальным причинам.
Сами функциональные опции это очень крутой функционал, но имхо он в качестве таких регуляторов использоваться не должен, а комплексная или ерп вовсе не обязаны повторять болезнь роста торговли.
В 7ке, обсуждая эти возможности с коллегами мы предполагали, что можно предлагать клиентам риб с предприятием и комплексной в центре и той же конфигурацией в периферии, но на одной компоненте. С ЗУП в качестве нагрузки или без него (как настроено в миграции). Так могло работать если размигрировать константы( т.е. отключить все типы учёта в периферии), но я не помню ни одного реального проекта, где бы эти идеи оказались востребованы или могли составить конкуренцию нетленкам.
Авторизацию приходилось делать независимую от платформенной, это удобно. Выбор принтеров и хранение их с привязкой к пользователям вместо оси, поскольку не всегда большая сеть была доменной, а печать по одной кнопке это всем нравилось.
Авторизацию приходилось делать независимую от платформенной, это удобно. Выбор принтеров и хранение их с привязкой к пользователям вместо оси, поскольку не всегда большая сеть была доменной, а печать по одной кнопке это всем нравилось.
По большому счету в обычных формах только одна проблема - в журналах/списках нет фильтров по проведен/помечен, что именно при риб с их попыткой проведения в центральной базе представляет неудобство. В такси все это есть (если не поубирали).
Есть такие хорошие понятия как "" и "".
Подобные методы реализации "подстраховки" растят нам необходимость внесения в дальнейшем изменений по удалению лишних блоков кода и функциональности. Как правильно было сказано выше, такая подстраховка нужна только первые пару дней. Значит, нам предстоит ещё один релиз с новыми изменениями: удаление нашей подстраховки. И как все мы знаем, даже такая простая операция может повлечь за собой ошибки.
Итого получается: более частые подготовка, тестирование и выкатывание релизов и бОльшие риски возникновения ошибок.
Второй приведённый мной термин намекает лично мне, что для собственника дешевле нанять тестера или наложить функцию тестирования на консультантов (что у нас на предприятии успешно работает уже несколько лет), чем подобная реализация.
Подобные методы реализации "подстраховки" растят нам необходимость внесения в дальнейшем изменений по удалению лишних блоков кода и функциональности. Как правильно было сказано выше, такая подстраховка нужна только первые пару дней. Значит, нам предстоит ещё один релиз с новыми изменениями: удаление нашей подстраховки. И как все мы знаем, даже такая простая операция может повлечь за собой ошибки.
Итого получается: более частые подготовка, тестирование и выкатывание релизов и бОльшие риски возникновения ошибок.
Второй приведённый мной термин намекает лично мне, что для собственника дешевле нанять тестера или наложить функцию тестирования на консультантов (что у нас на предприятии успешно работает уже несколько лет), чем подобная реализация.
Что если, да как быть... Если программист работает в режиме цейтнота, то гоните руководителей по автоматизации в шею мокрыми тряпками. Нашлись, блин, зарабатывальщики денег - сами себе проблемы создаёте, и доблестно же их решаете (это театрально возмущаюсь)
А если серьёзно, то я, например, действую так:
1. Кормёжка заказчика мелкими полезностями
2. Приучение пользователей к тому, что им хочется работать и они обожают свой участок
3. Плавное исключение всех контейнеров самодурства
И только потом всё приводится к стандартным решениям, с небольшими внешними доработками. Т.о. получаю нормальный ритм работы, довольных директоров и много позитива. И да, этот вариант относится к предприятиям, где 24 часа в сутки, 7 дней в неделю, всё кипит-бурлит и меняется.
Как делают гореавтоматизаторы:
Делают суперфичу, с кучей дыр и костылей. Быстро внедряют и потом латают дыры костылями. В итоге один-два прога постоянно что-то подделывают по этой задаче. На следующем блоке ещё один прог постоянно подделывает что-то и так до бесконечности. Помню более 40 айтишников сопровождали УПП (переписанную) и не успевали, поэтому несколько франей постоянно там работало. После применения рекомендуемых методов, через год не осталось никого, кроме одного малоопытного одинэсника, без потери функционала
А если серьёзно, то я, например, действую так:
1. Кормёжка заказчика мелкими полезностями
2. Приучение пользователей к тому, что им хочется работать и они обожают свой участок
3. Плавное исключение всех контейнеров самодурства
И только потом всё приводится к стандартным решениям, с небольшими внешними доработками. Т.о. получаю нормальный ритм работы, довольных директоров и много позитива. И да, этот вариант относится к предприятиям, где 24 часа в сутки, 7 дней в неделю, всё кипит-бурлит и меняется.
Как делают гореавтоматизаторы:
Делают суперфичу, с кучей дыр и костылей. Быстро внедряют и потом латают дыры костылями. В итоге один-два прога постоянно что-то подделывают по этой задаче. На следующем блоке ещё один прог постоянно подделывает что-то и так до бесконечности. Помню более 40 айтишников сопровождали УПП (переписанную) и не успевали, поэтому несколько франей постоянно там работало. После применения рекомендуемых методов, через год не осталось никого, кроме одного малоопытного одинэсника, без потери функционала
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.