Комментарии 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тыс вызовов веб-сервисов (это разные запросы к серверу из "внешних систем") в секунду, а еще не меньше через очереди идет...
Вот тут описывал одну из задачек из личного пула.
1С это проприетарный вендорский продукт. Меняем шило на мыло. lsFusion вообще маргинален крайне и по сообществу и по рынку присутствия - Беларусь и по подходу к разработке
по сообществу и по рынку присутствия - Беларусь
А что значит рынок присутствия для open source проекта ? На lsFusion пишут люди из многих стран.
о подходу к разработке
А в чем маргинальность подхода ? Тоже пишется код в IntelliJ IDEA. Тот же Git. "Маргинальность" в 1С в этом плане гораздо выше.
Трудности перевода. Мигрируем учетные системы после переезда на отечественную СУБД