You want to code your solution using the framework.
To actually use a framework you have to code. Therefore, understanding the source code is mandatory. But a framework is not a common piece of code: it has no clear entry point and there isn’t a “main” method from where to start understanding the flow of control. Its “hot-spots” are scattered across the code and the way to use them may not be straightforward.
What to look for to understand the source-code and plug-in your solution?
Hollywood principle. Your code will have to be inserted at a specific location that the framework will eventually call and execute. It might not be straightforward how and where that calling will take place.
Language familiarity. If you are not familiarized with the programming language in which the framework is built, you’re going to take more time to understand the code.
Task-orientation. To be cost-effective, learners tend to focus on the task at hand, and to find the quickest way to solve their immediate problem.
Code Annotations. Code annotations and inline documentation can give helpful insight on a certain code fragment was implemented or served a purpose.
Documentation. Usually, the framework comes with examples on how to quick start or how to quickly address initial problems. These can be extremely helpful as they show how to begin and force you to try to understand how the system works.
Browse the documentation for examples on how to address the task at hand. Identify the code main entry points for your specific task.
Usually, the framework comes with a COOKBOOK AND RECIPES on how to solve common problems the framework addresses. These show you how to begin coding and enable you to understand how the overall system works.
If no documentation is present, try to look for beacons and idioms that might hint to the entry point(s) of the framework (Control classes and “main” methods) and track down the flow of control. Idioms are coding patterns that are used to solve recurrent problems (You use a loop to iterate over an array, etc.). Beacons are fragments of code that may resemble algorithm techniques or coding strategies to known problems. Classifying and chunking code into these concepts might prove useful to increase code granularity search.
Identify your insertion points as you go along and preserve all the information gathered, by adopting a KNOWLEDGE KEEPING strategy.
Missing the whole picture. At such a low-level, the learner has local expertise but might overlook more global side-effects of code insertion or modification. A broader notion of what is happening might be necessary, so you might need to UNDERSTAND THE DESIGN INTERNALS to gain further awareness.
Prior to performing a software modification task, developers must inevitably investigate the code of the target system in order to find and understand the code related to the change. With frameworks, the theory is the same. If we assume that the way a developer investigates a program influences the success of the modification task, then ensuring that developers in charge of modifying software systems investigate code of the system effectively can yield important benefits such as decreasing the cost of performing software changes and increasing the quality of the change.
Developers should follow a general plan when investigating a program, should perform focused searches in the context of this plan, and should keep some form of record of their findings.
Documentation here is crucial. Not only should there be some sort of guide for browsing the code, but also examples on how to address the most common problems. Going through these examples would be a valuable assisted first “dive” into the framework code and would help emerge the control-flow mechanism of the framework and the way it is supposed to be used.
In [SMD06], Sillito et al. performed a study where they observe developers trying to understand a system in order to perform a change task. They harvested and identified 44 different kinds of questions developer ask during that process and divided them into four categories based on the characteristics of the source code graph capturing the information needed for answering a given question: those aimed at finding the initial focus points, those aimed at building on those points, those aimed at understanding the sub-graph, and those over such sub-graphs.
In [RCM04], Robillard et al. conducted another study where observed successful and unsuccessful developers while performing a software evolution task and came up with a theory of program investigation effectiveness in the form of a series of observations and associated hypotheses. Overall, they found that successful developers exhibited a highly methodical approach to program investigation, where they identified the high-level structures and planned the changes to be made, without forcefully spending more time than a more opportunistic approach.