How developers can already craft analyses

Humane assessment implies that developers have to craft their own analysis tools. One argument that might pop into people's mind is that the proposition is too expensive given that building software analysis tools is too difficult and too foreign to regular developers. Allow me to dispel this myth.

Some children are afraid of flies. Their fear has nothing to do with their ability, especially given that at the same time they are happily running after butterflies. It has only to do with the projection of their abilities.

I argue that developers' reluctancy of approaching code analysis has a similar nature.

As an example, let's take a closer look at how you can build a tool that can query references to a class. As an you typically get the code in a textual form. You parse and import the code to obtain the abstract syntax tree. Afterwards, you traverse the abstract syntax tree and transform it into a graph model that is more suitable for complex querying. And finally, you build the query by traversing this model.

Model and query will likely sound rather familiar to developers given that they manipulate them all day long. But, parser and abstract syntax trees can sound intimidating. There is nothing to be afraid of. There is no magic. And you are already working with them under different circumstances.

Let's take a look at a rather common development scenario: build a query over a model stored in XML. To do this, you will import the XML using a dedicated XML parser and build a DOM-like tree of objects out of it (notice the parser and the tree). Afterwards, you traverse the tree and transform it into a graph model that is more suitable for complex querying. And finally, you build the query by traversing this model.

The two scenarios truly imply the same things conceptually. The differences mostly come from the domain. Once you familiarize yourself with the domain of code analysis, you should be able to build on your existing skills.

Learning this new domain should not be a particularly hard proposition either. First, as a developer, you are likely learning a new domain every time you switch projects. Second, the model of a software language is not more complicated than the models you are already used to.

For example, FAMIX is the language independent meta-model used in Moose. It models concepts like Class, Method or Invocation (between one or more methods). This model has something like 55 classes. Even when considering its entirety, which is rarely needed, it still is smaller than the average amount of model entities behind the enterprise systems I played with.

Some children are afraid of flies, but they get over it once you take them by the hand and show them how the flies are not that much different from butterflies. What does it for you to get over your reluctancy?

Let me know if you need any help.