Для визуализации различий можно использовать https://demo.bpmn.io/diff. С ним можно увидеть какие элементы были добавлены, поправлены. Я рекомендую мержить внося изменения в моделере, чтобы просматривать и проверять отсутствие противоречий в схеме. Теоретически, можно прокачать свой скилл и мержить на уровне xml, но есть вероятность ошибиться. Также есть линтер, который позволяет валидировать схемы: https://github.com/camunda/camunda-modeler-linter-plugin
Полностью согласен. Есть интересный случай из практики: на соседнем проекте был криво реализован oauth. Мы взяли какую-то стандартную нодовскую библиотеку для этих целей и пытались использовать, но потом выяснилось, что под наш случай она не подходит. И, хвала небесам, все, что было необходимо сделать, чтобы библиотека заработала — вызвать недокументированную приватную функцию с кастомными параметрами. Это не потребовало от нас форкать библиотеку, городить костыли для доступа к данным,… Просто сделали вызов функции и оставили комментарий с тремя восклицательными знаками почему здесь вызывается эта функция. И это позволило нам дальше участвовать в хакатоне, не тратя время понапрасну.
Ну и еще к слову о приватности: никогда не понимал как тестировать приватные методы. Приватный метод вполне может содержать нетривиальную логику и его надо обязательно протестировать. А городить костыли в виде пубичных методов, которые существуют единственно для того, чтобы вызвать приватный — уже какое-то убожество.
В принципе, возможность создать метод с подчеркивание и обозначить таким образом, что он приватный или дописав перед ним jsdoc-нотацию private мне всегда нравилась. При необходимости такие методы можно вызвать из консоли, их легко протестировать, легко отлаживать код, вызывая при необходимости такие методы прямо в дебаггере. Ну а то, что кто-то упрямо использует то, что ему сказали не использовать — ну сорян, сам мудак)
Для визуализации различий можно использовать https://demo.bpmn.io/diff. С ним можно увидеть какие элементы были добавлены, поправлены. Я рекомендую мержить внося изменения в моделере, чтобы просматривать и проверять отсутствие противоречий в схеме. Теоретически, можно прокачать свой скилл и мержить на уровне xml, но есть вероятность ошибиться. Также есть линтер, который позволяет валидировать схемы: https://github.com/camunda/camunda-modeler-linter-plugin
Спасибо за замечание, поправил
Ну и еще к слову о приватности: никогда не понимал как тестировать приватные методы. Приватный метод вполне может содержать нетривиальную логику и его надо обязательно протестировать. А городить костыли в виде пубичных методов, которые существуют единственно для того, чтобы вызвать приватный — уже какое-то убожество.
В принципе, возможность создать метод с подчеркивание и обозначить таким образом, что он приватный или дописав перед ним jsdoc-нотацию private мне всегда нравилась. При необходимости такие методы можно вызвать из консоли, их легко протестировать, легко отлаживать код, вызывая при необходимости такие методы прямо в дебаггере. Ну а то, что кто-то упрямо использует то, что ему сказали не использовать — ну сорян, сам мудак)