Systematic and scientific approach to analyse source code for understanding

3    22 Jul 2015 14:46 by u/munoi

Hello communtiy,

I have to extend some unfamiliar source code and also write some paper about it. To do so I want to document, how I dive into the unfamiliar code.

Is there some step by step guide somewhere, that describes, how I should approach software to get to know it? Like a top down approach: - Find all its dependencies (third-party-libraries) - Check the folders/packages/modules out and - See what design patterns were used - Go to the entry-point and check flow ...

I tried to google something like "code analysis" but always get some tools for metrics which I am not interested in. I want to find a method to get to know what some kind of software (source code) does.

2 comments

3 u/pm_me_or 22 Jul 2015 16:11

Strangely, I read "unfamiliar source code" as "hostile source code". Because it often is.

You'll sometimes even wonder if the coder has volontarily overcomplicated everything (e.g. sliced a simple flow in multiple callback-ridden subprocesses) just to screw with you.

But more seriously, I do not know a simple method to read hostile code. I work in a SaaS-architectured IS, so my experience may not be applicable to your current problem, but what I do is :

  1. Look for external API implementations and isolate them. Those are the limbs of your code. They are here to augment the data processed by reading a database / a file, calling a service / an engine... Sometimes the data they return may alter the flow, but the implementation of these interfaces are really dumb : map from one type to another, call a low-level API... You don't need to dive in them early (except if the code you have to extend is there, but in this case this should be piece of cake).
  2. Look for business classes. Those are the trunk of your code. They control the workflow, make the decisions and generate functional errors. If business classes are implementation of business interfaces, that may imply some sort of business-level framework, which may simplify your work.
  3. If there are no interfaces, you may be screwed : you are facing something written like a script, monolithic and virtually non evolutive. Sorry.
  4. Look for the authors. Who knows, they're maybe still around, and perhaps willing to help
  5. In general, if you want to be more efficient in this task in the future, keep yourself updated about design patterns and frameworks. There is nothing scarier than having to decypher a pattern you never heard about (looking at you, RoR "artisans")...

All in all, welcome to hell.

0 u/ITW 24 Jul 2015 00:42

I'd say this is a good answer. It really depends on what kind of project it is though.