phpgraph

Like get_node, in one direction. "in": what uses this node (callers, implementations, subclasses, code that instantiates or references it), to judge the impact of a change. "out": what this node depends on.

Everything about one class, interface, trait, enum, method or function: kind, file and line, and every relation in and out. Each relation has a confidence: EXTRACTED (read in the code), INFERRED (resolved from declared types, across files and through vendor/ signatures) or AMBIGUOUS (guessed: the only method of the project with that name). When several nodes match the name, the others are listed.

The most connected classes and methods: the hubs most code depends on, often central domain objects, shared services or base classes. Changing them has the widest impact.

Call this before changing a class or a method, instead of searching for its usages with grep. What may break when it changes: every class that depends on it, directly or through others (callers, subclasses, implementations, code that instantiates or references it, senders and handlers of a message), nearest first, each with the relation that reaches it and the weakest confidence on the way, then its methods reaching the change with the source lines of their calls (3 per class, all with limit 0). Follows methods, not whole classes: a class is reached only through the methods that use the change. Also reaches the callers of the interface or parent method a method implements (INFERRED), and, in a separate list, the code possibly affected through the state the method writes (direct callers of methods reading the same properties, such as all() or hasErrors() for add(), not followed further). Lists the tests to run apart, found through test helpers (fakers) without the depth limit. Stops at a service receiving the change among others (a tagged collection) and at inherited code shared with other subclasses, which are listed but not followed. Lists the routes reaching the change without the depth limit, each with its chain down to the change, scoped by the injected lists on the way. Lists are cut at 40 entries: pass limit 0 for complete lists, or section to get a single one.

Call this first, instead of query_graph, grep or reading files, whenever you are asked to explain, describe or document a feature or how something works ("explain the notification validation system", "how does stock reservation work"), before reading any code. Returns its structural outline, enough to read only the few files with non-obvious logic. From the classes the topic names, the cluster they form, by namespace and layer, each with its kind, the first sentence of its docblock, its public signatures, constants and enum cases; the interfaces and base classes around it with their number of implementations by folder (0 stated) and the tags injecting them; the flow from the routes into it, the closures it runs and the calls inside it; behaviour read in the bodies (guarded throws, early returns, branches on constants, loop caps, state compared before and after); the container wiring with service ids; its users (tests counted by module), the classes no test touches and those nothing uses. A topic naming a method (OrderService::place) outlines what it runs: the methods it calls, 3 calls deep, each class with those methods only, the hubs it calls counted, its behaviour nearest first.

Start here on an unfamiliar PHP project. Returns: the Composer stack per application (framework, ORM, message bus, test and analysis tools, with versions); the namespace tree of application code, each branch annotated with the layer-like segments found below it (Domain, Application, Infrastructure, Adapter, Model, Controller...) so you can tell bounded contexts and layers; counts of class name suffixes (Handler, Repository, Controller...); and the gaps of the graph: share of method calls whose receiver type is unknown, the method names most often unresolved, missing vendor/, parse failures, duplicate class names, and what is not modelled at all; the dependencies breaking the layer rules (domain must not depend on infrastructure...) and between bounded contexts; the services of a multi-service repository; HTTP routes (entry points): each route with method, path, controller and routing file when there are up to 30, else counts by path prefix; routes whose controller class exists nowhere; HTTP calls; the API schemas (OpenAPI documents, protobuf services) with what implements them, what is documented and not implemented, and the routes no document describes; messages, their handlers and what is left unlinked. Test code is counted apart.

Find the code about a topic when you do not know the class names. To explain how a feature works ("explain the notification validation system"), call outline instead: it answers in one call what query_graph and several get_node calls would. Matches the words of the question against the words of class, method and function names (validated finds Validator, prices finds PriceCalculator; rare words weigh more than common ones; not semantic search: use words likely to appear in names, such as "stock availability" or "invoice payment"), then returns up to 6 best matches, the other classes of their namespace (the module asked about) and the neighbours that are about the question too, as relations (calls, handled_by, receives...) with confidence. Test code only when the question mentions tests. A question about routes (the words routes, endpoints, HTTP or URL, or a path such as /orders/{id}, with or without a method such as GET) returns the matching route nodes and their controllers; its other words narrow them by path or routing file: "mooc courses routes", "GET /courses".

How two pieces of code are connected: the shortest chain of relations from one node to the other. Follows dependencies first (calls and references in their direction, from an interface to its implementations, never through files or classes outside the project); otherwise ignores the direction. The answer says which mode found the path.