DataLife Engine > Блог > Почему так много изменений требуется в программе 1с?

Почему так много изменений требуется в программе 1с?


5-02-2015, 11:10. Разместил: admin
Одно не понятно. Неужели для каждой базы/конфигурации 1с необходима разная установка по оптимизации, разные схемы индексирования данных, разные схемы управляемых блокировок? Почему столько много приходится несуразностей и ошибок в базах исправлять? Это уже не просто слова, это уже «крик души».

Очень много информации в интернете про оптимизацию и запросов и структур индексов. В том числе и на дисках ИТС (информационно-технологическое сопровождение). А что в типовых конфигурациях? Такое ощущение, что выпускается конфигурация начального уровня, а дальше кормим разработчиков-программистов сопровождающих, которые в большей степени не умеют оптимизацию эту осуществлять. Да и тяжело какому-то одному программисту исправить все что сможет найти. Ни знаний не достаточно, ни умения. А ведь огромное количество вещей приходится доделывать и исправлять.  

 


Например, при поддержке одного предприятия в одном проекте мы насчитали более 2000 отметок об изменении типового кода. И это не считая доработок, которых насчитывается около 50-ти подсистем, которые в свою очередь включают более 200 объектов (отчетов, обработок, форм документов и справочников).

Слишком туго и сложно приходится тому, кто ставит обновление на эту систему (хотя дело техники). Допустим вносили за период между обновлениями несколько программистов изменения в конфигурацию. И получается все эти изменения нужно не затронуть и учесть и состыковать с типовым кодом. Именно в этом заключается большая трудность. Если меняется типовой код, то момента ошибок обновления не избежать. Поэтому прежде чем делать обновление нужно зафиксировать для себя что было изменено в базе и далее уже делать по алгоритму.

 


Доработка

Мы, как разработчики, у себя постоянно дорабатываем программу. Причем это не столько связано с тем, что кому-то необходимо что-то сделать в программе. А именно связано с тем, что у самого разработчика есть понимание глобального охвата структуры всей базы данных.

Ну например, вносятся постоянные коррективы в разработку юзабилити. ну не просят пользователи и не понимают, что можно сделать, а что нет. И нет задания такого на разработку. А у разработчика присутствует понимание, что это нужно и делает это во всей конфигурации.
 

  Приведем небольшой пример. В одном отчете понадобился универсальный кусочек кода для того, чтобы в отборе в построителе отчета был однозначно подбор следующего реквизита по условию заполненного другого. Согласитесь, когда в отчете выбрали в отборе контрагента, то в случае если будет необходимо подобрать договор, то хотелось бы договор выбирать уже по конкретному контрагенту, а не безлико выбирать все заново во всем справочнике контрагентов. Вот и получился у нас маленький кусочек кода, который позволяет делать универсально по наличию такого подчинения реквизитов. При этом было сделано для любых таких возможных подчинений  — Номенклатура и Единица измерения, Организация и Банковский счет. Это далеко не полный перечень возможных вариаций подчиненности справочников. Но в нашей доработке это не помеха, там все проверяется на уровне типа значения владельца подбираемого подчиненного справочника.
 
Казалось бы такие моменты возникали у каждого пользователя. Они не заметны, многие к этому привыкают и не обращают на это внимание, а мы вот взяли и подправили. При этом еще пошли дальше и во всех отчетах эту возможно сделали.
 
Вся ли конфигурация 1с универсальна? На практике очень часто приходится добавлять возможность создавать документы на основании других документов и которые не предусмотрены в типовой конфигурации.

  Например, на основании «Возврата поставщику» сделать документ «Возврат от покупателя». Конечно, если рассматривать с точки зрения учета одного предприятия, не логично делать на основании связки данных по этим видам документов. Но ведь учет в 1с позволяет вести учет по нескольким организациям. Вот и получается не везде универсально то, что может быть практичным в применении. Т.е. не все включено в арсенал типовых конфигураций. Достаточно много таких функционалов приходилось и приходится дорабатывать. Встречали на просторах сайта Infostart инструмент универсального заполнения табличной части «товары» на основании любого документа с аналогичной табличной частью. В типовых конфигурациях почему такого инструмента тоже нет? Как быть? Не менять конфигурацию? И забивать данные опять вручную?


Результат

Правильный ли это подход? Результатом таких небольших доработок у нас база данных приобрела достаточно удобный инструмент, и самое интересное в базе не существует понятие блокировок как таковых. Что именно сработало за многолетний труд, трудно сказать. В целом можно заключить, что повлияло всё. 2000 изменений в типовых местах кода, еще правильное конфигурирование дополнительных подсистем, в целом дал такой результат.

Дорабатывая такие куски кода следует быть осторожным. Универсальные вещи могут сыграть злую шутку, не везде они могут быть универсальными и могут вылезти в ошибку, здесь можно применять хитрый ход: обрамлять доработку условием «Попытка Исключение КонецПопытки», тем самым код можно безбоязненно вносить в конфигурацию, и это не будет мешать тестированию

 


Количество вносимых изменений в конфигурации

 
Вообще, в конфигурации на столько много всего меняется. Каждый день вносятся настройки и данные. Каждая галочка, каждая единица информации вносится в большую корзину под названием информационная база и поди пойми, что там находится и уж тем более попробуй оценить, что это нужно внедрить на другую конфигурацию или платформу. Ведь множество вопросов в процессе работы решалось и устранялось, добавлялось, внедрялось. Конечно, если речь идет о небольшой конфигурации складского или бухгалтерского учета, то ее перевод может быть облегчен. Но даже при этом возникает все равно «момент перехода», а это и становится камнем преткновения в каждом внедрении системы.

Можно сравнить в большей степени это с несущимся локомотивом с множеством вагонов. В каждом вагоне своя организационная структура. И даже если они друг за другом зацеплены  — имеют взаимосвязь (ведь каждый вагон  — это каждое подразделение), то всё учесть каждую мелочь в новой системе: перенести весь багаж, инвентарь, бывает и сделать это все одномоментно. А в большинстве случаев это требуется сделать за 1 день. Т.е. с вечера перенести и настроить и с утра уже в другом поезде. И вот как сделать так, чтобы пассажиры (пользователи) почуствовали себя комфортно. В большинстве случаев на первый взгляд пользователи совершенно не замечают удобства в новом. Они привыкли все к одному и именно этот момент шоковой терапии  — переход в новую реальность  — ставит многие системы при внедрении в тупик. Здесь главную роль играет именно начальник поезда (руководитель проекта автоматизации). Но он должен быть не один. Должен быть и машинист (системный администратор), бортпроводницы (помошники-консультанты), механики (программисты).

Как вы думаете сколько нареканий к новой системы будет в самом начале? Да пусть она трижды лучше (опять же с точки зрения кого? внедренца?). Пользователям это объяснить потребуется время. А больше даже не объяснить, а доказывать нужно.

На сегодня существует потребность перехода на управляемые формы на новую платформу 1с 8.3. Во многих случаях этот переход сопряжон со многими трудностями. И не только с привыканием к новому интерфейсу, работе в нем или в разработке на новой платформе, но и в том, что приходится переводить все, что было за много лет внедрено. А это все равно что, все у всех вагонов поезда переделать колесную часть на новую колею. Кому это нужно? Предприятию это нужно? На нем и так еще не решено очень многое. Потребности бизнеса растут из-зо дня в день. И вдруг раз… Нужно переходить на новый локомотив  — на новую платформу 1с8.3.

 


Предостережение

С доработками тоже нужно быть осторожными. Вот накидают горе-программисты код в базе и довольные уходят, так как предприятие их услугу оплатило. Возможно и не такие придут сделают. И профессионалы могут ошибаться и на скорую руку сделают быстро заплатку. А дальше кто прийдет и это творчество увидит, то что с этим делать? При этом всегда следующие будут ругать предыдущих. Может быть из-за того, чтобы самим себя показать вот какие мы «умные», либо действительно так обстоят дела и код написан безобразно.
 
Поэтому мы четко утверждаем: у конфигурации должен быть «хозяин»  — администратор, чтоб он по крупицам собирал все в одно целое и понимал все взаимосвязи и что хорошо, а что плохо для информационной системы и в целом для автоматизации всего предприятия.


Реальность

Теперь возьмем новое веяние с управляемыми формами Представьте, что управлемые формы стали еще больше сложней (кому как конечно) и несведущие профессионалы в кавычках начнут там вносить изменения и код на столько превратиться может в мешанину, что разобраться будет сложнее. Конечно здесь нужны специалисты, умеющие в этом разбираться. А в большинстве случаев тот, кто имеет большой многолетний опыт за плечами на обычных формах с большим трудом будет переучиваться ездить по новым рельсам. А стало быть он и в этом новых условиях программирования будет применять старые «проверенные» способы вместо применения передовых методов. А управляемые формы требуют изменения. Управляемые формы не так уж и управляемые.

Реальность такова, что менять конфигурацию будут. И без этого никуда не уйти. А как же оптимизация с помощью добавления индексов в базу, т.е. добавление индексируемых реквизитов для увеличения быстродействия. Ведь это не сделать в режиме пользовательского интерфейса. Это обязательно нужно идти и менять в конфигураторе. Возможно разработчики именно из-за этого оставляют без этих самых индексов типовые базовые конфигурации. Хотя более чем странно. Наоборот бы лучше добавили индексы чуть ли не полный список. А уж затем для уменьшения нагрузки на базу программисты бы убирали.

 


Вывод

В целом отметим, что типовой код может содержать ошибки, множество неоптимальностей и нужно будет править. А ошибки в типовом коде существуют. Множество существует. Мы не станем сейчас их приводить в пример, но на этом сайте они представлены и будут дополняться с рекомендациями по изменению.

Типовые конфигурации также затачиваться будут под реальные бизнес-задачи каждого предприятия. А задач у растущих и динамично развивающихся предприятий становится все больше и больше.

Отметим также конфигурации нужно оптимизировать для ускорения процессов работы в базе как самой программы, так и работы пользователей. Без изменений типовых конфигураций не обойтись. Да и зачем этому препятствовать, когда сам инструмент-платформа 1с именно заточена для этого, чтобы каждое предприятие могло добавить свои специфичные отраслевые вещи без ущерба основной базовой конфигурации. Даже если специалист-программист затронет типовой код. На то он и специалист  — он учтет эти изменения при установке следующих обновлений.

 

<< Первое знакомство с разработчиком    Далее: Бизнес. Скорость. Шоколад >> 

Хаки для Dle 10.4
скачать форекс советники Ilan

Вернуться назад