Критерии сложности конфигураций
Добрый день!
Есть какие то критерии когда считается, что конфигурация сложная?
Работаю сейчас на самописке. Около 5 лет. Сначала она была простая и не много дорабатывалось, больше поддержка. Но вот года 3 как очень много ее дорабатываем. Пилим и пилим. Я уже всего не помню что и зачем делалось. Начинается какой то хаос. И я понимаю, что нам нужен еще архитектор или человек, который будет следить за структурой и заниматься только этим. Подскажите, как можно это аргументировать? Есть какие то критерии того, что база уже сложная?
Есть какие то критерии когда считается, что конфигурация сложная?
Работаю сейчас на самописке. Около 5 лет. Сначала она была простая и не много дорабатывалось, больше поддержка. Но вот года 3 как очень много ее дорабатываем. Пилим и пилим. Я уже всего не помню что и зачем делалось. Начинается какой то хаос. И я понимаю, что нам нужен еще архитектор или человек, который будет следить за структурой и заниматься только этим. Подскажите, как можно это аргументировать? Есть какие то критерии того, что база уже сложная?
По теме из базы знаний
- Перенос данных из учетных программ Парус в конфигурации 1С
- Бонусная система для УТ 10.3
- Какими критериями стоит руководствоваться при выборе партнера на проект по автоматизации? Часть 2
- Реальный кейс по внедрению CodeReview
- Переход с УПП на ERP. Сложности выверки регламентированного учета при «плавном переходе»
Ответы
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
(1)Для «показать» обычно нужны цифры. Я так понял хранилище есть, значит можно сравнить, например, количество объектов/форм/строчек кода сейчас и допустим два года назад.
В типовых делят по подсистемам, например, бюджетирование точно отдельно. Подумайте, может и у вас есть такие отдельные области.
В типовых делят по подсистемам, например, бюджетирование точно отдельно. Подумайте, может и у вас есть такие отдельные области.
(14) Меня мало интересует, что они там в своем руководстве в своей голове понимают под различными терминами и условиями труда. У меня разговор короткий: если работы много - выделяй ресурсы. Деньги - это ресурсы, на которое можно купить время у нового сотрудника. У существующего сотрудника уже нет времени для продажи за твои деньги. Система уходит в энтропию. И если тебе жалко денег на нового сотрудника - то выбирай: либо скорый окончательный развал учета и стагнация твоего бизнеса (претензий не принимаю), либо "я уже и заявление написал".
Работает безотказно.
Работает безотказно.
(2) :-) Да вот у нас один так и сделал. Потому что нет вообще возможности проанализировать, проверить почитать что нового. Удовольствия ноль. Был красивый уютный домик. А сейчас какие то трущобы без порядка. Руководство по-моему только обрадовалось. Меньше денег платить. И мы теперь и его разработки поддерживаем.
(5)
у вас контакт на 25 лет без возможности прервать ?
семейные или жилищные обстоятельства...конечно, может быть и личное
но если вы уже видите, что скоро будет взрыв, то почему-бы не поискать другое место...?
понимаю, сложно разрывать любые отношения, может даже и зарплата будет меньше, но кто восстановит здоровье или мозги .даже за большие деньги ?
аргументы....смотря сколько человек в коллективе дорабатывает-собраться отдельно , поговорить про последствия такого пути и хотя-бы договориться об общей линии действия...конечно , вам виднее в вашем коллективе..
у вас контакт на 25 лет без возможности прервать ?
семейные или жилищные обстоятельства...конечно, может быть и личное
но если вы уже видите, что скоро будет взрыв, то почему-бы не поискать другое место...?
понимаю, сложно разрывать любые отношения, может даже и зарплата будет меньше, но кто восстановит здоровье или мозги .даже за большие деньги ?
аргументы....смотря сколько человек в коллективе дорабатывает-собраться отдельно , поговорить про последствия такого пути и хотя-бы договориться об общей линии действия...конечно , вам виднее в вашем коллективе..
(26)
или на инфостарте скоро будет тендер
Доработка УНФ и УТ10 (От 300 руб. до 210 000 руб.)
Конфигурирование 1С
Приветствую. Требуется программист для доработки конфигураций. В среднем в месяц задач на 70-140 часов. Написание внешних обработок Работа с внешним API Обмены не типовые
----------------------------------------------------------------
ведь последствия хаоса всегда дороже обойдутся , если не вам, то руководству
вопрос только времени и желающего попробовать это на себе.
или на инфостарте скоро будет тендер
Доработка УНФ и УТ10 (От 300 руб. до 210 000 руб.)
Конфигурирование 1С
Приветствую. Требуется программист для доработки конфигураций. В среднем в месяц задач на 70-140 часов. Написание внешних обработок Работа с внешним API Обмены не типовые
----------------------------------------------------------------
ведь последствия хаоса всегда дороже обойдутся , если не вам, то руководству
вопрос только времени и желающего попробовать это на себе.
(26) Я только сейчас начала осознавать, что реально все катится в одно место и что нужен еще кто то. И еще я по характеру лояльна к месту к коллективу где работаю, к руководителю. И все это время работала, старалась, чтобы все работало и прочее. Думала в нас дело, надо работать лучше. Но сейчас поняла, что просто уже не успеваю. И еще останавливает, что работаю на самописке, типовых почти не знаю. Наверное не много мест где могу пригодиться.
(30) При грамотном подходе самописка - отличная вещь для прокачивания умений проектирования и разработки нового функционала с нуля. Но, как у нас всегда, время не позволяет грамотно и обстоятельно заниматься этим - начальству всегда надо "здесь и вчера".
С отсутствием практики на типовых - да, есть небольшая засада такая. Но доскональное знание типовых необходимо скорее консультантам для поддержки бухов.
Грамотный разработчик обычно изучает типовые в процессе работы. Причем, только те, которые есть в его хозяйстве. Например, 5 лет сидеть на УТ - это практически означает расстаться со скиллами по БП, и наоборот. И это не трагедия.
С отсутствием практики на типовых - да, есть небольшая засада такая. Но доскональное знание типовых необходимо скорее консультантам для поддержки бухов.
Грамотный разработчик обычно изучает типовые в процессе работы. Причем, только те, которые есть в его хозяйстве. Например, 5 лет сидеть на УТ - это практически означает расстаться со скиллами по БП, и наоборот. И это не трагедия.
(32) Тогда да, для самописки нужен хороший сторож-архитектор. Да в принципе и для любой типовой, если её пытаются нещадно кастомизировать. Но в самописках есть и обратная сторона - обычно владельцу она и так обходится дороже, чем использование типовой, а тут еще и второго человека брать очень дорогого... Вилка такая, неопределенная.
Ну, основное как аргумент:
Но, можно документировать изменения в структуре конфигурации, в изменениях учета и т.п. самими разработчиками. И тогда архитектор не понадобится. Естественно, это отнимет время у разработчиков.
Архитектор должен планировать изменения до их внесения, а не отслеживать за разработчиками, когда они уже внесены.
Я уже всего не помню что и зачем делалось. Начинается какой то хаос.
Но, можно документировать изменения в структуре конфигурации, в изменениях учета и т.п. самими разработчиками. И тогда архитектор не понадобится. Естественно, это отнимет время у разработчиков.
Архитектор должен планировать изменения до их внесения, а не отслеживать за разработчиками, когда они уже внесены.
(3) Пишем, пишем, но не особо помогает. Нужно более вдумчиво, созидательно все продумывать. Пусть планирует до, мы только все будем рады. Потому что сейчас кто то что то доработал, другой делает то же самое, хотя можно сделать более универсально. Иногда какие то взаимоисключающие вещи делаются. Одному хорошо сделали, а другой звонит и орет. И если будет архитектор, то может быть к его аргументам будут прислушиваться, а нас просто не слушают.
(7) Ключевое слово "может быть". Если не сработает, то шишки посыпятся на инициатора.
Ну, основные аргументы вы и сами перечислили, а что-то еще без знания вашей специфики работы и прочего сложно что-то советовать.
Чтобы меньше орали нужно все доработки делать после нормального оформления заявки с их утверждением заранее установленными ответственными лицами от заявителей, а не по звонку.
У меня был опыт поддержки конфы, использовавшейся в нескольких организациях одновременно. Сильно дописанная и переписанная была. Так вот изменения по заявке от одной организации делались под условие с проверкой на эту самую организацию, т.к. не понятно было, как это повлияет на работу пользователей других организаций. А если заявка поступала от другой, ее также добавляли в условие.
Конечно, это не касалось изменений вызванных, например, изменением законодательства, которые должны быть едины для всех организаций, использовавших конфу. Естественно использовали комментарии в коде для блока, где что-то менялось, и при помещении в хранилище добавлялся краткий комментарий: что, для чего и по чьей заявке было сделано.
В общем, обходились без архитектора, т.к. выбить единицу для этого было нереально. Скорее эти обязанности начальство кому-то накинет, причем даже без доплаты.
Ну, основные аргументы вы и сами перечислили, а что-то еще без знания вашей специфики работы и прочего сложно что-то советовать.
Чтобы меньше орали нужно все доработки делать после нормального оформления заявки с их утверждением заранее установленными ответственными лицами от заявителей, а не по звонку.
У меня был опыт поддержки конфы, использовавшейся в нескольких организациях одновременно. Сильно дописанная и переписанная была. Так вот изменения по заявке от одной организации делались под условие с проверкой на эту самую организацию, т.к. не понятно было, как это повлияет на работу пользователей других организаций. А если заявка поступала от другой, ее также добавляли в условие.
Конечно, это не касалось изменений вызванных, например, изменением законодательства, которые должны быть едины для всех организаций, использовавших конфу. Естественно использовали комментарии в коде для блока, где что-то менялось, и при помещении в хранилище добавлялся краткий комментарий: что, для чего и по чьей заявке было сделано.
В общем, обходились без архитектора, т.к. выбить единицу для этого было нереально. Скорее эти обязанности начальство кому-то накинет, причем даже без доплаты.
(15) С чего вдруг?
Условие по организации было, когда изменение было не для всех, иначе условие убирали. Поэтому, если новой организации, что-то нужно было что работало по новой схеме, по которой работали отдельные организации, то ее по заявке от нее же и добавляли.
Но это, естественно, касалось "нестандартных" нововведений. Для остальных, стандартизированных, переключение делалось через учетную политику, например. Или подобное.
Условие по организации было, когда изменение было не для всех, иначе условие убирали. Поэтому, если новой организации, что-то нужно было что работало по новой схеме, по которой работали отдельные организации, то ее по заявке от нее же и добавляли.
Но это, естественно, касалось "нестандартных" нововведений. Для остальных, стандартизированных, переключение делалось через учетную политику, например. Или подобное.
(19) Так оно и так в одном хранилище все было.
А как переключать: через константы или РС учетной политики, это дело конкретной ситуации и решения и на результат не влияет.
А добавлять под каждую нестандартную доделку/хотелку реквизит/константу это не камильфо.
Помню, как как-то раздули РС учетной политики так, что при запуске тестирования и исправления процесс валился с ошибкой из-за того что у 2008 скуля было ограничение на размер запроса меньшее, чем он формировался этой операцией, создаваемого платформой.
Приходилось выгружать регистр в xml, очищать, проводить тестирование/исправление, и потом загружать значения обратно.
А как переключать: через константы или РС учетной политики, это дело конкретной ситуации и решения и на результат не влияет.
А добавлять под каждую нестандартную доделку/хотелку реквизит/константу это не камильфо.
Помню, как как-то раздули РС учетной политики так, что при запуске тестирования и исправления процесс валился с ошибкой из-за того что у 2008 скуля было ограничение на размер запроса меньшее, чем он формировался этой операцией, создаваемого платформой.
Приходилось выгружать регистр в xml, очищать, проводить тестирование/исправление, и потом загружать значения обратно.
(22) Можно выгрузить текущую и давнюю конфигурации в файлы (не cf, а xml) и сравнить их. Так не только покажет количество добавленных строк кода, но и количество добавленных объектов конфигурации.
Можно еще вывести в таблицу статистику добавления правок в хранилище. И добавить как аргумент ее.
Можно еще вывести в таблицу статистику добавления правок в хранилище. И добавить как аргумент ее.
Я думаю, правильнее будет сравнивать конфигурации 3 года назад и сейчас, по критерию функциональности. Начальству совершенно ничего не скажут миллион строк кода сейчас и 2 тысячи тогда, а вот объем функционала программы тогда и сейчас, может вполне себе корректно им это показать. Еще лучше будет разбить отчет по подсистемам (соответственно, объяснить начальству что это разделы), что и где добавилось, что изменилось. Как показывает опыт, предприниматели любят цифры, т.е. можно даже некий график производительности составить, но это так, домыслы.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот