Let your code know… your code

Has this ever happened to you ?

… you work on a legacy project, and there is this method called `getAccount` which sounds simple.
But this method is a compound one.
1°) It actually calls a database A to fetch a user Id.
2°) Then completes the data with a B Web service based on LDAP
3°) Then completes it with some extra data based on the account preferences from a service C
4°) It updates the database with the found data (yes, « getAccount » writes something… in a legacy project, you will certainly see that)
5°) It returns all the data.

What if you call getAccount from another point of view ? If you are the caller of the method, you could even do this :

if (getAccount (user) != null) {
String userName = getAccount (user).getName ();
}

Ugh… Did you realize that these 4 lines will call different external services 3 * 2 = 6 times… It has awful performance, and can be harmful (= with side effects) if the method getAccount is not idempotent (which is likely to happen in a legacy project)

What you need is not (really) refactoring. The technical debt is too tough to be attacked right now. What you need IS knowledge about the code. How can you know what is happening in the code ? Think painless, think about code to understand code …

I have created what I call a DiveDeepAnalyzer. The aim of this is to understand which sensitive methods are called directly or indirectly in each method.

https://gist.github.com/libetl/00bc6079b3dd91af55bb6cf8229e942a

Write down the list of sensitive calls (webservices, LDAP, databases, cache, drivers, hardware), and the algorithm will annotate each and every method that is likely to use these calls.

How to ?
1°) Copy this class in your project,
2°) change the params in the main method (you will need to exclude the DiveDeepAnalyzer class itself from the scan)
3°) run the class.

This analyzer uses spoon, an OSS made by a research lab in France (inria). You can find more about spoon at this address : http://spoon.gforge.inria.fr/

Smart HATEOAS APIs

Hello.

It is always useful to navigate in an API as easily as in an HTML file.
Who have ever dreamt of a clever software code able to browse all the relevant data just by browsing an API document ?

Here is how :
– build an API result with links. Your links must be accessed like you would do in a css file (<link rel= »stylesheet » href= »path/to/the/file>)
– trust your MVC framework to remind you which links are associated to your current resource (find in the Request Mapping the relevant links)
– give the user a root resource where you can find a « menu » of your APIs. A simple test can convince you that your APIs links work : use Postman, and try to reach a single resource from the root resource.

You can find an example about how it works with Spring MVC 4.2 . Give it a try to my simple web app https://github.com/libetl/RESTAndSpringBankAccountWebApp. Fork this repo, scaffold it to build your own APIs, make yourself at home.