Research in program comprehension has evolved considerably over the past decades. However, only little is known about how developers practice program comprehension in their daily work. This article reports on qualitative and quantitative research to comprehend the strategies, tools, and knowledge used for program comprehension. We observed 28 professional developers, focusing on their comprehension behavior, strategies followed, and tools used. In an online survey with 1,477 respondents, we analyzed the importance of certain types of knowledge for comprehension and where developers typically access and share this knowledge.
We found that developers follow pragmatic comprehension strategies depending on context. They try to avoid comprehension whenever possible and often put themselves in the role of users by inspecting graphical interfaces. Participants confirmed that standards, experience, and personal communication facilitate comprehension. The team size, its distribution, and open-source experience influence their knowledge sharing and access behavior. While face-to-face communication is preferred for accessing knowledge, knowledge is frequently shared in informal comments.
Our results reveal a gap between research and practice, as we did not observe any use of comprehension tools and developers seem to be unaware of them. Overall, our findings call for reconsidering the research agendas towards context-aware tool support.
Maalej, Tiarks, Roehm and Koschke conducted an observational study and a survey to understand how programmers read code, generating twenty-eight separate findings about code comprehension as it is practiced in industry. Two of the findings on tool usage really jumped out at me:
Programmers aren't using sophisticated program comprehension tools. In fact, they generally aren't even aware of the program comprehension functionality that exists in the IDEs they use every day.
This result will likely come as little surprise to most programmers, but it's a reality that the software engineering research community needs to internalize: we aren't using the comprehension tools you are developing. If you don't understand why existing comprehension tools fail to be adopted, I doubt the next ones will meet with much success.
There's a lot more in this paper, including findings about the role that documentation plays (or, rather, doesn't play) in comprehension, the absence of documented rationale in most code bases, and the role of communication channels on comprehension.Comments powered by Disqus