Как убить конфигурацию 1С и забить... Введение.
Коллеги, всем хорошего настроения. За десять лет уже многое повидал и многому научился у 1С, видимо настало время со всем этим разобраться, и передать опыт другим. Постараюсь минимально, вообще эта тема очень большая, каждый вопрос порождает ещё несколько вопросов и так далее с прогрессией. Мое отношение к платформе можно описать фразой Аристотеля, -"От любви до ненависти - один шаг." Не буду описывать свои чувства, и сразу озвучу глобальную проблему. За последние 10 лет очень сильно изменился подход к программированию конфигураций, но многих это мало волнует, и они остались верны "старой Вере". Это касается не только программистов, но и руководителей компаний, которые требуют от программистов невозможное, а потом жалуются на затраты раздутого штата. Давайте посмотрим на сухие цифры, которые могут посмотреть абсолютно все, посмотрите размеры файлов конфигурации УТ10.3 и 11.5, первая менее 100мб, вторая уже давно перевалила за 500мб. Да, в последней запакованы драйвера и XML, это все присутствует и в конфе 10.3, в последней их чуть больше, и все же это не сопоставимо с текущими размерами файлов. Про различающееся количество регистров, просто промолчу. В старой 10.3 (10.2 не беру в расчет), простой как болт и гайка, реверс инжиниринг большинства заложенного функционала проводился в среднем за 15 минут со всеми точками останова, сейчас эти цифры увеличились в разы иногда можно провести за этим занятием не один день. Дальше углубляться не буду, т.к. эта тема растянется на часы. Разработчики 1С, далее Поставщик, собрали довольно не плохую команду, они пишут сложные алгоритмы, которые им любезно предоставляет собственная команда аналитиков, тестировщики тестируют, архитекторы придумывают все пути отхода, а маркетологи с манагерами создают агрессивный маркетинг. И тут наступает момент, когда штатный программист компании N, говорит, переписать, однозначно переписать. Это утрированно, но это реальность. Дорабатывать конфу все-таки приходится, иногда сами поставщики допускают ошибки, и ожидать исправления от поставщиков нет времени. Очень часто идут задачи по упрощению интерфейса, который существенно экономит время сотрудника компании. А иногда есть не типовой жизненно важный для компании бизнес процесс, и вот тут наступает ответственный момент, который зависит не только от программиста, но и от руководителей, просящих программиста. Лично моя философия простая, каждая строчка кода порождает расходы на её содержание, она косвенно связана с расходом дорогого времени программиста, самое простое её нужно прочитать, самое сложное, понять почему она выдает ошибку, остальное множество причин опустил. Поэтому я всегда заказчикам в шутку говорю, если ваш процесс стоит менее 100тыс. рублей прибыли компании, вышлите задачу через почту России, там она спокойно отлежится и бесслезно канет в небытие. И так, первое, заказчик, как правило руководитель, должен понимать экономическую составляющую процесса. Как правило 70 процентов выполненных задач не пользуются популярностью у пользователей, и далее лежат в конфиге мертвым легаси, которого боятся абсолютно все программисты, т.к. в своё время не создали нормальную документацию по коду и т.п. Наступает второе, если все таки задача попадает в руки программиста, которому "старая Вера" говорит - "Перепиши тут все", то дальнейшие посты будут ему полезны, чтобы не убить конфигу, и вовремя обновиться, на релиз версии с НДС 25%, тьфу тьфу тьфу.Тут наверное прерву этот пост, потому что далее, я надеюсь, написать цикл статей, как не допускать ошибок при доработках конфигурации, используя встроенные и внешние инструменты. Как следовать правилам разработки, и где поставить свечку))) Обещаю только одно, методологии не будет её полно в интернете, только применение на практике.