|
Действия ...
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
17.04.2017, 11:02
|
|||
|---|---|---|---|
|
|||
Карта модулей приложения |
|||
|
#18+
Как правильно составлять карту модулей приложения? Есть большое запутанное приложение, в котором много различных модулей, и они постоянно друг друга вызывают и связи эти по первой можно вообще запутаться в этих макаронных вызовах, хочется понять спросить узнать, есть ли какие-нибудь методики описания структуры связей модулей приложения? как-то отслеживать вложенность вызовов, документировать этот процесс в наиболее понятную форму? Придать этому многообразию структурированный вид? Кто сталкивался и чкакие подходы использвал в этом случае? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.04.2017, 11:20
|
|||
|---|---|---|---|
Карта модулей приложения |
|||
|
#18+
RMagistr2015, да многие сталкивались с так называемым монолитным приложением. Кто-то до сих пор с ним живёт, а кто-то распилил на отдельные сервисы и зарефакторил, отдав тем самым технический долг. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.04.2017, 11:24
|
|||
|---|---|---|---|
|
|||
Карта модулей приложения |
|||
|
#18+
skyANA https://habrahabr.ru/post/249183/ https://habrahabr.ru/company/it-grad/blog/273583/ Спасибо, Брат )))) Ты понимаешь лдей и их боль )))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.04.2017, 13:34
|
|||
|---|---|---|---|
|
|||
Карта модулей приложения |
|||
|
#18+
RMagistr2015Как правильно составлять карту модулей приложения? Указываешь линкеру при сборке соответствующий ключик и он сам эту карту составит. Как ты её потом будешь визуализовать - другой вопрос. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.04.2017, 14:12
|
|||
|---|---|---|---|
Карта модулей приложения |
|||
|
#18+
RMagistr2015Кто сталкивался и какие подходы использвал в этом случае? Графы, и ещё раз графы. И не жалеть букв на коменты. Если doxygen поймёт исходники, то можно его+graphviz. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.04.2017, 15:43
|
|||
|---|---|---|---|
|
|||
Карта модулей приложения |
|||
|
#18+
Dimitry SibiryakovRMagistr2015Как правильно составлять карту модулей приложения? Указываешь линкеру при сборке соответствующий ключик и он сам эту карту составит. Как ты её потом будешь визуализовать - другой вопрос. а это как? А можно пример пожалуйста пожалуйста...? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
18.04.2017, 01:15
|
|||
|---|---|---|---|
Карта модулей приложения |
|||
|
#18+
Вопрос автора разбит на 2 части ИМХО. 1) собственно извлечение сведений о модулях (кст что такое модуль?) и определение связей между ними. Здесь же я предлагаю уточнить что "вызывает" и "зависит/наследует" и "включает" это разные смыслы и их надо по разному определять. Технически этот сбор сведений может быть осуществлен через статический анализ сорцов или через отладку. В maven есть специальные плагины которые рисуют отчеты по зависимостям пакетов и версий. 2) Визуализация. Средств - навалом. Про graphviz уже говорили. Добавлю что если не побрезгуете .js разработками то сильно удивитесь насколько там уже много всего создано для визуализации данных и знаний. Так-то. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
18.04.2017, 07:09
|
|||
|---|---|---|---|
|
|||
Карта модулей приложения |
|||
|
#18+
maytonВопрос автора разбит на 2 части ИМХО. 1) собственно извлечение сведений о модулях (кст что такое модуль?) и определение связей между ними. Здесь же я предлагаю уточнить что "вызывает" и "зависит/наследует" и "включает" это разные смыслы и их надо по разному определять. Технически этот сбор сведений может быть осуществлен через статический анализ сорцов или через отладку. В maven есть специальные плагины которые рисуют отчеты по зависимостям пакетов и версий. 2) Визуализация. Средств - навалом. Про graphviz уже говорили. Добавлю что если не побрезгуете .js разработками то сильно удивитесь насколько там уже много всего создано для визуализации данных и знаний. Так-то. По визуализации JS можно ример пожалуйста? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
18.04.2017, 08:43
|
|||
|---|---|---|---|
Карта модулей приложения |
|||
|
#18+
RMagistr2015, я сам не использовал js либы т.к. не специалист в js. Но если поискать в github по data+visualization то можно найти достаточно много результатов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
18.04.2017, 10:48
|
|||
|---|---|---|---|
Карта модулей приложения |
|||
|
#18+
RMagistr2015Как правильно составлять карту модулей приложения? Имхо, правильно её не составлять. Ибо это совершенно бессмысленное занятие - для мало-мальски большого приложения, как ни определяй правила построения этой "карты", получится неимоверных размеров необозримый граф, годный только висеть распечаткой во всю стену со словами "вот как у нас хреново охрененно". RMagistr2015можно вообще запутаться в этих макаронных вызовах А в "карте" запутаться ещё легче. Просто потому, что один модуль может вызывать другой из десяти различных мест в двадцати различных ситуациях - и на графе этого никак не отобразишь. А если начать укрупнять модули (естественное желание при их количестве, что бы ни называть модулем) всё это дополнительно слипается. RMagistr2015хочется понять спросить узнать, есть ли какие-нибудь методики описания структуры связей модулей приложения? как-то отслеживать вложенность вызовов, документировать этот процесс в наиболее понятную форму? Придать этому многообразию структурированный вид? Чтобы придать этому многообразию структурированный вид, нужно не отслеживать вызовы, а определить правила и добиться их соблюдения. Самое древнее и стандартное правило называется "чётко определить интерфейс каждого модуля, сделать его минимально возможным и не лазить в модуль мимо интерфейса". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
18.04.2017, 12:46
|
|||
|---|---|---|---|
Карта модулей приложения |
|||
|
#18+
softwarer неимоверных размеров необозримый граф, годный только висеть распечаткой во всю стену Не для спора - забудьте об этом. Даже самые простые инструменты помогают. Это к вопросу анализа объёма бедствий. По вопросу синтеза "модулей" высказался softwarer выше. Во-первых существует графический формат SVG, он неимоверно зуммируется без графических лесенок. Во-2-х, по исходникам составляются эксел-сводные_таблицы "кто куда откуда", они достаточно удобно фильтруются. В-3-х, вкупе с 1 и 2, помогает явление автоматизированной кластеризации по связям. В-4-х, как по кластерам рисуем отдельные подграфы, к-рые легко разводятся руками и влазят в полстраницы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.04.2017, 12:00
|
|||
|---|---|---|---|
Карта модулей приложения |
|||
|
#18+
Уже который раз сталкиваюсь с подобного рода задачей. 1. Первый раз решили проблему(причем очень успешно) разбив программу на два относительно независимых модуля, буквально два отдельных приложения. Далось это достаточно сложно, но оно окупилось, т.к. предыдущая монолитная версия просто съедала все ресурсы на отладку, поддержку, исправление багов. Еще пришлось пойти на урезания функционала, все что было не "шибко нужно" или сделано в "общем виде" было удалено. Конечно подход так-себе, но он сработал и позволил хоть как-то выбраться из нескончаемого потока жалоб пользователей. Предыдущие разы, просто переписывали все с нуля) Причем помню был один проект, его три раза переписывали, в течении четырех лет три разных команды. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.04.2017, 12:06
|
|||
|---|---|---|---|
Карта модулей приложения |
|||
|
#18+
skyANARMagistr2015, да многие сталкивались с так называемым монолитным приложением. Кто-то до сих пор с ним живёт, а кто-то распилил на отдельные сервисы и зарефакторил, отдав тем самым технический долг. Помню что-то в визио делали, диаграмму классов или диаграмму объектов, но все это особой пользы не принесло, единственное что помогало это изоляция "модулей" (кстати что такое модуль?). На мой взгляд автор больше интересуется не как можно визуализировать и т.д., а кто как визуализировал и у кого какие были в этом деле успехе, полагаю когда человек долго сидит над подобного рода проектом, он буквально "набивает руку" и начинает в оперативной памяти держать все эти взаимосвязи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.04.2017, 12:10
|
|||
|---|---|---|---|
Карта модулей приложения |
|||
|
#18+
da17он буквально "набивает руку" и начинает в оперативной памяти держать все эти взаимосвязи. По-хорошему, приложение нужно строить так, чтобы не было необходимости держать взаимосвязи в оперативной памяти. Вот есть кирпич - и кто бы как бы его ни вызывал, он работает как надо. Соответственно, при реструктуризации нужно приближать приложение к этому состоянию, тогда и не потребуется анализировать цепочки вызовов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.04.2017, 13:37
|
|||
|---|---|---|---|
Карта модулей приложения |
|||
|
#18+
softwarer, все мы знаем как "по-хорошему", но тут речь, что делать когда уже "по-плохому" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.04.2017, 13:43
|
|||
|---|---|---|---|
Карта модулей приложения |
|||
|
#18+
da17, что делать... брать наиболее горячие проблемные куски и аккуратно переписывать на "по-хорошему". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.04.2017, 23:19
|
|||
|---|---|---|---|
Карта модулей приложения |
|||
|
#18+
da17softwarer, все мы знаем как "по-хорошему", но тут речь, что делать когда уже "по-плохому" Рефакторинг/переписывание/расплатиться с техническим долгом... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
20.04.2017, 14:08
|
|||
|---|---|---|---|
Карта модулей приложения |
|||
|
#18+
RMagistr2015, Ещё наверное можно использовать утилиту depends... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
20.04.2017, 15:47
|
|||
|---|---|---|---|
|
|||
Карта модулей приложения |
|||
|
#18+
da17Предыдущие разы, просто переписывали все с нуля) Причем помню был один проект, его три раза переписывали, в течении четырех лет три разных команды. Ну это конечно полный Пэ, потратить 4-е года жизни и так и не дописать, нет лов от таких шикарных заказчиков )))) Где они живут, расскажите ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
20.04.2017, 17:45
|
|||
|---|---|---|---|
Карта модулей приложения |
|||
|
#18+
skyANA https://habrahabr.ru/post/249183/ https://habrahabr.ru/company/it-grad/blog/273583/ в общем случае эти все микросервисы такой-же тупик, как и микроядра. мало того, что цена межмодульных вызовов возростает многократно (три-четыре порядка, как минимум), так еще и порождается целый пласт новых проблем для DevOps - мониторить и деплоить монолитное приложение куда проще, чем следить за здоровьем тысяч микросервисов. а какие ожидают прелести трассировки микросервисов (а поди собери трейс лог по десяткам нод в реалтайме) - это вообще неописуемо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
20.04.2017, 17:47
|
|||
|---|---|---|---|
Карта модулей приложения |
|||
|
#18+
RMagistr2015Как правильно составлять карту модулей приложения? Есть большое запутанное приложение, в котором много различных модулей, и они постоянно друг друга вызывают и связи эти по первой можно вообще запутаться в этих макаронных вызовах, хочется понять спросить узнать, есть ли какие-нибудь методики описания структуры связей модулей приложения? как-то отслеживать вложенность вызовов, документировать этот процесс в наиболее понятную форму? Придать этому многообразию структурированный вид? Кто сталкивался и чкакие подходы использвал в этом случае? и какой смысл в этом описании, если не секрет? ну составишь ты деревья всякие и графы, да еще и с картинками миллионов стрелочек туда-сюда, что потом с этим предполагается делать? положить в архив и забыть? проблема/задача то какая стоит, на самом деле? "задокументировать все" - это не задача, это ИБД ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
20.04.2017, 18:00
|
|||
|---|---|---|---|
Карта модулей приложения |
|||
|
#18+
dbpatchмало того, что цена межмодульных вызовов возростает многократно Если не доходить до идиотизма в микромизации, то эти расходы можно сделать приемлемыми, а возможно и оказаться в итоговом плюсе. dbpatchтак еще и порождается целый пласт новых проблем Как и пласт новых возможностей. dbpatchмониторить и деплоить монолитное приложение куда проще, чем следить за здоровьем тысяч микросервисов. Если добавить в "деплоить" условие "без прерывания обслуживания" - ещё вопрос, назовём так. dbpatchа какие ожидают прелести трассировки микросервисов (а поди собери трейс лог по десяткам нод в реалтайме) - это вообще неописуемо. Прелести есть везде. Просто для примера - давайте просчитаем сценарий "одна из операций снабжена устойчивой утечкой памяти" для случая монолитного приложения и для случая микросервисов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
20.04.2017, 23:05
|
|||
|---|---|---|---|
Карта модулей приложения |
|||
|
#18+
dbpatchskyANA https://habrahabr.ru/post/249183/ https://habrahabr.ru/company/it-grad/blog/273583/ в общем случае эти все микросервисы такой-же тупик, как и микроядра. мало того, что цена межмодульных вызовов возростает многократно (три-четыре порядка, как минимум), так еще и порождается целый пласт новых проблем для DevOps - мониторить и деплоить монолитное приложение куда проще, чем следить за здоровьем тысяч микросервисов. а какие ожидают прелести трассировки микросервисов (а поди собери трейс лог по десяткам нод в реалтайме) - это вообще неописуемо.мой опыт показывает, что с теоретиками спорить - это долго и бессмысленно:) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.04.2017, 01:31
|
|||
|---|---|---|---|
Карта модулей приложения |
|||
|
#18+
dbpatchRMagistr2015Как правильно составлять карту модулей приложения? Есть большое запутанное приложение, в котором много различных модулей, и они постоянно друг друга вызывают и связи эти по первой можно вообще запутаться в этих макаронных вызовах, хочется понять спросить узнать, есть ли какие-нибудь методики описания структуры связей модулей приложения? как-то отслеживать вложенность вызовов, документировать этот процесс в наиболее понятную форму? Придать этому многообразию структурированный вид? Кто сталкивался и чкакие подходы использвал в этом случае? и какой смысл в этом описании, если не секрет? ну составишь ты деревья всякие и графы, да еще и с картинками миллионов стрелочек туда-сюда, что потом с этим предполагается делать? положить в архив и забыть? проблема/задача то какая стоит, на самом деле? "задокументировать все" - это не задача, это ИБД полагаю поддерживать функционал задача стоит, надо ведь с чего-то начинать. Так составишь граф вызовов, поймешь связь между структурами данных. Все проще чем с чистого листа код читать, а где проще, там и дело быстрей идет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=16&mobile=1&tid=1340422]: |
0ms |
get settings: |
5ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
29ms |
get topic data: |
6ms |
get forum data: |
1ms |
get page messages: |
35ms |
get tp. blocked users: |
1ms |
| others: | 206ms |
| total: | 296ms |
| 0 / 0 |
