featkpr

What your product does, from one module down to one feature.

featkpr reads the code and names each feature it finds. Four screens show the result, each one closer in: a module, the board of every feature, one feature and the lines that justify its name, and what the code has that nobody has asked about yet.

Screens of featkpr's app run on sample data, so the numbers inside them are examples, not BookStack's. A screen marked "recorded from BookStack" replays featkpr's own records of BookStack's run of 26 Sep.

312 features in 13 modules, named from 343 routes read in the code.

One module, every route in it #

The Map opens on every module at once (the home page shows it). Open one module and its routes line up: the features featkpr has named, the ones known only from the code, and the routes no feature names yet, grouped by the path they share.

Map/map/Exportssample data

  1. Every module as a tab with its feature count. Exports is open; Entities carries three features on the open pull request's path.
  2. Features known only from the code: named, with no scenario yet.
  3. Routes no feature names yet, grouped by the path they share. Each chip is one format; its number is the scenarios behind it.

Every feature, placed by how far it is proven #

The Features board puts each feature in the column its evidence has reached, from known only in the code to proven by a run. A feature moves right as tests are written and run. Filters live in the address, so a filtered board can be shared.

Features/featuressample data

  1. How far each feature is proven, left to right.
  2. Amber outline: features the open pull request changed. They need a person now.
  3. Flows drafted to this feature, waiting for review.

One feature, and why featkpr believes it exists #

A feature is never a guess: its name rests on lines of the product's own source, each cited with its file and line. The Feature screen opens on its verdict, then shows its route, its screen, its scenarios and the flows that end there.

Feature/f/…sample data

  1. The verdict first: scenarios waiting on a person, new with no test yet, covered.
  2. Its words: the route, the permission and the release note it rests on, each with its file and line.
  3. The route's real screen, as the crawl captured it.
  4. Its scenarios by what the route does, and the test files that cover them.
  5. The drafted flow that ends here.

What the code has that nobody has asked about #

Everything the code reader found is counted once: on the map, asked on a card, set aside, or still waiting for a look. The sheet puts modules against kinds of thing, so the gaps show as numbers, not as a feeling.

Discovery/discoverysample data

  1. One tally: found = on the map + asked + set aside + still waiting.
  2. A column per kind of thing the code holds.
  3. A cell: still waiting, of all found in that module and kind. It opens them with their files.

On BookStack, what featkpr missed is published step by step, with the reason for each miss. What featkpr missed on BookStack

The map is read at one commit, and it follows each app's release flow: The map follows BookStack's development branch, never a pull request's head; names carried across the move for less than a cent, shipped 28 Sep (part of "How your app ships, drawn and approved").

See BookStack's map on a call #

A live walkthrough of these screens on BookStack, and what featkpr would need to read your product's code.

Ask for a private demo

Open original

↑ ↓ to move, Enter to open, Esc to close