tech.Solbi

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

Как не стоит программировать

… или маленькие (и не очень 🙂 ) ошибки, которые потенциально приводят к некорректному исполнению программного кода…

  • Если переменные не определены перед использованием (подробнее…)
  • Если при делении, знаменатель не проверять на не равенство нулю (почему нельзя делить на ноль)
  • Если после поиска по справочнику/документу/таблице и т.д. не проверять успешность выполнения поиска (оптимистически считать, что мы нашли то, что искали)
  • Если работать с количеством из документа, не проводя пересчет с использованием коэффициента (подробнее…)
  • Если создаются одинаковые данные несколько раз, в том случае если задачу можно решить «красивее»
  • Если для расчета (вывода) результатов проведения применять процедуры и функции отличные от тех которыми формируются движения документа или не использовать результаты проведения документа (подробнее…)
  • Если происходит дублирование кода процедур/функций/обработок. Под «обработками» в данном случае стоит понимать не обработку как объект метаданных 1С, а как совокупность программного кода для выполнения операций.
  • Если мы называем реквизиты так, чтобы они означали совершенно другое (например по смыслу поля — это цена, а мы назвали его «Стоимость»)
  • Если отчеты оформлены не полностью или же формируются не правильно, а именно (приведен самый минимум без которого нельзя отчет даже показывать заказчику 😉 ):
    • не выведена секция ИТОГО
    • не выводятся итоги в группировочных строках и/или колонках
    • в группировочных строках выводятся суммы нижестоящих строк, в то время как итоговые строки должны рассчитываться самостоятельно (например: % наценки)
    • не подписаны колонки в каких валютах выводятся данные
    • в пункт помощи к отчетам отсутствует информация о том, как и какие показатели считаются или информация не соответствует действительности
    • в отчет выводятся отрицательные значений, когда их по физическому смыслу не может быть. Например если смотреть «Оставшийся срок полезного использования» для основных фондов, которые уже давно амортизированны.
  • Если при описание запросов (в соединениях) отсутствуют проверки на NULL
  • Если происходит переопределение реквизитов, переданных в процедуру, внутри процедуры (если специально процедура не возвращает значение)
  • Если расчет НДС проведен через цифру 20% (или «*0.2» или «/6»)
  • Если отсутствует пересчет из валюты в валюту, там где возможно несколько разных валют
  • Если при расчетах сумм выполняются операции над суммами, представленными в разных валютах (например складываем гривны с долларами не умножая на курс)
  • Если постоянное происходит обращение к функциям остатков в цикле, при условии, что можно сделать предварительную выборку остатков и затем проводить обращение к результатам предварительной выборки. Или же (это уже так сказать совсем плохая ситуация) если при выводе в табличных частях документов/справочников, для каждой строки отдельно выполняется запрос по остаткам для текущей строки и это сделано без кэширования данных и при этом еще и в событии «ПриВыводеСтроки».
  • Если при копировании объектов — в предопределенных процедурах не очищаются (заполняются по новой) важные характеристики нового объекта (подробнее…)
  • Если при добавление реквизитов на форму, не учтены привязки в результате чего форма не поддается масштабированию
  • Если при открытии существующих документов / справочников, у них сразу выставляется признак модифицированности (т.е. происходит изменение реквизитов объекта или формы)
  • Если при разработке не учитывается преемственность новой разработки (не подумали, не проанализировали или же подумали, проанализировали но не сделали), а именно:
    • как измененная система будет себя вести с теми данными, которые были созданы в не доработанной системе (старые данные не должны портиться и как будет открываться например старый документ или справочник);
    • как система будет реагировать на то, что пользователь будет пытаться вносить, редактировать и анализировать данные «по привычке», т.е. используя старые приемы работы;
    • как не измененные в процессе разработки объекты базы данных будут себя вести если они используют измененные структуры хранения данных (любой старый объект должен знать как вести себя в новой схеме хранения данных);
    • как не измененные объекты метаданных (процедуры, функции, общие модули, справочники, документы, отчеты, обработки и прочее) будут взаимодействовать с измененными объектами метаданных (процедурами, функциями общими модулями, справочниками, документами, отчетами, обработками и прочее);
  • Если в программном коде не осуществляется проверка на то, о чем договорились с заказчиком 🙂 (Подробнее…)
  • Если при автоматизированной загрузке данных в объекты 1С не обеспечивается такая же структура данных, как при создании объектов «в ручную»
  • Если не соблюдается (или не выработана) методология работы с регистрами остатков в части за что отвечает в системе приход по регистру, а за что — расход (например для взаиморасчетов верно правильно, что отгрузки мы проводим всегда по расходу (в т.ч. и возвраты), а оплаты проводим всегда по приходу (в т.ч. и возвраты)). (Под вопросом остается пока учет остатков ТМЦ)


Один комментарий

  • Роман Мирошниченко:

    Если соблюдать то, что тут написано, то вопросов к разработанному программному продукту возникает гораздо меньше

Добавить комментарий для Роман Мирошниченко Отменить ответ

Ваш e-mail не будет опубликован. Обязательные поля помечены *