(13) Сейчас программистов 6 человек включая меня. Пользователей более ста. На предыдущей работе пользователей было свыше 300. Да как и писал выше сейчас нет того ада наверное, который есть у других, что они вынуждены использовать более так сказать серьезные системы типа Git. Я не негатювлю, просто люди должны понимать, что Git не панацея и не всегда нужен, можно обходиться и более простым функционалом.
| Цитата |
|---|
| Я правильно понимаю, что вы ERP дорабатываете через расширение? |
Да дорабатываем через расширения все, при этом стремимся чтобы расширение было только одно, но сейчас их два. Второе заточено под интеграции с 1С ДО 2.1 (в нем тоже одно расширение). С Самого начала как начали использовать ERP, все дорабатывали только через расширения. Эта практика пока не подводила не считая иногда встречавшиеся глюки платформы. Разработка с применением расширений проходит куда интереснее чем портить типовой код, обновления на новые релизы протекают гладко, большое подспорье это проверка возможности применения расширений с автоматическим поиском проблем, хоть и не всех. В свое время я услал восстанавливать допилы в БП 2.0 - 3.0 при обновлении, в начале своей карьеры, кошмарная рутина стала. На ERP это было бы еще то удовольствие, не завидую тем кто пилит типовую.
Если снимать замки с типовой ERP, то банально как было замечено, обновление ставится не 30 минут, а 3 часа. Применять хранилище на типовой конфигурации пробовал, лютый трэш с длительностью захвата всех объектов, со сдачей в хранилище. Само по себе хранилище растет в размере большими темпами...
| Цитата |
|---|
| Также хотелось уточнить, а как вы храните документацию, |
Документации к сожалению мало, по сути как и везде кто-то ставит ТЗ на ломанном языке, мы пытаемся реализовать. В сложных отчетах или обработках сразу в расширении пишется справка, чего вполне хватает.
От внешних отчетов и обработок планомерно уходим, разгребаем технический долг доставшийся в конце 2021 года, все переносим в то самое расширение где и версионируется оно уже хранилищем конфигураций.
До этого программисты 1С на предприятии пытались Git использовать для внешних обработок и отчетов, посмотрев на что я прекратил эту практику на корню ибо времени на то чтобы запихнуть в Git обработку или отчет, а потом положить в базу в справочник внешних обработок, уходило больше чем просто работать с хранилищем (свыше 300 обработок и отчетов было внешних). А ведь те программисты гавкались даже на этапе размещения в базе своей обработки ибо кто-то на несколько минут раньше туда положил такую же, но со своими доработками, ну и закономерно доработки одного терялись, так что внешние файлики это очень плохое решение. Позволительно только с нуля что-то как внешнее писать, отлаживается, а потом вживляется в расширение и уже потом групповая доработка через хранилище.
| Цитата |
|---|
| (правда непонятно, зачем неготовые объекты в системе, еще не протестированные пользователями), |
Вы там видимо в каки-то тепличных условиях доработки ведете, видимо в столице родины нашей. Мы тут в глубинке не избалованы огромным количеством тестировщиков, кодревьверов и еже с ними. Приходится полагаться на свой многолетний опыт и то как ты изначально код пишешь, то есть не как курица лапой, где ничего не понятно. Я гоняю за несоблюдения аккуратности. Так и вот сдается код в котором ты уверен и конечно же протестирован хоть даже и бегло на тестовых базах. От того, что ты например выполняя большую работу в некотором общем модуле изобрел новую функцию получения минимума из двух чисел и сдал ее в хранилище, система не упадет, зато другой программист получает возможность и свое что-то в модуль сдать, а ты в каких-то других частях еще не дописанной программы уже используешь свою функция получения минимума.
И разве кто-то мешает допустим сделать костяк некоторого справочника, без блэк джэка и ... и сдать его в хранилище и применить. Потом юзеры возможно без некоторого комфорта начинают туда вбивать данные, а ты тем временем пилишь кнопочки, которые добавят в будущем комфорта. Стоит упомянуть, что все же между программистами и юзерами у нас есть и только одна линия обороны в виде пяти специалистов 1С, которые в отличии от юзеров в состоянии материалы с 1С ИТС читать и так же проверить за программистом потыкав кнопочки в новом или допиленном старом функционале и то чисто для успокоения и отрапортованию юзеру, что работа сделана.
| Цитата |
|---|
| В хранилище при такой реализации нужно как-то покрывать дополнительно скриптами для переезда доработок между отдельными хранилищами: разработка, тестирование, рабочие. |
У нас кощунство, мы и разрабатываем и тестируем, и применяем в боевые базы все из одного хранилища, экономия времени катастрофичная, отладке не мешает, ибо у программистов и так у всех свои базы, где еще до сдачи доработок может проверить функционал как он сам, так специалист 1С и юзер.
| Цитата |
|---|
| Конечно, если ты сам себе постановщик, разработчик, тестировщик, и тимлид, то такая схема работа вообще не нужна. |
Вот вот, ближе к истине, я тимлид, а моя команда программистов молодцы, каждый сочетает в себе: постановщика (под контролем меня), разработчика, тестировщика.
Такой состав функций у каждого программиста позволил за пол года без лишних соплей перевести 15 (1С КА 1.1) филиалов крупной фирмы в ERP, под знаменем новой одной организации. Потом в эту же базу за 3 месяца завести крупное производственное предприятие (1С УПП 1.3) являющейся материнским для той первой организации. Потом выполнить там же слияние организаций за 3 месяца. Предприятие видя, что программистов мало, а работ море пыталось привлечь много разных франчей. Только они слились все уже на этапе коммерческих предложений. И только из Первого Бита пару ребят удалось все же на процентов 5 работ задействовать на момент объединения фирм.
На новой работе применяя тот же подход, за 2.5 месяца удалось перевести фирму с релиза ERP 2.4 на 2.5.7, очень запущенная база. Ударными темпами, но вытянули, теперь разгребаем технический долг доставшийся по наследству (и это не только ERP). И тут хранилищ конфигураций за глаза хватает. В каждый момент времени программисты видят, что кто-то уже колупает некий объект и что можно просто заняться или другой работой или узнать, а нужен ли он еще, решается все без конфликтов и быстро. Проблем со слиянием доработок разных программистов нет ибо разработка и изменения последовательные получаются, сначала один допилил, потом другой, и так далее. Мы уже готовы ставить 2.5.11 релиз ERP, как только он перекочует в колонку стабильных. При этом нужно переименовать в расширении только одну подсистему и мы обновились (проверено на тестовой).
По сути можно или волокиту разводить бумажную с кучей прослоек специалистов разных уровней, чтобы перекладывать ответственность (обезьянку), или просто работать без лишних бесполезных порой людей, делать работы частями и отдавать в работу частями, если это возможно, нечего так сказать тянуть известно кого за известно что. Если работы сдавать частями, то и обратную связь от пользователей начнешь раньше получать и не придется переписывать все ибо они хотели по другому.
Ладно все это не о Git.
Кому надо тот его будет использовать.
Но я надеюсь, что все же на волне санкций, фирма 1С развивать будет свой инструментарий.
