Assessment
Get the engine’s perspective on your code.
An assessment is a read-only engagement with a fixed scope. The CodeLaser engine reads the project in full — every type, every reference, every call chain — and reports what it finds, including what would move if you changed it. You get a written report and a debrief where your engineers can push back on any finding.
That is a view you can plan from: which work is worth doing, how much has to change for each, and what to do first.
How it looks at your code
We simulate improvements and measure where the code resists.
The standard measurements come with it
Sizes and complexity at every level, the distributions behind the totals, the worst offenders ranked, duplication and coupling. Roughly the picture a maintainability report gives you, so what follows has something to sit against.
Where a finding has a remedy the engine can carry out, it comes with that operation named. The size of the job comes with it: how far the change would reach, and what it would take to move the number.
What this engine adds
CodeLaser is built to carry out large structural change. An assessment is that same machinery with nothing written: it resolves the code in full — every type, every reference, every call chain — then works out what a given change would do to it.
So it can say where the code would give and where it would resist, which is the part a reader of the source cannot reach.
Five families
Typical questions the engine takes on.
Which questions get asked depends on what you need to decide, so the set is agreed per engagement.
Every route from the entry points inward to the code that runs: how many there are, how deep they go, and which exist only through reflection or a framework. What nothing reaches at all falls out of the same computation.
How the code clusters by who calls whom, set against how it is filed into packages and declared in the build. The gap between the two is where the structure has drifted from what anyone intended.
Parameters and fields typed more narrowly than the code requires, interfaces that offer more than any caller uses, third-party types that have spread further into the codebase than the work they do. Where the fit can be tightened, the operation that does it comes with the finding.
What stands between a proposed boundary and a real one: the references going the wrong way, the access the code quietly relies on, the build arrangements, the links that only exist while it runs.
What a change implies once it is worked through — how much of the codebase it would touch, how much could be carried out as the code stands, and where the engine would decline and why.
The engagement
How an assessment runs.
We talk through what is blocked, or what you are trying to decide. That sets which questions the run should answer.
The project is mounted read-only. We agree where it runs, which repositories are in scope, and which entry points count as real.
The standard measures run first. The questions from the first conversation are written and run after that.
We go through the findings with your engineers. Each one shows what it was derived from, so anything doubtful can be checked against the code.
A written report: the measurements, the findings and the evidence behind each one, and the plan they support.