Teaching Code Review Management using Branch Based Workflows Stephan Krusche Mjellma Berisha Bernd Bruegge Technische Universität Technische Universität Technische Universität München München München Munich, Germany Munich, Germany Munich, Germany [email protected] [email protected] [email protected] ABSTRACT 1. INTRODUCTION Developing software with high code quality in a university The organization of multi-customer capstone courses with environment is a challenge for instructors of software engi- real industry customers is challenging for instructors. They neering capstone courses. Teaching students how to achieve often choose toy projects with fabricated problem statements quality and how to conduct code reviews in projects is often to minimize the e↵ort. However, we claim such setups do not neglected, although it helps to improve maintainability. motivate the students and result in low learning experience. In this paper we describe an informal review technique: We consider large project courses with multiple customers branch based code reviews. Developers realize requirements the most promising way to teach industry relevant software in feature branches. Before they integrate source code into engineering practices, in particular agile methodologies and the main codebase, the code is reviewed asynchronously over continuous delivery [7]. We conduct such courses since 2008 the Internet in a quality gate to identify defects, design flaws with up to 100 students, ranging from sophomores to master and code flaws. Traditionally reviewing has been a task of students in their final semesters with some years of develop- the instructor. In our course, we delegate it to students of ment experience. Students develop mobile applications for the development team. Our hypothesis is that students learn industry clients, e.g. BMW, Siemens and T-Systems, during and adapt best practices from each other, improving code one semester [7]. This allows students to experience and quality and their coding skills. apply agile methodologies with changing requirements and We applied this technique in a workflow during a project- real deadlines, which in fact leads to real team experience. based capstone course over the period of three semesters. 300 Students face typical communication problems and improve students conducted 2939 code reviews with 4665 comments their non technical skills as well. in 33 projects with industry customers. We evaluated the In 2012, we incorporated continuous delivery into the workflow in a qualitative study using interviews. Our key capstone course [25]. Its introduction increased the number findings are that students do not longer see reviews as a of releases significantly [26] and led to many benefits, also bureaucratic burden and improve their skills through the described by others [9]: accelerated time of releases, improved comments of experienced team members. They are convinced product quality and customer satisfaction and reduced risk that reviewing code leads to higher code quality and 89 % of release failure. However it also posed new challenges. want to use the workflow again in future projects. The focus on concurrent feature development complicates collaboration on source code. The client’s expectation for CCS Concepts multiple releases and the inclusion of feedback to improve the product increments increased the time pressure during Software and its engineering Software configura- • ! development. This pressure resulted in less attention to tion management and version control systems; Soft- object design and source code quality, which ought to be ware version control; Software development process important when teaching software engineering: Students management; Agile software development; Software evolu- should learn to write maintainable code with high quality. tion; Programming teams; Before we introduced continuous delivery, we held code reviews with each team two weeks before the course end. Keywords The course instructors reviewed the code since they were Peer Learning, Capstone Course, Code Quality, Branching experienced with the development environment and program- Model, Pull Request, Merge Request, Pair Programming, ming language. Reviewing the codebase and searching for Distributed Version Control common design flaws and unfulfilled coding guidelines con- sumed a lot of time. In retrospectives with students, we asked for feedback about the code reviews. They stated that late code reviews led to almost no learning experience. As the end results of the course projects further improved, more customers want to build upon the codebase of the projects and extend the applications. They hire students after the course to finalize and release the software. In such cases, further developing the software was challenging and led to To appear in the 38th International Conference on Software Engineering - higher maintenance costs due to low code quality. To address ICSE, May 2016, Austin, TX, USA. this problem, we introduced a new approach for source code for improving quality, as it helps to remove both code smells collaboration and reviews with the following goals: and problematic solutions from antipatterns. 1. Early stage reviews: The code is reviewed from the beginning of the project to adapt the fail early principle and to learn from mistakes as soon as possible. 2.1 Reviews 2. Continuous reviews: Reviews are conducted regu- The Oxford Dictionary defines review as ”formal assess- larly to guarantee high quality in the main codebase. ment of something with the intention of instituting change if 3. Review responsibility: Students conduct the review necessary” [35]. This definition also applies to software engi- themselves to improve their learning experience and to neering, where reviews are an important quality assurance reduce the e↵ort for the instructors. method that check for defects, deviations from development 4. High quality releases: Only reviewed code is inte- standards, and other problems in products [10, 31]. Weinberg grated to the main codebase and is present in product states how early software developers, even the likes of von increments. Neumann and Babbage, understood that correctness was 5. Efficient reviews: Each change is only reviewed once too difficult a task to master by oneself, and sought their before it is integrated. colleagues’ feedback [38]. These initial reviews were informal 6. Fast development process: Reviews do not slow in nature, as there was no defined or agreed upon process. down the development process and the ability to release In fact, well defined reviews eluded research interests well new features quickly. into the 1970s. The explanation Weinberg [38] o↵ers is that ”the need for reviewing was so obvious to the best program- In this paper we present a branch based code review work- mers that they rarely mentioned it in print, while the worst flow that fulfills these goals. We define the term quality, programmers believed they were so good that their work did present a taxonomy of review techniques and describe the not need reviewing”. capstone course in which we applied the workflow, in Section An early approach to reviews found in literature is a for- 2. In Section 3, we give an overview of the workflow and mal, well defined and heavyweight process called inspection describe benefits and challenges, while Section 4 provides [30]. Software inspections were developed under the direc- details for each activity of the workflow. We describe the tion of Michael Fagan in an e↵ort to improve quality and approach how we introduced the workflow in a capstone increase productivity. Fagan’s inspection process consists of course with a project-based organization using introduction six activities: planning, overview, preparation, inspection, courses and interactive tutorials in Section 5. We evaluated rework and follow-up. The first three lay out the foundation: our approach via interviews qualitatively and measured the the author determines what materials are to be inspected usage of the workflow quantitatively. We present observa- and ensures that they meet predefined entry criteria. Then, tions and statistics in Section 6, including key findings and a meeting is scheduled, the participants are chosen and each limitations. Section 7 describes similarities and di↵erences is assigned one of the four inspection roles: designer, coder, to related work, while Section 8 concludes the paper. tester and moderator. This set of roles ensures that the material is reviewed from various perspectives to identify 2. BACKGROUND di↵erent bugs. [17, 18] In this section we define quality, explain our taxonomy Walkthroughs are lower in formality than inspections [30]. for review techniques shown in Figure 1 and describe our There are di↵erent approaches to define the process ranging capstone course briefly. The topic of product quality has from formal ones such as Yourdon’s structured walkthrough been investigated from various perspectives. Renown quality [40] or the IEEE Standard 1028 [24], to informal ones that experts either take the stance that quality means ”confor- focus mainly on the walkthrough meeting [34, 3]. They all mance to requirements” [13] or define it relative to the user’s have in common the fact that the author walks an audience of needs [15] and their ”stated or unstated, conscious or merely reviewers step-by-step through the material, while explaining sensed” [19] requirements. Another component of quality the purpose and reasoning behind it. There is consensus includes patterns, which describe generic solutions