Анализ функциональной зависимости - PullRequest
1 голос
/ 19 ноября 2009

Разработчики, которые использовали eclipse, не могут пропустить комбо Cntrl + Shift + G - самый простой способ найти все ссылки на определенный член / метод / класс в вашем рабочем пространстве. Рассмотрим сценарий, когда вы новичок, поддерживающий веб-приложение, написанное на Java. Теперь вы собираетесь изменить сигнатуру метода, и вы делаете Cntl + Shift + G, чтобы найти все ссылки на указанный метод (да, надеясь, что вы не выполняете внедрение / отражение зависимостей и т. Д.). Однако, новый парень, хотел бы не испортить какую-либо функциональность в приложении. Как гарантировать, что функциональные зависимости не будут затронуты?

Полагаю, вопрос немного неясен ... перефразирую ... скажем, вы меняете что-то функциональное (цикл if в бизнес-правиле или whateva) - это определенно ИЗМЕНИТ что-то другое в контексте приложения. ... и в этот момент вы хотели бы, чтобы в затмении был какой-то (плагин?), который бы сказал вам - "эй, нуб ... не меняйте это - это повлияет на это ..." - Теперь, если бы вы создать что-то, что делает это для затмения (плагин?) - с чего бы вы начали? (пометка частей кода scr и введение дерева зависимостей? и т. д.?)

Ответы [ 3 ]

1 голос
/ 19 ноября 2009

Возможно, я не понял вашего вопроса, но думаю, у меня может быть ответ. Взгляните на nWire для Java (или PHP ). Это плагин для исследования кода. Сосредоточившись на фрагменте кода, разработчик может быстро определить, где вызывается метод, где используется класс и т. Д. Это облегчает понимание того, что вы собираетесь изменить.

Я разработчик этого плагина. Если это не совсем то, что вы ищете, дайте мне знать, я буду рад лучше понять, что вы ищете.

1 голос
/ 19 ноября 2009

Кроме того: ALT + SHIFT + C - это способ изменить сигнатуру метода. ALT + SHIFT + G «только» находит ссылки, что, конечно, полезно.

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

Книга Роберта Мартина «Эффективная работа с устаревшим кодом» прекрасно объясняет это: весь код, который не охватывается тестами, является устаревшим кодом. Вы можете сделать вывод, что прежде чем применять какие-либо функциональные изменения, необходимо обеспечить достаточный охват тестированием.

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

0 голосов
/ 19 ноября 2009

А как насчет JDepend ?

...