Как стать автором
Обновить

Трудности перевода. Мигрируем учетные системы после переезда на отечественную СУБД

Уровень сложностиСредний
Время на прочтение10 мин
Количество просмотров2.4K
Всего голосов 16: ↑15 и ↓1+15
Комментарии10

Комментарии 10

Учетные системы часто включают в себя бизнес-логику

Для систем с бизнес-логикой есть специализированные, заточенные под это платформы

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

После увольнения этого разработчика будете искать нового, который по понятным причинам разобраться в этом спагетти коде не может и переписывать все снова?

Для систем с бизнес-логикой есть специализированные, заточенные под это платформы

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

После увольнения этого разработчика будете искать нового, который по понятным причинам разобраться в этом спагетти коде не может и переписывать все снова?

Разбираться в спагетти-коде приходится всегда, когда вы получаете плохо задокументированный код, созданный командой разработки, которая отработала на вашем проекте все самые хайповые технологии;) Для всех остальных случаев есть гайдлайны от фреймворка, документация и обучающие материалы в открытом доступе.

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

Думаю, тут подразумевались не CRUD системы, а что-то более сложное.

То, что описываете Вы, по большому счету не содержит особой бизнес-логики, тут больше UI для представления данных.

Полагаю, вопрос был по поводу более сложных, высоконагруженных, систем (часто еще работающих в режиме реального времени или с минимальными временными задержками), работающих с большими объемами данных (десятки и сотни миллионов записей, десятки тысяч взаимосвязанных объектов БД), где UI мало, зато много фоновых процессов, где реализуется действительно сложная бизнес-логика. Биллинговые системы, или, того хуже, банковские. Там UI очень мало и оно, как правило, вынесено на "внешние системы" и общается с сервером через, например, REST API (или подобные механизмы) и само по себе не имеет прямого доступа к БД.

Именно для таких систем и придумываются "специализированные платформы" и "специализированные языки" типа PL/SQL у Oracle или RPG (RPGLE) у IBM.

И перейти с такого на какую-нибудь Java или C# без потери производительности (которую придется компенсировать кратным увеличением вычислительных мощностей просто для того, чтобы все не "встало колом") практически нереально. Да и по времени это займет годы - там миллионы строк кода придется переписать заново, а потом все это еще оттестировать.

Разбираться в спагетти-коде приходится всегда, когда вы получаете плохо задокументированный код, созданный командой разработки, которая отработала на вашем проекте все самые хайповые технологии

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

Причем, "команда" - это и архитекторы и аналитики и разработчики... Плюс, естественно, система ведения и хранения документации - BRD, FSD, архитектурные вижены... Все это тоже должно поддерживаться в актуальном состоянии, равно как и вся кодовая база.

Все это неотъемлемая часть для стабильного существования долгоживущих (LALT - Long Application LifeTime) проектов.

Бизнес-логика и требования производительности я бы все-таки разделял. Может быть система с совершенно "адской" бизнес-логикой расчета - типа оптимальный раскрой чего-нибудь, но нагрузка на уровне 1000 бизнес-транзакции в день. Такую систему вряд-ли потребуется писать на чем-то специализированном. Python разработчик вообще прекрасно справится.

Да, согласен. Я со своей колокольни смотрю (банковская система - АБС). 50+ млн клиентов (а сколько еще всего с каждым клиентом связано), очень много разных сущностей (клиентские данные, счета, карты, доверенности, доверенные лица, риски, запреты, лимиты, тарифы... и т.д. и т.п). Тысячи, если не десятки тысяч разного рода бизнес-процессов постоянно крутятся...

И при этом 100+ млн платежей в сутки, 65тыс вызовов веб-сервисов (это разные запросы к серверу из "внешних систем") в секунду, а еще не меньше через очереди идет...

Вот тут описывал одну из задачек из личного пула.

Забавно, что в контексте учетных систем Вы забыли упомянуть самую распространенную low-code платформу , или ее бесплатный конкурент lsFusion. Да, у 1С есть множество проблем, но все равно даже на ней все делается гораздо быстрее и дешевле, чем на описанных в статье платформах.

1С это проприетарный вендорский продукт. Меняем шило на мыло. lsFusion вообще маргинален крайне и по сообществу и по рынку присутствия - Беларусь и по подходу к разработке

по сообществу и по рынку присутствия - Беларусь

А что значит рынок присутствия для open source проекта ? На lsFusion пишут люди из многих стран.

о подходу к разработке

А в чем маргинальность подхода ? Тоже пишется код в IntelliJ IDEA. Тот же Git. "Маргинальность" в 1С в этом плане гораздо выше.

сколько вакансий на HH.ru?

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий