Cognitive-Support Code Review Tools

Total Page:16

File Type:pdf, Size:1020Kb

Cognitive-Support Code Review Tools Cognitive-Support Code Review Tools Improved Efficiency of Change-Based Code Review by Guiding and Assisting Reviewers Von der Fakult¨atf¨ur Elektrotechnik und Informatik der Gottfried Wilhelm Leibniz Universit¨atHannover zur Erlangung des akademischen Grades Doktor-Ingenieur (abgek¨urzt:Dr.-Ing.) genehmigte Dissertation von Herrn M. Eng. Tobias Baum geboren am 28.04.1985 in Hannover, Deutschland 2019 Betreuer: Prof. Dr. Kurt Schneider 1. Referent: Prof. Dr. Alberto Bacchelli 2. Referent: Prof. Dr. S¨oren Auer Vorsitzende der Pr¨ufungskommission: Prof. Dr. Eirini Ntoutsi Tag der Promotion: 25. Oktober 2019 c 2019 Tobias Baum. Some figures contain icons made by Freepik from www.flaticon.com Parts of this thesis share material with published articles (see pg. 273f) and are c the respective publishers. To my family . Abstract Code reviews, i.e., systematic manual checks of program source code by other developers, have been an integral part of the quality assurance canon in software engineering since their for- malization by Michael Fagan in the 1970s. Computer-aided tools supporting the review process have been known for decades and are now widely used in software development practice. De- spite this long history and widespread use, current tools hardly go beyond simple automation of routine tasks. The core objective of this thesis is to systematically develop options for improved tool support for code reviews and to evaluate them in the interplay of research and practice. The starting point of the considerations is a comprehensive analysis of the state of research and practice. Interview and survey data collected in this thesis show that review processes in practice are now largely change-based, i.e., based on checking the changes resulting from the iterative-incremental evolution of software. This is true not only for open source projects and large technology companies, as shown in previous research, but across the industry. Despite the common change-based core process, there are various differences in the details of the review processes. The thesis shows possible factors influencing these differences. Important factors seem to be the process variants supported and promoted by the used review tool. In contrast, the used tool has little influence on the fundamental decision to use regular code reviews. Instead, the interviews and survey data suggest that the decision to use code reviews depends more on cultural factors. Overall, the analysis of the state of research and practice shows that there is a potential for developing better code review tools, and this potential is associated with the opportunity to increase efficiency in software development. The present thesis argues that the most promising approach for better review support is reducing the reviewer's cognitive load when reviewing large code changes. Results of a controlled experiment support this reasoning. The thesis explores various possibilities for cognitive support, two of these in detail: Guiding the reviewer by identifying and presenting a good order of reading the code changes being reviewed, and assisting the reviewer through automatic determination of change parts that are irrelevant for review. In both cases, empirical data is used to both generate and test hypotheses. In order to demonstrate the practical suitability of the techniques, they are also used in a partner company in regular development practice. For this evaluation of the cognitive support techniques in practice, a review tool which is suitable for use in the partner company and as a platform for review research is needed. As such a tool was not available, the code review tool \CoRT" has been developed. Here, too, a combination of an analysis of the state of research, support of design decisions through scientific studies and evaluation in practical use was employed. Overall, the results of this thesis can be roughly divided into three blocks: Researchers and practitioners working on improving review tools receive an empirically and theoretically sound catalog of requirements for cognitive-support review tools. It is available explicitly in the form of essential requirements and possible forms of realization, and additionally implicitly in the form i of the tool \CoRT". The second block consists of contributions to the fundamentals of review research, ranging from the comprehensive analysis of review processes in practice to the analysis of the impact of cognitive abilities (specifically, working memory capacity) on review perfor- mance. As the third block, innovative methodological approaches have been developed within this thesis, e.g., the use of process simulation for the development of heuristics for development teams and new approaches in repository and data mining. Keywords: Software Engineering, Code Reviews, Cognitive Load, Code Reading Techniques, Software Development Tools ii Zusammenfassung Code Reviews, d. h. manuelle Pr¨ufungenvon Programmquellcode durch andere Entwick- ler, sind seit ihrer Formalisierung durch Michael Fagan in den 1970er Jahren fester Bestandteil des Qualit¨atssicherungs-Kanons im Software Engineering. Auch computerbasierte Werkzeuge zur Unterst¨utzungdes Review-Prozesses sind seit Jahrzehnten bekannt und inzwischen in der Softwareenwicklungspraxis weit verbreitet. Trotz dieser langen Historie und weiten Verbrei- tung gehen auch aktuelle Werkzeuge kaum ¨uber einfache Automatisierung anfallender Rou- tineaufgaben hinaus. Das Kernziel der vorliegenden Arbeit ist, systematisch M¨oglichkeiten zur verbesserten Werkzeugunterst¨utzungf¨urCode Reviews zu erarbeiten und im Zusammenspiel von Wissenschaft und Praxis zu evaluieren. Ausgangspunkt der Uberlegungen¨ ist eine umfassende Analyse des Standes der Forschung und der Praxis. Im Rahmen dieser Arbeit erhobene Interview- und Umfragedaten zeigen, dass Review-Prozesse in der Praxis inzwischen zu einem großen Teil ¨anderungsbasiert sind, d.h. auf dem Pr¨ufenvon Anderungen,¨ die sich aus der iterativ-inkrementellen Weiterentwicklung von Software ergeben, basieren. Dies gilt nicht nur, wie in der vorherigen Forschung gezeigt wurde, f¨urOpen-Source-Projekte und große Technologiefirmen, sondern in der gesamten Branche. Dem gemeinsamen ¨anderungsbasiertenKernprozess stehen jedoch diverse Unterschiede in der De- tailumsetzung der Reviewprozesse gegen¨uber. Die Arbeit zeigt m¨ogliche Einflussfaktoren f¨ur diese Unterschiede auf. Wichtige Faktoren scheinen die vom genutzen Review-Werkzeug un- terst¨utztenund bevorzugten Prozessvarianten zu sein. Diesem großen Einfluss der verwende- ten Werkzeuge auf die Auspr¨agungdes Review-Prozesses steht ein geringer Einfluss auf die grunds¨atzliche Entscheidung f¨urdie Nutzung regelm¨aßigerCode Reviews entgegen. Die Inter- views und Umfragedaten legen stattdessen nahe, dass die Entscheidung f¨urdie Nutzung von Code Reviews eher von kulturellen Faktoren abh¨angigist. Aus der Analyse des Stands der Forschung und der Praxis ergibt sich insgesamt, dass es ein Potential zur Entwicklung besserer Code-Review-Werkzeuge gibt und mit diesem Potential die Chance zur Effizienzsteigerung in der Softwareentwicklung einhergeht. In der vorliegenden Arbeit wird dargelegt, dass der vielversprechendste Ansatz f¨urbessere Review-Unterst¨utzungin der kognitiven Entlastung des Reviewers beim Pr¨ufengroßer Code-Anderungen¨ besteht. Diese Argumentation kann durch Ergebnisse eines kontrollierten Experiments gest¨utztwerden. Die Ar- beit untersucht verschiedene M¨oglichkeiten zur kognitiven Unterst¨utzung,zwei davon im Detail: Das Leiten des Reviewers durch Ermitteln und Pr¨asentieren einer guten Abfolge des Lesens der zu pr¨ufendenCode-Anderungen¨ sowie das Entlasten des Reviewers durch automatisches Erken- nen f¨urdas Review irrelevanter Teile der Anderungen.¨ In beiden F¨allenwerden empirische Daten sowohl zur Generierung als auch zur Pr¨ufungvon Hypothesen verwendet. Um die Praxis- tauglichkeit der Unterst¨utzungsvarianten zu zeigen, werden diese zus¨atzlich in einem Partnerun- ternehmen in der regul¨arenEntwicklungspraxis eingesetzt. F¨urdiese Evaluation der kognitiven Unterst¨utzungsfunktionenim Praxiseinsatz wird ein Review-Werkzeug ben¨otigt,das sich f¨urden iii Einsatz im Partnerunternehmen und als Plattform f¨urReviewforschung eignet. Da ein solches Werkzeug nicht verf¨ugbarwar, wurde im Rahmen dieser Arbeit das Code-Review-Werkzeug CoRT\ entwickelt. Auch hierbei wurde wieder auf eine Kombination aus einer Analyse des " Standes der Forschung, Unterst¨utzungvon Designentscheidungen durch wissenschaftliche Stu- dien und Evaluation im Praxiseinsatz zur¨uckgegriffen. Insgesamt lassen sich die Ergebnisse dieser Arbeit grob in drei Bl¨ocke einteilen: Forscher und Praktiker, die an der Verbesserung von Review-Werkzeugen arbeiten, erhalten einen empirisch und theoretisch fundierten Katalog von Anforderungen an kognitiv-unterst¨utzendeReview- Werkzeuge. Dieser liegt einmal explizit in Form essentieller Anforderungen und m¨oglicher Reali- sierungsformen vor, und zus¨atzlich implizit in Form der im Praxiseinsatz bew¨ahrtenAuspr¨agung CoRT\. Der zweite Block besteht aus Beitr¨agenzu den Grundlagen der Reviewforschung und " erstreckt sich von der umfassenden Analyse von Review-Prozessen in der Praxis bis hin zur Analyse des Einflusses kognitiver F¨ahigkeiten (konkret der Arbeitsged¨achtniskapazit¨at)auf die Reviewleistung. Aus den erzielten Ergebnissen ergeben sich Ans¨atzef¨urweitere Forschung und die weitere Verbesserung der Softwareentwicklung durch Code Reviews. Als dritter Block wur- den im Rahmen dieser Arbeit innovative methodische
Recommended publications
  • Open Source Used in Influx1.8 Influx 1.9
    Open Source Used In Influx1.8 Influx 1.9 Cisco Systems, Inc. www.cisco.com Cisco has more than 200 offices worldwide. Addresses, phone numbers, and fax numbers are listed on the Cisco website at www.cisco.com/go/offices. Text Part Number: 78EE117C99-1178791953 Open Source Used In Influx1.8 Influx 1.9 1 This document contains licenses and notices for open source software used in this product. With respect to the free/open source software listed in this document, if you have any questions or wish to receive a copy of any source code to which you may be entitled under the applicable free/open source license(s) (such as the GNU Lesser/General Public License), please contact us at [email protected]. In your requests please include the following reference number 78EE117C99-1178791953 Contents 1.1 golang-protobuf-extensions v1.0.1 1.1.1 Available under license 1.2 prometheus-client v0.2.0 1.2.1 Available under license 1.3 gopkg.in-asn1-ber v1.0.0-20170511165959-379148ca0225 1.3.1 Available under license 1.4 influxdata-raft-boltdb v0.0.0-20210323121340-465fcd3eb4d8 1.4.1 Available under license 1.5 fwd v1.1.1 1.5.1 Available under license 1.6 jaeger-client-go v2.23.0+incompatible 1.6.1 Available under license 1.7 golang-genproto v0.0.0-20210122163508-8081c04a3579 1.7.1 Available under license 1.8 influxdata-roaring v0.4.13-0.20180809181101-fc520f41fab6 1.8.1 Available under license 1.9 influxdata-flux v0.113.0 1.9.1 Available under license 1.10 apache-arrow-go-arrow v0.0.0-20200923215132-ac86123a3f01 1.10.1 Available under
    [Show full text]
  • Buildbot Documentation Release 1.6.0
    Buildbot Documentation Release 1.6.0 Brian Warner Nov 17, 2018 Contents 1 Buildbot Tutorial 3 1.1 First Run.................................................3 1.2 First Buildbot run with Docker......................................6 1.3 A Quick Tour...............................................9 1.4 Further Reading............................................. 17 2 Buildbot Manual 23 2.1 Introduction............................................... 23 2.2 Installation................................................ 29 2.3 Concepts................................................. 41 2.4 Secret Management........................................... 50 2.5 Configuration............................................... 53 2.6 Customization.............................................. 251 2.7 Command-line Tool........................................... 278 2.8 Resources................................................. 289 2.9 Optimization............................................... 289 2.10 Plugin Infrastructure in Buildbot..................................... 289 2.11 Deployment............................................... 290 2.12 Upgrading................................................ 292 3 Buildbot Development 305 3.1 Development Quick-start......................................... 305 3.2 General Documents........................................... 307 3.3 APIs................................................... 391 3.4 Python3 compatibility.......................................... 484 3.5 Classes.................................................
    [Show full text]
  • Gerrit J.J. Van Den Burg, Phd London, UK | Email: [email protected] | Web: Gertjanvandenburg.Com
    Gerrit J.J. van den Burg, PhD London, UK | Email: [email protected] | Web: gertjanvandenburg.com Summary I am a research scientist with a PhD in machine learning and 8+ years of experience in academic research. I am currently looking to transition to industry to work on complex, large-scale problems that can have a positive real-world impact. I have extensive experience with machine learning modeling, algorithm design, and software engineering in Python, C, and R. My goal is to use my expertise and technical skills to address ongoing research challenges in machine learning and AI. Research Experience Postdoctoral Researcher — The Alan Turing Institute, UK 2018–2021 • Introduced a memorization score for probabilistic deep generative models and showed that neural networks can remember part of their input data, which has important implications for data privacy • Created a method for structure detection in textual data files that improved on the Python builtin method by 21%. Developed this into a Python package that has received over 600,000 downloads • Developed a robust Bayesian matrix factorization algorithm for time series modeling and forecasting that improved imputation error up to 60% while maintaining competitive runtime • Established the first benchmark dataset for change point detection on general real-world time series and determined the best performing methods, with consequences for research and practice • Collaborated with other researchers to design a unified interface for AI-powered data cleaning tools Doctoral Researcher
    [Show full text]
  • Optimization of Software Quality Using Management and Technical Review Techniques
    International Journal of Computer Trends and Technology (IJCTT) – volume 17 Number 6 Nov 2014 Optimization of Software Quality using Management and Technical Review Techniques Inibehe Emmanuel Akpannah Post Graduate Student (MSc. Information Technology), SRM University, Chennai, India Abstract compromising the security of the entire system. Optimizing the quality of software is a function of Improving the quality of our software process leads the degree of reviews made during the early life of to minimal rework, cost effectiveness and also a software development process. Reviews detect meeting up with schedules, which all lead to errors and potential errors early in the software improvement in capability measurement. Software development process. The errors detected during review is a chain process, it is dynamic and review the early life cycle of software are least expensive needs to be performed at every phase of the to correct. Efficient involvement in software development process until there is a transition to the inspections and technical reviews, help developers testing phase. improve their own skills, thereby mitigating the Software design and code review is a phase in the occurrence of errors in the later stage of software software development process in which development process. The ideas gathered on this programmers (authors of codes), quality assurance paper point that a properly implemented program of (QA) team, and peer reviewers get together to technical and management reviews drastically review design and code [9]. One way of optimizing reduces the time as well as the cost required for the quality of software is finding and correcting testing, debugging, and reworking, and dramatically errors at the early stage of a software development improves the quality of the resulting product.
    [Show full text]
  • The'as Code'activities: Development Anti-Patterns for Infrastructure As Code
    Empirical Software Engineering manuscript No. (will be inserted by the editor) The `as Code' Activities: Development Anti-patterns for Infrastructure as Code Akond Rahman · Effat Farhana · Laurie Williams Pre-print accepted at the Empirical Software Engineering Journal Abstract Context: The `as code' suffix in infrastructure as code (IaC) refers to applying software engineering activities, such as version control, to main- tain IaC scripts. Without the application of these activities, defects that can have serious consequences may be introduced in IaC scripts. A systematic investigation of the development anti-patterns for IaC scripts can guide prac- titioners in identifying activities to avoid defects in IaC scripts. Development anti-patterns are recurring development activities that relate with defective IaC scripts. Goal: The goal of this paper is to help practitioners improve the quality of infrastructure as code (IaC) scripts by identifying development ac- tivities that relate with defective IaC scripts. Methodology: We identify devel- opment anti-patterns by adopting a mixed-methods approach, where we apply quantitative analysis with 2,138 open source IaC scripts and conduct a sur- vey with 51 practitioners. Findings: We observe five development activities to be related with defective IaC scripts from our quantitative analysis. We iden- tify five development anti-patterns namely, `boss is not around', `many cooks spoil', `minors are spoiler', `silos', and `unfocused contribution'. Conclusion: Our identified development anti-patterns suggest
    [Show full text]
  • QUARTERLY CHECK-IN Technology (Services) TECH GOAL QUADRANT
    QUARTERLY CHECK-IN Technology (Services) TECH GOAL QUADRANT C Features that we build to improve our technology A Foundation level goals offering B Features we build for others D Modernization, renewal and tech debt goals The goals in each team pack are annotated using this scheme illustrate the broad trends in our priorities Agenda ● CTO Team ● Research and Data ● Design Research ● Performance ● Release Engineering ● Security ● Technical Operations Photos (left to right) Technology (Services) CTO July 2017 quarterly check-in All content is © Wikimedia Foundation & available under CC BY-SA 4.0, unless noted otherwise. CTO Team ● Victoria Coleman - Chief Technology Officer ● Joel Aufrecht - Program Manager (Technology) ● Lani Goto - Project Assistant ● Megan Neisler - Senior Project Coordinator ● Sarah Rodlund - Senior Project Coordinator ● Kevin Smith - Program Manager (Engineering) Photos (left to right) CHECK IN TEAM/DEPT PROGRAM WIKIMEDIA FOUNDATION July 2017 CTO 4.5 [LINK] ANNUAL PLAN GOAL: expand and strengthen our technical communities What is your objective / Who are you working with? What impact / deliverables are you expecting? workflow? Program 4: Technical LAST QUARTER community building (none) Outcome 5: Organize Wikimedia Developer Summit NEXT QUARTER Objective 1: Developer Technical Collaboration Decide on event location, dates, theme, deadlines, etc. Summit web page and publicize the information published four months before the event (B) STATUS: OBJECTIVE IN PROGRESS Technology (Services) Research and Data July, 2017 quarterly
    [Show full text]
  • VES Home Welcome to the VNF Event Stream (VES) Project Home
    VES Home Welcome to the VNF Event Stream (VES) Project Home This project was approved May 31, 2016 based upon the VNF Event Stream project proposal. In the meantime the project evolved and VES is not only used by VNF but also by PNF (physical network functions). However, the term "VES" is established and will be kept. Next to OPNFV and ONAP also O-RAN, O-RAN-SC and 3GPP are using VES. The term "xNF" refers to the combination of virtual network functions and physical network functions. Project description: Objective: This project will develop OPNFV platform support for VNF and PNF event streams, in a common model and format intended for use by Service Providers (SPs), e.g. in managing xNF health and lifecycle. The project’s goal is to enable a significant reduction in the effort to develop and integrate xNF telemetry-related data into automated xNF management systems, by promoting convergence toward a common event stream format and collection system. The VES doc source, code, and tests are available at: OPNFV github (generally updated with 30 minutes of merged commits) OPNFV gitweb To clone from the OPNFV repo, see the instructions at the Gerrit project page Powerpoint intro to the project: OPNVF VES.pptx. A demo of the project (vHello_VES Demo) was first presented at OpenStack Barcelona (2016), and updated for the OPNFV Summit 2017 (VES ONAP demo - see below for more info). The following diagram illustrates the concept and scope for the VES project, which includes: From ONAP a Common Event Data Model for the “VNF Event Stream”, with report "domains" covering e.g.
    [Show full text]
  • Metrics for Gerrit Code Reviews
    SPLST'15 Metrics for Gerrit code reviews Samuel Lehtonen and Timo Poranen University of Tampere, School of Information Sciences, Tampere, Finland [email protected],[email protected] Abstract. Code reviews are a widely accepted best practice in mod- ern software development. To enable easier and more agile code reviews, tools like Gerrit have been developed. Gerrit provides a framework for conducting reviews online, with no need for meetings or mailing lists. However, even with the help of tools like Gerrit, following and monitoring the review process becomes increasingly hard, when tens or even hun- dreds of code changes are uploaded daily. To make monitoring the review process easier, we propose a set of metrics to be used with Gerrit code review. The focus is on providing an insight to velocity and quality of code reviews, by measuring different review activities based on data, au- tomatically extracted from Gerrit. When automated, the measurements enable easy monitoring of code reviews, which help in establishing new best practices and improved review process. Keywords: Code quality; Code reviews; Gerrit; Metrics; 1 Introduction Code reviews are a widely used quality assurance practice in software engineer- ing, where developers read and assess each other's code before it is integrated into the codebase or deployed into production. Main motivations for reviews are to detect software defects and to improve code quality while sharing knowledge among developers. Reviews were originally introduced by Fagan [4] already in 1970's. The original, formal type of code inspections are still used in many com- panies, but has been often replaced with more modern types of reviews, where the review is not tied to place or time.
    [Show full text]
  • Whodo: Automating Reviewer Suggestions at Scale
    1 WhoDo: Automating reviewer suggestions at scale 59 2 60 3 61 4 Sumit Asthana B.Ashok Chetan Bansal 62 5 Microsoft Research India Microsoft Research India Microsoft Research India 63 6 [email protected] [email protected] [email protected] 64 7 65 8 Ranjita Bhagwan Christian Bird Rahul Kumar 66 9 Microsoft Research India Microsoft Research Redmond Microsoft Research India 67 10 [email protected] [email protected] [email protected] 68 11 69 12 Chandra Maddila Sonu Mehta 70 13 Microsoft Research India Microsoft Research India 71 14 [email protected] [email protected] 72 15 73 16 ABSTRACT ACM Reference Format: 74 17 Today’s software development is distributed and involves contin- Sumit Asthana, B.Ashok, Chetan Bansal, Ranjita Bhagwan, Christian Bird, 75 18 uous changes for new features and yet, their development cycle Rahul Kumar, Chandra Maddila, and Sonu Mehta. 2019. WhoDo: Automat- 76 ing reviewer suggestions at scale. In Proceedings of The 27th ACM Joint 19 has to be fast and agile. An important component of enabling this 77 20 European Software Engineering Conference and Symposium on the Founda- 78 agility is selecting the right reviewers for every code-change - the tions of Software Engineering (ESEC/FSE 2019). ACM, New York, NY, USA, 21 79 smallest unit of the development cycle. Modern tool-based code 9 pages. https://doi.org/10.1145/nnnnnnn.nnnnnnn 22 review is proven to be an effective way to achieve appropriate code 80 23 review of software changes. However, the selection of reviewers 81 24 in these code review systems is at best manual.
    [Show full text]
  • Fashion Terminology Today Describe Your Heritage Collections with an Eye on the Future
    Fashion Terminology Today Describe your heritage collections with an eye on the future Ykje Wildenborg MoMu – Fashion Museum of the Province of Antwerp, Belgium Europeana Fashion, Modemuze Abstract: This article was written for ‘non-techy people’, or people with a basic knowledge of information technology, interested in preparing their fashion heritage metadata for publication online. Publishing fashion heritage on the web brings about the undisputed need for a shared vocabulary, especially when merged. This is not only a question of multilingualism. Between collections and even within collections different words have been used to describe, for example, the same types of objects, materials or techniques. In professional language: the data often is “unclean”. Linked Data is the name of a development in information technology that could prove useful for fashion collecting institutions. It means that the descriptions of collections, in a computer readable format, have a structure that is extremely easy for the device to read. As alien as it may sound, Linked Data practices are already used by the data departments of larger museums, companies and governmental institutions around the world. It eliminates the need for translation or actual changing of the content of databases. It only concerns ‘labeling’ of terms in databases with an identifier. With this in mind, MoMu, the fashion museum of Antwerp, Belgium, is carrying out a termi- nology project in Flanders and the Netherlands, in order to motivate institutions to accomplish the task of labeling their terms. This article concludes with some of the experiences of this adventure, but firstly elucidates the context of the situation.
    [Show full text]
  • Software Reviews
    Software Reviews Software Engineering II WS 2020/21 Enterprise Platform and Integration Concepts Image by Chris Isherwood from flickr: https://www.flickr.com/photos/isherwoodchris/6807654905/ (CC BY-SA 2.0) Review Meetings a software product is [examined by] project personnel, “ managers, users, customers, user representatives, or other interested parties for comment or approval —IEEE1028 ” Principles ■ Generate comments on software ■ Several sets of eyes check ■ Emphasis on people over tools Code Reviews — Software Engineering II 2 Software Reviews Motivation ■ Improve code ■ Discuss alternative solutions ■ Transfer knowledge ■ Find defects Code Reviews — Software Engineering II Image by Glen Lipka: http://commadot.com/wtf-per-minute/ 3 Involved Roles Manager ■ Assessment is an important task for manager ■ Possible lack of deep technical understanding ■ Assessment of product vs. assessment of person ■ Outsider in review process ■ Support with resources (time, staff, rooms, …) Developer ■ Should not justify but only explain their results ■ No boss should take part at review Code Reviews — Software Engineering II 4 Review Team Team lead ■ Responsible for quality of review & moderation ■ Technical, personal and administrative competence Reviewer ■ Study the material before first meeting ■ Don’t try to achieve personal targets! ■ Give positive and negative comments on review artifacts Recorder ■ Any reviewer, can rotate even in review meeting ■ Protocol as basis for final review document Code Reviews — Software Engineering II 5 Tasks of
    [Show full text]
  • Full-Graph-Limited-Mvn-Deps.Pdf
    org.jboss.cl.jboss-cl-2.0.9.GA org.jboss.cl.jboss-cl-parent-2.2.1.GA org.jboss.cl.jboss-classloader-N/A org.jboss.cl.jboss-classloading-vfs-N/A org.jboss.cl.jboss-classloading-N/A org.primefaces.extensions.master-pom-1.0.0 org.sonatype.mercury.mercury-mp3-1.0-alpha-1 org.primefaces.themes.overcast-${primefaces.theme.version} org.primefaces.themes.dark-hive-${primefaces.theme.version}org.primefaces.themes.humanity-${primefaces.theme.version}org.primefaces.themes.le-frog-${primefaces.theme.version} org.primefaces.themes.south-street-${primefaces.theme.version}org.primefaces.themes.sunny-${primefaces.theme.version}org.primefaces.themes.hot-sneaks-${primefaces.theme.version}org.primefaces.themes.cupertino-${primefaces.theme.version} org.primefaces.themes.trontastic-${primefaces.theme.version}org.primefaces.themes.excite-bike-${primefaces.theme.version} org.apache.maven.mercury.mercury-external-N/A org.primefaces.themes.redmond-${primefaces.theme.version}org.primefaces.themes.afterwork-${primefaces.theme.version}org.primefaces.themes.glass-x-${primefaces.theme.version}org.primefaces.themes.home-${primefaces.theme.version} org.primefaces.themes.black-tie-${primefaces.theme.version}org.primefaces.themes.eggplant-${primefaces.theme.version} org.apache.maven.mercury.mercury-repo-remote-m2-N/Aorg.apache.maven.mercury.mercury-md-sat-N/A org.primefaces.themes.ui-lightness-${primefaces.theme.version}org.primefaces.themes.midnight-${primefaces.theme.version}org.primefaces.themes.mint-choc-${primefaces.theme.version}org.primefaces.themes.afternoon-${primefaces.theme.version}org.primefaces.themes.dot-luv-${primefaces.theme.version}org.primefaces.themes.smoothness-${primefaces.theme.version}org.primefaces.themes.swanky-purse-${primefaces.theme.version}
    [Show full text]