The document summarizes research investigating differences in code review practices between defective and clean files. It finds that reviews of files that will eventually become defective (future-defective files) tend to be less rigorous, with less intense discussion, less participation, and faster completion times, compared to reviews of clean files. In contrast, reviews of files that were previously defective (risky files) do not see increased rigor in terms of intensity, participation or duration compared to normal files.
This document describes data from a controlled, multiple case study of software evolution and defects from industrial projects. The study involved 12 software projects developed by 6 programmers across 2 systems. Data was collected on code smells, code changes, defects, task dates and other variables. Code, code smells and evolution data are available online, along with defect reports extracted from issue tracking systems. The goal is to enable further analysis of factors that influence software maintainability.
Leveraging Historical Co-change Information for Requirements TraceabilitySAIL_QU
This document discusses leveraging historical co-change information to improve requirements traceability. It presents the CoChaIR technique, which combines information retrieval (IR) techniques and analysis of files that tend to co-change together. An evaluation of CoChaIR on three datasets shows it leads to better accuracy and ranking than IR techniques alone, improving precision by up to 12.38% and recall by up to 5.67%, and decreasing rank by up to 48%. CoChaIR also removes up to 44% more false positive links than IR techniques.
- The document discusses Android app development lessons including app lifecycles, bundles, and event handling. It describes how to save app state using bundles during configuration changes and restarts. It also explains how to add click and text change listeners to buttons, text views and edit texts to handle user interaction events.
[Droidcon]Developing Apps for Android on 2.x/3.x/4.xKenichi Kambara
Kenichi Kambara gave a presentation on developing apps for Android across multiple versions and devices. He discussed designing user interfaces to support different screen sizes and densities. He also covered using APIs like Fragments and the action bar across versions. Finally, he provided code examples for using lazy loading to access newer APIs on older platforms in a single APK. The talk aimed to provide tips for developing apps that work well on both handsets and tablets running Android 2.x through 4.x.
Prioritizing the Devices to Test Your App On: A Case Study of Android Game AppsSAIL_QU
This document discusses prioritizing which devices to test mobile apps on based on user reviews. It analyzes reviews from 99 Android game apps and finds that, on average, 33% of devices account for 80% of reviews. Some devices, like the Motorola Droid X, tend to leave more negative reviews due to performance issues. The document proposes using the percentage of reviews from each device to predict the top devices to test on. When applied to 98 apps, the top 10 predicted devices matched the actual top 10 devices 7 out of 10 times on average. This approach could help app developers focus their testing efforts on the most important devices.
Android 4.0 Ice Cream Sandwich aimed to unite the Android platforms for smartphones and tablets by bringing together the best features of Gingerbread and Honeycomb. It improved multitasking capabilities and merged the interfaces to provide a cohesive experience across all devices. The new version targeted a Q4 2011 release and was Google's most ambitious Android update to date, focused on creating a unified operating system for both phones and tablets.
Who Should Review My Code? A file-location based code-reviewer recommendation approach for modern code review.
This research study is presented at the 22nd IEEE International Conference on Software Analysis, Evolution, and Reengineering (SANER2015)
Find more information and preprint at patanamon.com
Treating Code Quality as a First Class Entity (icsme15) [doc. symposium]Yuriy Tymchuk
This document discusses treating code quality as a first-class entity when developing software tools. It suggests that tools need a model that allows for smart quality rules that can aid in issue resolution, allows rules to be adapted for specific scopes like projects or teams, and is aware of software lifecycles and dependencies between projects. The document examines how tools could help with issues like reducing noise from rules, enhancing deprecation of APIs with rules, handling conflicts between rules for dependent projects, and determining the importance and cost of resolving issues over time.
This document describes data from a controlled, multiple case study of software evolution and defects from industrial projects. The study involved 12 software projects developed by 6 programmers across 2 systems. Data was collected on code smells, code changes, defects, task dates and other variables. Code, code smells and evolution data are available online, along with defect reports extracted from issue tracking systems. The goal is to enable further analysis of factors that influence software maintainability.
Leveraging Historical Co-change Information for Requirements TraceabilitySAIL_QU
This document discusses leveraging historical co-change information to improve requirements traceability. It presents the CoChaIR technique, which combines information retrieval (IR) techniques and analysis of files that tend to co-change together. An evaluation of CoChaIR on three datasets shows it leads to better accuracy and ranking than IR techniques alone, improving precision by up to 12.38% and recall by up to 5.67%, and decreasing rank by up to 48%. CoChaIR also removes up to 44% more false positive links than IR techniques.
- The document discusses Android app development lessons including app lifecycles, bundles, and event handling. It describes how to save app state using bundles during configuration changes and restarts. It also explains how to add click and text change listeners to buttons, text views and edit texts to handle user interaction events.
[Droidcon]Developing Apps for Android on 2.x/3.x/4.xKenichi Kambara
Kenichi Kambara gave a presentation on developing apps for Android across multiple versions and devices. He discussed designing user interfaces to support different screen sizes and densities. He also covered using APIs like Fragments and the action bar across versions. Finally, he provided code examples for using lazy loading to access newer APIs on older platforms in a single APK. The talk aimed to provide tips for developing apps that work well on both handsets and tablets running Android 2.x through 4.x.
Prioritizing the Devices to Test Your App On: A Case Study of Android Game AppsSAIL_QU
This document discusses prioritizing which devices to test mobile apps on based on user reviews. It analyzes reviews from 99 Android game apps and finds that, on average, 33% of devices account for 80% of reviews. Some devices, like the Motorola Droid X, tend to leave more negative reviews due to performance issues. The document proposes using the percentage of reviews from each device to predict the top devices to test on. When applied to 98 apps, the top 10 predicted devices matched the actual top 10 devices 7 out of 10 times on average. This approach could help app developers focus their testing efforts on the most important devices.
Android 4.0 Ice Cream Sandwich aimed to unite the Android platforms for smartphones and tablets by bringing together the best features of Gingerbread and Honeycomb. It improved multitasking capabilities and merged the interfaces to provide a cohesive experience across all devices. The new version targeted a Q4 2011 release and was Google's most ambitious Android update to date, focused on creating a unified operating system for both phones and tablets.
Who Should Review My Code? A file-location based code-reviewer recommendation approach for modern code review.
This research study is presented at the 22nd IEEE International Conference on Software Analysis, Evolution, and Reengineering (SANER2015)
Find more information and preprint at patanamon.com
Treating Code Quality as a First Class Entity (icsme15) [doc. symposium]Yuriy Tymchuk
This document discusses treating code quality as a first-class entity when developing software tools. It suggests that tools need a model that allows for smart quality rules that can aid in issue resolution, allows rules to be adapted for specific scopes like projects or teams, and is aware of software lifecycles and dependencies between projects. The document examines how tools could help with issues like reducing noise from rules, enhancing deprecation of APIs with rules, handling conflicts between rules for dependent projects, and determining the importance and cost of resolving issues over time.
Code review is one of the crucial software activities where developers and stakeholders collaborate with each other in order to assess software changes. Since code review processes act as a final gate for new software changes to be integrated into the software product, an intense collaboration is necessary in order to prevent defects and produce a high quality of software products. Recently, code review analytics has been implemented in projects (for example, StackAnalytics4 of the OpenStack project) to monitor the collaboration activities between developers and stakeholders in the code review processes. Yet, due to the large volume of software data, code review analytics can only report a static summary (e.g., counting), while neither insights nor instant suggestions are provided. Hence, to better gain valuable insights from software data and help software projects make a better decision, we conduct an empirical investigation using statistical approaches. In particular, we use the large-scale data of 196,712 reviews spread across the Android, Qt, and OpenStack open source projects to train a prediction model in order to uncover the relationship between the characteristics of software changes and the likelihood of having poor code review collaborations. We extract 20 patch characteristics which are grouped along five dimensions, i.e., software changes properties, review participation history, past involvement of a code author, past involvement of reviewers, and review environment dimensions. To validate our findings, we use the bootstrap technique which repeats the experiment 1,000 times. Due to the large volume of studied data, and an intensive computation of characteristic extraction and find- ing validation, the use of the High-Performance-Computing (HPC) re- sources is mandatory to expedite the analysis and generate insights in a timely manner. Through our case study, we find that the amount of review participation in the past and the description length of software changes are a significant indicator that new software changes will suffer from poor code review collaborations [2017]. Moreover, we find that the purpose of introducing new features can increase the likelihood that new software changes will receive late collaboration from reviewers. Our findings highlight the need for the policies of software change submission that monitor these characteristics in order to help software projects improve the quality of code reviews processes. Moreover, based on our findings, future work should develop real-time code review analytics implemented on HPC resources in order to instantly provide insights and suggestions to software projects
OSSF 2018 - Jamie Jones of GitHub - Pull what where? Contributing to Open Sou...FINOS
Pull Requests? Upstream Remotes? Compact Discs? Understanding how to publish code developed inside your organization into the Open Source world can leave you with more questions than answers. In this talk, we will cover key strategies, as well as the workflows and tools that make it possible, for moving past merely consuming open source on GitHub to becoming contributors. Whether you are an IT Manager or Head of Open Source, you will walk away with tips to on how to contribute while staying compliant with legal, technical and security approvals within your organization.
Three Interviews About Static Code AnalyzersAndrey Karpov
The author invites you to read three interviews with representatives of three large, modern and
interesting projects to learn about their software development methodologies and about how they use
static code analyzers in particular. The author hopes that you will find this article interesting. The
following companies took part as interviewees: Acronis, AlternativaPlatform, Echelon Company.
Sincerely yours, Aleksandr Timofeev
The document discusses factors that impact the effectiveness of code contributions to open source projects. It identifies tensions that can arise between contributors wanting quick approval of their code and reviewers having other considerations around code quality and maintainability. It recommends good planning, preparation, communication and following community workflows and conventions to help contributions be reviewed efficiently with minimal iterations.
This document discusses code reviews and how Fisheye and Crucible can be used to facilitate the code review process. It provides an overview of the key features of Fisheye for viewing and searching code and Crucible for conducting code reviews and collaborating on review comments. Examples are given of how to use Fisheye to view changes, commits, and reviews and how to navigate and manage reviews within Crucible.
Ph.D. Thesis Defense: Studying Reviewer Selection and Involvement in Modern ...The University of Adelaide
Patanamon's Ph.D. thesis defense at Graduate School of Infomation Science, Nara Institute of Science and Technology, Japan. The thesis title is Studying Reviewer Selection and Involvement in Modern Code Review Processes. This presentation takes 20 minutes.
Improving Code Quality In Medical Software Through Code Reviews - Vincit Teat...VincitOy
The document discusses improving code quality in medical software through code reviews. It describes how one project implemented peer code reviews to prevent bugs, share knowledge, and improve discipline. The project evolved its workflow from long review cycles with many changes to immediate reviews of individual commits. Reviews check functionality, style, implementation, and readability. Commit messages are also reviewed to improve the project history. Tools like Git, Gerrit and Buildbot help automate version control, reviews and continuous integration.
Software Analytics: Data Analytics for Software EngineeringTao Xie
This document summarizes a presentation on software analytics and its achievements and opportunities. It begins by noting how both how software and how it is built and operated are changing, with data becoming more pervasive and development more distributed. It then defines software analytics as enabling analysis of software data to obtain insights and make informed decisions. It outlines research topics covering different areas of the software domain throughout the development cycle. It describes target audiences of software practitioners and outputs of insightful and actionable information. Selected projects demonstrating software analytics are then summarized, including StackMine for performance debugging at scale, XIAO for scalable code clone analysis, and others.
How do you integrate security within a Continuous Deployment (CD) environment - where every 5 minutes a feature, an enhancement, or a bug fix needs to be released?
Traditional application security tools which require lengthy periods of configuration, tuning and
application learning have become irrelevant in these fast-pace environments. Yet, falling back only on
the secure coding practices of the developer cannot be tolerated.
Secure coding requires a new approach where security tools become part of the development environment – and eliminate any unnecessary overhead. By collaborating with development teams, understanding their needs and requirements, you can pave the way to a secure deployment in minutes.
The document discusses Bibliomation's process of transitioning to an open source integrated library system (ILS). It describes how they initially explored the Koha ILS in 2008 but did not move forward at that time. In 2009, they re-evaluated Koha and other open source options. They ultimately decided to implement Evergreen, hiring a project manager, implementation coordinator, and software coordinator. Their first libraries to launch on Evergreen were Beacon Falls Library in March 2010 and Douglas Library in March 2010. The document also provides an overview of the Evergreen architecture and components. It concludes by discussing future plans such as implementing a master-slave database setup and additional web servers.
Our hope is that defenders and reverse engineers can make use of the project updates to validate their preparedness and techniques against highly targeted malware. As discussed in our presentation, detection of malicious code in runtime interpreted languages is error prone and difficult. Shortly after our initial presentation at INFILTRATE, Kaspersky created an AV signature that flagged as malicious many of the most popular GO language applications such as Docker, a Bitcoin wallet and the actual Golang installer in an attempt to flag EBOWLA binaries – oops.
We’ve updated the project to include a new loader for PowerShell. This ubiquitous Windows scripting language is widely used in offensive testing and by defenders for incident response. Now the incident responder will need to be proficient in PowerShell debugging to begin the task of decrypting targeted malware that could also end up being more PowerShell! Post-Ekoparty, the team is working on a traditional loader using C++ compiled code, so stay tuned and visit our EBOWLA GitHub page for future updates.
Our hope is that defenders and reverse engineers can make use of the project updates to validate their preparedness and techniques against highly targeted malware. As discussed in our presentation, detection of malicious code in runtime interpreted languages is error prone and difficult. Shortly after our initial presentation at INFILTRATE, Kaspersky created an AV signature that flagged as malicious many of the most popular GO language applications such as Docker, a Bitcoin wallet and the actual Golang installer in an attempt to flag EBOWLA binaries – oops.
We’ve updated the project to include a new loader for PowerShell. This ubiquitous Windows scripting language is widely used in offensive testing and by defenders for incident response. Now the incident responder will need to be proficient in PowerShell debugging to begin the task of decrypting targeted malware that could also end up being more PowerShell! Post-Ekoparty, the team is working on a traditional loader using C++ compiled code, so stay tuned and visit our EBOWLA GitHub page for future updates.
Software Analytics: Data Analytics for Software Engineering and SecurityTao Xie
Frodo Baggins presents on software analytics for software engineering and security tasks. The presentation discusses how software and how it is built and used is changing, with data now being ubiquitous and software having continuous development and release. Software analytics aims to enable software practitioners to perform data exploration and analysis to obtain useful insights. Examples of software analytics techniques discussed include XIAO for scalable code clone analysis, and SAS for incident management of online services. The presentation then shifts to discussing software analytics techniques for mobile app security, including WHYPER for natural language processing on app descriptions to link permissions to functionality, and AppContext for machine learning to classify malware.
Research seminar slides at URJC June 6. Briefly: social analysis; more detailed: static analysis and co-evolution (joint w Landman, Vinju, Muske; Businge).
Presentation given at Oracle Code One - 16 September 2019, San Francisco / USA
Do your customers keep complaining about bugs in your software application? Does it take you too long to fix bugs and implement new features? If yes, then you may have issues with the quality of your application. This session provides practical advice on how you can improve the quality of your software application. The speaker shares with you all the lessons he learned while working as a software engineer for a big, complex enterprise application, discussing which techniques worked and which ones failed and providing actual examples and metrics from that application. It’s assumed that you have already experienced the struggle of maintaining a defective software application and that you aspire to building software of top quality.
The document discusses integrating security practices within DevOps environments. It begins by introducing DevOps and noting that traditional security controls like penetration testing and code analysis are too slow for continuous deployment. It then outlines a three step approach to DevOps security: 1) Plan security requirements upfront, 2) Engage developers in security, and 3) Automate security checks into the continuous integration/deployment pipeline. The key takeaways are to plan security thoroughly, involve developers, and integrate security testing automatically into the build process.
The document summarizes updates to the Jenkins project since its split from the Hudson project in 2011. It discusses the interim governance board, increased development activity and contributions from the community, initiatives to improve plugin development and testing, and plans for a stable but older release line and logo contest. The project is thriving with more users, developers, and formal governance processes since the split from Hudson.
This document provides a case study on a project created using open source technology. It discusses analyzing project goals and resources, evaluating open source options based on total cost of ownership, implementing a solution using LAMP stack, and lessons learned. The project was developed using Linux, Apache, MySQL, and PHP based on the needs of a low budget, ability to invest in internal skills, and reduce dependency on external trends. Key steps included preparing the Linux server, using version control and local testing, and engaging the open source community for support.
Studying the Integration Practices and the Evolution of Ad Libraries in the G...SAIL_QU
In-app advertisements have become a major revenue for app developers in the mobile app economy. Ad libraries play an integral part in this ecosystem as app
developers integrate these libraries into their apps to display ads. However, little is known about how app developers integrate these libraries with their apps and how these libraries have evolved over time.
In this thesis, we study the ad library integration practices and the evolution of such libraries. To understand the integration practices of ad libraries, we manually study apps and derive a set of rules to automatically identify four strategies for integrating
multiple ad libraries. We observe that integrating multiple ad libraries commonly occurs in apps with a large number of downloads and ones in categories with a high percentage of apps that display ads. We also observe that app developers prefer to manage their own integrations instead of using off the shelf features of ad libraries for integrating multiple ad libraries.
To study the evolution of ad libraries, we conduct a longitudinal study of the 8 most popular ad libraries. In particular, we look at their evolution in terms of size, the main drivers for releasing a new ad library version, and their architecture. We observe that ad libraries are continuously evolving with a median release interval of 34 days. Some ad libraries have grown exponentially in size (e.g., Facebook Audience Network ad library), while other libraries have worked to reduce their size. To study the main drivers for releasing an ad library version, we manually study the release notes of the eight studied ad libraries. We observe that ad library developers continuously update their ad libraries to support a wider range of Android versions (i.e., to ensure that more devices can use the libraries without errors). Finally, we derive a reference architecture for ad libraries and study how the studied ad libraries diverged from this architecture during our study period.
Our findings can assist ad library developers to understand the challenges for developing ad libraries and the desired features of these libraries.
Code review is one of the crucial software activities where developers and stakeholders collaborate with each other in order to assess software changes. Since code review processes act as a final gate for new software changes to be integrated into the software product, an intense collaboration is necessary in order to prevent defects and produce a high quality of software products. Recently, code review analytics has been implemented in projects (for example, StackAnalytics4 of the OpenStack project) to monitor the collaboration activities between developers and stakeholders in the code review processes. Yet, due to the large volume of software data, code review analytics can only report a static summary (e.g., counting), while neither insights nor instant suggestions are provided. Hence, to better gain valuable insights from software data and help software projects make a better decision, we conduct an empirical investigation using statistical approaches. In particular, we use the large-scale data of 196,712 reviews spread across the Android, Qt, and OpenStack open source projects to train a prediction model in order to uncover the relationship between the characteristics of software changes and the likelihood of having poor code review collaborations. We extract 20 patch characteristics which are grouped along five dimensions, i.e., software changes properties, review participation history, past involvement of a code author, past involvement of reviewers, and review environment dimensions. To validate our findings, we use the bootstrap technique which repeats the experiment 1,000 times. Due to the large volume of studied data, and an intensive computation of characteristic extraction and find- ing validation, the use of the High-Performance-Computing (HPC) re- sources is mandatory to expedite the analysis and generate insights in a timely manner. Through our case study, we find that the amount of review participation in the past and the description length of software changes are a significant indicator that new software changes will suffer from poor code review collaborations [2017]. Moreover, we find that the purpose of introducing new features can increase the likelihood that new software changes will receive late collaboration from reviewers. Our findings highlight the need for the policies of software change submission that monitor these characteristics in order to help software projects improve the quality of code reviews processes. Moreover, based on our findings, future work should develop real-time code review analytics implemented on HPC resources in order to instantly provide insights and suggestions to software projects
OSSF 2018 - Jamie Jones of GitHub - Pull what where? Contributing to Open Sou...FINOS
Pull Requests? Upstream Remotes? Compact Discs? Understanding how to publish code developed inside your organization into the Open Source world can leave you with more questions than answers. In this talk, we will cover key strategies, as well as the workflows and tools that make it possible, for moving past merely consuming open source on GitHub to becoming contributors. Whether you are an IT Manager or Head of Open Source, you will walk away with tips to on how to contribute while staying compliant with legal, technical and security approvals within your organization.
Three Interviews About Static Code AnalyzersAndrey Karpov
The author invites you to read three interviews with representatives of three large, modern and
interesting projects to learn about their software development methodologies and about how they use
static code analyzers in particular. The author hopes that you will find this article interesting. The
following companies took part as interviewees: Acronis, AlternativaPlatform, Echelon Company.
Sincerely yours, Aleksandr Timofeev
The document discusses factors that impact the effectiveness of code contributions to open source projects. It identifies tensions that can arise between contributors wanting quick approval of their code and reviewers having other considerations around code quality and maintainability. It recommends good planning, preparation, communication and following community workflows and conventions to help contributions be reviewed efficiently with minimal iterations.
This document discusses code reviews and how Fisheye and Crucible can be used to facilitate the code review process. It provides an overview of the key features of Fisheye for viewing and searching code and Crucible for conducting code reviews and collaborating on review comments. Examples are given of how to use Fisheye to view changes, commits, and reviews and how to navigate and manage reviews within Crucible.
Ph.D. Thesis Defense: Studying Reviewer Selection and Involvement in Modern ...The University of Adelaide
Patanamon's Ph.D. thesis defense at Graduate School of Infomation Science, Nara Institute of Science and Technology, Japan. The thesis title is Studying Reviewer Selection and Involvement in Modern Code Review Processes. This presentation takes 20 minutes.
Improving Code Quality In Medical Software Through Code Reviews - Vincit Teat...VincitOy
The document discusses improving code quality in medical software through code reviews. It describes how one project implemented peer code reviews to prevent bugs, share knowledge, and improve discipline. The project evolved its workflow from long review cycles with many changes to immediate reviews of individual commits. Reviews check functionality, style, implementation, and readability. Commit messages are also reviewed to improve the project history. Tools like Git, Gerrit and Buildbot help automate version control, reviews and continuous integration.
Software Analytics: Data Analytics for Software EngineeringTao Xie
This document summarizes a presentation on software analytics and its achievements and opportunities. It begins by noting how both how software and how it is built and operated are changing, with data becoming more pervasive and development more distributed. It then defines software analytics as enabling analysis of software data to obtain insights and make informed decisions. It outlines research topics covering different areas of the software domain throughout the development cycle. It describes target audiences of software practitioners and outputs of insightful and actionable information. Selected projects demonstrating software analytics are then summarized, including StackMine for performance debugging at scale, XIAO for scalable code clone analysis, and others.
How do you integrate security within a Continuous Deployment (CD) environment - where every 5 minutes a feature, an enhancement, or a bug fix needs to be released?
Traditional application security tools which require lengthy periods of configuration, tuning and
application learning have become irrelevant in these fast-pace environments. Yet, falling back only on
the secure coding practices of the developer cannot be tolerated.
Secure coding requires a new approach where security tools become part of the development environment – and eliminate any unnecessary overhead. By collaborating with development teams, understanding their needs and requirements, you can pave the way to a secure deployment in minutes.
The document discusses Bibliomation's process of transitioning to an open source integrated library system (ILS). It describes how they initially explored the Koha ILS in 2008 but did not move forward at that time. In 2009, they re-evaluated Koha and other open source options. They ultimately decided to implement Evergreen, hiring a project manager, implementation coordinator, and software coordinator. Their first libraries to launch on Evergreen were Beacon Falls Library in March 2010 and Douglas Library in March 2010. The document also provides an overview of the Evergreen architecture and components. It concludes by discussing future plans such as implementing a master-slave database setup and additional web servers.
Our hope is that defenders and reverse engineers can make use of the project updates to validate their preparedness and techniques against highly targeted malware. As discussed in our presentation, detection of malicious code in runtime interpreted languages is error prone and difficult. Shortly after our initial presentation at INFILTRATE, Kaspersky created an AV signature that flagged as malicious many of the most popular GO language applications such as Docker, a Bitcoin wallet and the actual Golang installer in an attempt to flag EBOWLA binaries – oops.
We’ve updated the project to include a new loader for PowerShell. This ubiquitous Windows scripting language is widely used in offensive testing and by defenders for incident response. Now the incident responder will need to be proficient in PowerShell debugging to begin the task of decrypting targeted malware that could also end up being more PowerShell! Post-Ekoparty, the team is working on a traditional loader using C++ compiled code, so stay tuned and visit our EBOWLA GitHub page for future updates.
Our hope is that defenders and reverse engineers can make use of the project updates to validate their preparedness and techniques against highly targeted malware. As discussed in our presentation, detection of malicious code in runtime interpreted languages is error prone and difficult. Shortly after our initial presentation at INFILTRATE, Kaspersky created an AV signature that flagged as malicious many of the most popular GO language applications such as Docker, a Bitcoin wallet and the actual Golang installer in an attempt to flag EBOWLA binaries – oops.
We’ve updated the project to include a new loader for PowerShell. This ubiquitous Windows scripting language is widely used in offensive testing and by defenders for incident response. Now the incident responder will need to be proficient in PowerShell debugging to begin the task of decrypting targeted malware that could also end up being more PowerShell! Post-Ekoparty, the team is working on a traditional loader using C++ compiled code, so stay tuned and visit our EBOWLA GitHub page for future updates.
Software Analytics: Data Analytics for Software Engineering and SecurityTao Xie
Frodo Baggins presents on software analytics for software engineering and security tasks. The presentation discusses how software and how it is built and used is changing, with data now being ubiquitous and software having continuous development and release. Software analytics aims to enable software practitioners to perform data exploration and analysis to obtain useful insights. Examples of software analytics techniques discussed include XIAO for scalable code clone analysis, and SAS for incident management of online services. The presentation then shifts to discussing software analytics techniques for mobile app security, including WHYPER for natural language processing on app descriptions to link permissions to functionality, and AppContext for machine learning to classify malware.
Research seminar slides at URJC June 6. Briefly: social analysis; more detailed: static analysis and co-evolution (joint w Landman, Vinju, Muske; Businge).
Presentation given at Oracle Code One - 16 September 2019, San Francisco / USA
Do your customers keep complaining about bugs in your software application? Does it take you too long to fix bugs and implement new features? If yes, then you may have issues with the quality of your application. This session provides practical advice on how you can improve the quality of your software application. The speaker shares with you all the lessons he learned while working as a software engineer for a big, complex enterprise application, discussing which techniques worked and which ones failed and providing actual examples and metrics from that application. It’s assumed that you have already experienced the struggle of maintaining a defective software application and that you aspire to building software of top quality.
The document discusses integrating security practices within DevOps environments. It begins by introducing DevOps and noting that traditional security controls like penetration testing and code analysis are too slow for continuous deployment. It then outlines a three step approach to DevOps security: 1) Plan security requirements upfront, 2) Engage developers in security, and 3) Automate security checks into the continuous integration/deployment pipeline. The key takeaways are to plan security thoroughly, involve developers, and integrate security testing automatically into the build process.
The document summarizes updates to the Jenkins project since its split from the Hudson project in 2011. It discusses the interim governance board, increased development activity and contributions from the community, initiatives to improve plugin development and testing, and plans for a stable but older release line and logo contest. The project is thriving with more users, developers, and formal governance processes since the split from Hudson.
This document provides a case study on a project created using open source technology. It discusses analyzing project goals and resources, evaluating open source options based on total cost of ownership, implementing a solution using LAMP stack, and lessons learned. The project was developed using Linux, Apache, MySQL, and PHP based on the needs of a low budget, ability to invest in internal skills, and reduce dependency on external trends. Key steps included preparing the Linux server, using version control and local testing, and engaging the open source community for support.
Studying the Integration Practices and the Evolution of Ad Libraries in the G...SAIL_QU
In-app advertisements have become a major revenue for app developers in the mobile app economy. Ad libraries play an integral part in this ecosystem as app
developers integrate these libraries into their apps to display ads. However, little is known about how app developers integrate these libraries with their apps and how these libraries have evolved over time.
In this thesis, we study the ad library integration practices and the evolution of such libraries. To understand the integration practices of ad libraries, we manually study apps and derive a set of rules to automatically identify four strategies for integrating
multiple ad libraries. We observe that integrating multiple ad libraries commonly occurs in apps with a large number of downloads and ones in categories with a high percentage of apps that display ads. We also observe that app developers prefer to manage their own integrations instead of using off the shelf features of ad libraries for integrating multiple ad libraries.
To study the evolution of ad libraries, we conduct a longitudinal study of the 8 most popular ad libraries. In particular, we look at their evolution in terms of size, the main drivers for releasing a new ad library version, and their architecture. We observe that ad libraries are continuously evolving with a median release interval of 34 days. Some ad libraries have grown exponentially in size (e.g., Facebook Audience Network ad library), while other libraries have worked to reduce their size. To study the main drivers for releasing an ad library version, we manually study the release notes of the eight studied ad libraries. We observe that ad library developers continuously update their ad libraries to support a wider range of Android versions (i.e., to ensure that more devices can use the libraries without errors). Finally, we derive a reference architecture for ad libraries and study how the studied ad libraries diverged from this architecture during our study period.
Our findings can assist ad library developers to understand the challenges for developing ad libraries and the desired features of these libraries.
Improving the testing efficiency of selenium-based load testsSAIL_QU
Slides for a paper published at AST 2019:
Shahnaz M. Shariff, Heng Li, Cor-Paul Bezemer, Ahmed E. Hassan, Thanh H. D. Nguyen, and Parminder Flora. 2019. Improving the testing efficiency of selenium-based load tests. In Proceedings of the 14th International Workshop on Automation of Software Test (AST '19). IEEE Press, Piscataway, NJ, USA, 14-20. DOI: https://doi.org/10.1109/AST.2019.00008
Studying User-Developer Interactions Through the Distribution and Reviewing M...SAIL_QU
This document discusses studying user-developer interactions through the distribution and reviewing mechanisms of the Google Play Store. It analyzes emergency updates made by developers to fix issues, the dialogue between users and developers through reviews and responses, and how the reviewing mechanism can help identify good and bad updates. The study found that responding to reviews is six times more likely to increase an app's rating, with 84% of rating increases going to four or five stars. Three common patterns of developer responses were identified: responding to negative or long reviews, only negative reviews, and reviews shortly after an update.
Studying online distribution platforms for games through the mining of data f...SAIL_QU
Our studies of Steam platform data provided insights into online game distribution:
1) Urgent game updates were used to fix crashes, balance issues, and functionality; frequent updaters released more 0-day patches.
2) The Early Access model attracted indie developers and increased game participation; reviews were more positive during Early Access.
3) Game reviews were typically short and in English; sales increased review volume more than new updates; negative reviews came after longer play.
Understanding the Factors for Fast Answers in Technical Q&A Websites: An Empi...SAIL_QU
This study analyzed factors that impact the speed of questions receiving accepted answers on four popular Stack Exchange websites: Stack Overflow, Mathematics, Ask Ubuntu, and Super User. The researchers examined question, answerer, asker, and answer factors from over 150,000 questions. They built classification models and found that key factors for fast answers included the past speed of answerers, length of the question, and past speed of answers for the question's tags. The models achieved AUCs of 0.85-0.95. Fast answers relied heavily on answerers, especially frequent answerers. The study suggests improving incentives for non-frequent and more difficult questions to attract diverse answerers.
Investigating the Challenges in Selenium Usage and Improving the Testing Effi...SAIL_QU
Selenium is a popular tool for browser-based automation testing. The author analyzes challenges in using Selenium by mining Selenium questions on Stack Overflow. Programming language-related questions, especially for Java and Python, are most common and growing fastest. Less than half of questions receive accepted answers, and questions about browsers and components take longest. In the second part, the author develops an approach to improve efficiency of Selenium-based load testing by sharing browsers among user instances. This increases the number of error-free users by 20-22% while reducing memory usage.
Mining Development Knowledge to Understand and Support Software Logging Pract...SAIL_QU
This document summarizes Heng Li's PhD thesis on mining development knowledge to understand and support software logging practices. It discusses how logging code is used to record runtime information but can be difficult for developers to maintain. The thesis aims to understand current logging practices and develop tools by mining change history, source code, issue reports, and other development knowledge. It presents research that analyzes logging-related issues to identify developers' logging concerns, uses code topics and structure to predict where logging statements should be added, leverages code changes to suggest when logging code needs updating, and applies machine learning models to recommend appropriate log levels.
Which Log Level Should Developers Choose For a New Logging Statement?SAIL_QU
The document discusses choosing an appropriate log level when adding a new logging statement. It finds that an ordinal regression model can effectively model log levels, achieving an AUC of 0.76-0.81 in within-project evaluation and 0.71-0.8 in cross-project evaluation. The most influential factors for determining log levels vary between projects and include metrics related to the logging statement, containing code block, and file as well as code change and historical change metrics.
Towards Just-in-Time Suggestions for Log ChangesSAIL_QU
The document presents a study on providing just-in-time suggestions for log changes when developers make code changes. The researchers analyzed over 32,000 log changes from 4 systems. They found 20 reasons for log changes that fall into 4 categories: block changes, log improvements, dependence-driven changes, and logging issues. A random forest classifier using 25 software metrics related to code changes, history, and complexity achieved 0.84-0.91 AUC in predicting whether a log change is needed. Change metrics and product metrics were the most influential factors. The study aims to help developers make better logging decisions for failure diagnosis.
The Impact of Task Granularity on Co-evolution AnalysesSAIL_QU
The document discusses how task granularity at different levels (e.g. commits, pull requests, work items) can impact analyses of co-evolution in software projects. It finds that analyzing at the commit-level can overlook relationships between tasks that span multiple commits. Work item level analysis is recommended to provide a more complete view of co-evolution, as median of 29% of work items consist of multiple commits, and analyzing at the commit level would miss 24% of co-changed files and inability to group 83% of related commits.
How are Discussions Associated with Bug Reworking? An Empirical Study on Open...SAIL_QU
1) Initial bug fix discussions with more comments and more developers participating are more likely to experience later bug reworking through re-opening or re-patching of the bug.
2) Manual analysis found that defective initial fixes and failure to reach consensus in discussions contributed to later reworking.
3) For re-opened bugs, initial discussions focused on addressing a particular problem through a burst of comments, while re-patched bugs lacked thorough code review and testing during the initial fix period.
A Study of the Relation of Mobile Device Attributes with the User-Perceived Q...SAIL_QU
This study examined the relationship between mobile device attributes and user-perceived quality of Android apps. The researchers analyzed 150,373 star ratings from Google Play across 30 devices and 280 apps. They found that the perceived quality of apps varies across devices, and having better characteristics of an attribute does not necessarily correlate with higher quality. Device OS version, resolution, and CPU showed significant relationships with ratings, as did some app attributes like lines of code and number of inputs. However, some device attributes had stronger relationships than app attributes.
A Large-Scale Study of the Impact of Feature Selection Techniques on Defect C...SAIL_QU
This document presents the results of a large-scale study on the impact of feature selection techniques on defect classification models. The study used expanded scopes including multiple datasets from NASA and PROMISE with different feature types, more classification techniques from different paradigms, and additional feature selection techniques. The results show that correlation-based feature subset selection techniques like FS1 and FS2 consistently appear in the top ranks across most of the datasets, projects within the datasets, and classification techniques. The document concludes that future defect classification studies should consider applying correlation-based feature selection techniques.
Studying the Dialogue Between Users and Developers of Free Apps in the Google...SAIL_QU
The study analyzes user-developer interactions through reviews and responses on the Google Play Store. It finds that responding to reviews has a significant positive impact, with 84% of rating increases due to the developer addressing the issue or providing guidance. Three common response patterns were identified: only negative reviews, negative or longer reviews, and reviews shortly after an update. Developers most often thank the user, ask for details, provide guidance, or ask for an endorsement. Guidance responses can address common issues through FAQs. The analysis considered over 2,000 apps, 355,000 review changes, 128,000 responses, and 4 million reviews.
What Do Programmers Know about Software Energy Consumption?SAIL_QU
This document summarizes the results of a survey of 122 programmers about their knowledge of software energy consumption. The survey found that programmers have limited awareness of energy consumption and how to reduce it. They were unaware of the main causes of high energy usage. Programmers lacked knowledge about how to properly rank the energy consumption of different hardware components and were unfamiliar with strategies to improve efficiency, such as minimizing I/O and avoiding polling. The study concludes that programmers would benefit from more education on software energy usage and its causes.
Revisiting the Experimental Design Choices for Approaches for the Automated R...SAIL_QU
Prior research on automated duplicate issue report retrieval focused on improving performance metrics like recall rate. The author revisits experimental design choices from four perspectives: needed effort, data changes, data filtration, and evaluation process.
The thesis contributions are: 1) Showing the importance of considering needed effort in performance measurement. 2) Proposing a "realistic evaluation" approach and analyzing prior findings with it. 3) Developing a genetic algorithm to filter old issue reports and improve performance. 4) Highlighting the impact of "just-in-time" features on evaluation. The findings help better understand benefits and limitations of prior work in this area.
Measuring Program Comprehension: A Large-Scale Field Study with ProfessionalsSAIL_QU
The document summarizes a large-scale field study that tracked the program comprehension activities of 78 professional developers over 3,148 hours. The study found that:
1) Program comprehension accounted for approximately 58% of developers' time on average, with navigation and editing making up the remaining portions.
2) Developers frequently used web browsers and document editors to aid comprehension beyond just IDEs.
3) Interviews and observations revealed that insufficient documentation, unclear code, and complex inheritance hierarchies contributed to long comprehension sessions.
Measuring Program Comprehension: A Large-Scale Field Study with Professionals
Presentationpick 150517080804-lva1-app6892
1. Investigating Code Review Practices
in Defective Files
Patanamon (Pick)
Thongtanunam
Shane McIntosh
Ahmed E.
Hassan
Hajimu Iida
May 16-17, 2015.
Firenze, Italy
patanamon-t@is.naist.jp @pamon
2. Modern Code Review: A lightweight, tool-supported
code review process
Code Review Tool
3. Modern Code Review: A lightweight, tool-supported
code review process
Code Review Tool
Code change
4. Modern Code Review: A lightweight, tool-supported
code review process
Code Review Tool
Code change
5. Modern Code Review: A lightweight, tool-supported
code review process
Code Review Tool
Code change
Examine Code
6. Modern Code Review: A lightweight, tool-supported
code review process
Upstream VCS
repositories
Code Review Tool
Code change
Examine Code
7. Modern Code Review: A lightweight, tool-supported
code review process
Upstream VCS
repositories
Code change
A lack of code review
activity can increase the
risk of post-release defects
[McIntosh et. al., MSR2014]
My code is awesome!
No needs for a review
Code Review Tool
Code change
Examine Code
8. Modern Code Review: A lightweight, tool-supported
code review process
Upstream VCS
repositories
Code change
A lack of code review
activity can increase the
risk of post-release defects
[McIntosh et. al., MSR2014]
My code is awesome!
No needs for a review
Code Review Tool
Code change
How should reviewers do a code
review to reduce the risk of
having defects?
Examine Code
9. What is the difference between code review
practices of defective and clean files?
10. What is the difference between code review
practices of defective and clean files?
Review Practice A
Defective
i.e., files that have defects
11. Defect-free (Clean)
i.e., files that do not have defects
Review Practice B
What is the difference between code review
practices of defective and clean files?
Review Practice A
VS
Defective
i.e., files that have defects
12. Defect-free (Clean)
i.e., files that do not have defects
Review Practice B
What is the difference between code review
practices of defective and clean files?
Review Practice A
VS
Defective
i.e., files that have defects
13. We measure 3 dimensions of review activity metrics
Review Intensity
e.g., #Review Iterations,
Discussion Length
Review Participation
e.g., #Reviewers,
Review Agreement
Reviewing Time
e.g., Review Length,
Code Reading Speed
14. Defect-free (Clean)
i.e., files that do not have defects
Review Practice B
What is the difference between code review
practices of defective and clean files?
Review Practice A
VS
Defective
i.e., files that have defects
15. Defect-free (Clean)
i.e., files that do not have defects
Review Practice B
What is the difference between code review
practices of defective and clean files?
Review Practice A
VS
Defective
i.e., files that have defects
18. Risky Files
Files that have historically been defective
Past Defective
i.e., files that have defects
We investigate defective files along 2 perspectives
19. Risky Files
Files that have historically been defective
Past FutureDefective
i.e., files that have defects
Future-Defective Files
Files that will eventually have defects
We investigate defective files along 2 perspectives
20. Risky Files
Files that have historically been defective
Past FutureDefective
i.e., files that have defectsFuture-Defective Files
Files that will eventually have defects
Conjecture: Reviews of Future-
Defective will be
• less intense,
• with less team participation,
• completed with a shorter time
than reviews of clean files
We investigate defective files along 2 perspectives
23. Future-Defective Files: Files that have post-release defects
VCS
Repositories
Release date Bug-fixing commit
Future-Defective
24. Future-Defective Files: Files that have post-release defects
VCS
Repositories
Release date
No bug-fixing commits
Release date
Bug-fixing commit
Future-Defective
25. Future-Defective Files: Files that have post-release defects
VCS
Repositories
Release date
No bug-fixing commits
Release date
Bug-fixing commit
Future-Defective
Clean
26. Future-Defective Files: Files that have post-release defects
Studied ReviewsVCS
Repositories
Release date
No bug-fixing commits
Release date
Bug-fixing commit
6 months
Future-Defective
Clean
27. Future-Defective Files: Files that have post-release defects
Studied ReviewsVCS
Repositories
Release date
No bug-fixing commits
Release date
Bug-fixing commit
6 months
1,176 Files
3,470 Reviews
10,513 Files
2,727 Reviews
5.0.0
866 Files
2,849 Reviews
11,931 Files
2,690 Reviews
5.1.0
Future-Defective
Clean
28. #Reviewers
#Reviews of Clean files
#Reviewers
#Reviews of Future-Defective files
VS
Review Activity Analysis: Compare code review activity
that has been applied to future-defective and clean files
29. #Reviewers
#Reviews of Clean files
#Reviewers
#Reviews of Future-Defective files
VS
Using a statistical test to determine the difference between
the distributions of code review activity
Review Activity Analysis: Compare code review activity
that has been applied to future-defective and clean files
30. #Reviewers
#Reviews of Clean files
#Reviewers
#Reviews of Future-Defective files
VS
Using a statistical test to determine the difference between
the distributions of code review activity
Raw code review activity metric is
normalized by patch size
Review Activity Analysis: Compare code review activity
that has been applied to future-defective and clean files
31. Findings
Code review activity in
the reviews of future-defective files
Conjecture
Results
Review Intensity
Review Participation
Reviewing Time
Less Intense
Less Team
Participation
Completed with
a shorter time
32. Findings
Code review activity in
the reviews of future-defective files
Conjecture
Less Intense
Results
Review Intensity
Review Participation
Reviewing Time
Less Intense
Less Team
Participation
Completed with
a shorter time
33. Findings
Code review activity in
the reviews of future-defective files
Conjecture
Less Intense
Less Team
Participation
Results
Review Intensity
Review Participation
Reviewing Time
Less Intense
Less Team
Participation
Completed with
a shorter time
34. Findings
Code review activity in
the reviews of future-defective files
Conjecture
Less Intense
Less Team
Participation
Faster Code
Reading Rate
Results
Review Intensity
Review Participation
Reviewing Time
Less Intense
Less Team
Participation
Completed with
a shorter time
35. Defective
i.e., files that have defects
Past
We investigate defective files along 2 perspectives
Risky Files
Files that have historically been defective
FutureFuture-Defective Files
Files that will eventually have defects
Conjecture: Reviews of Future-
Defective will be
• less intense,
• with less team participation,
• completed with a shorter time
than reviews of clean files
36. Defective
i.e., files that have defects
Past
We investigate defective files along 2 perspectives
Risky Files
Files that have historically been defective
FutureFuture-Defective Files
Files that will eventually have defects
Reviews of future-defective files
tend to be less rigorous than
reviews of clean files
37. Defective
i.e., files that have defects
Past
We investigate defective files along 2 perspectives
Risky Files
Files that have historically been defective
FutureFuture-Defective Files
Files that will eventually have defects
Reviews of future-defective files
tend to be less rigorous than
reviews of clean files
38. Defective
i.e., files that have defects
Past
We investigate defective files along 2 perspectives
Risky Files
Files that have historically been defective
Conjecture: Reviews of risky files
should be
• more intense,
• with more team participation,
• reviewed for a longer time
to reduce the risk of having defects
in the future
FutureFuture-Defective Files
Files that will eventually have defects
Reviews of future-defective files
tend to be less rigorous than
reviews of clean files
39. Risky Files: Files that had post-release defects
in prior release
VCS
Repositories
40. Risky Files: Files that had post-release defects
in prior release
VCS
Repositories
Release date
Prior release date
Bug-fixing
commit
41. Risky Files: Files that had post-release defects
in prior release
VCS
Repositories
Release date
Prior release date
Bug-fixing
commit
Risky
42. Risky Files: Files that had post-release defects
in prior release
VCS
Repositories
No bug-fixing commits
Release date
Prior release
date
Release date
Prior release date
Bug-fixing
commit
Risky
43. Risky Files: Files that had post-release defects
in prior release
VCS
Repositories
No bug-fixing commits
Release date
Prior release
date
Release date
Prior release date
Bug-fixing
commit
Normal
Risky
44. Risky Files: Files that had post-release defects
in prior release
Studied ReviewsVCS
Repositories
No bug-fixing commits
Release date
Prior release
date
Release date
Prior release date
Bug-fixing
commit
6 months
Normal
Risky
45. Risky Files: Files that had post-release defects
in prior release
Studied ReviewsVCS
Repositories
No bug-fixing commits
Release date
Prior release
date
Release date
Prior release date
Bug-fixing
commit
6 months
1,168 Files
2,671 Reviews
11,629 Files
2,868 Reviews
5.1.0
Normal
Risky
46. Findings
Code review activity in
the reviews of risky files
Conjecture
Results
Review Intensity
Review Participation
Reviewing Time
More Intense
More Team
Participation
Completed with
a longer time
47. Findings
Code review activity in
the reviews of risky files
Conjecture
Less Intense
Results
Review Intensity
Review Participation
Reviewing Time
More Intense
More Team
Participation
Completed with
a longer time
48. Findings
Code review activity in
the reviews of risky files
Conjecture
Less Intense
Less Team
Participation
Results
Review Intensity
Review Participation
Reviewing Time
More Intense
More Team
Participation
Completed with
a longer time
49. Findings
Code review activity in
the reviews of risky files
Conjecture
Less Intense
Less Team
Participation
Receive Slow
Feedback &
Faster Code
Reading Rate
Results
Review Intensity
Review Participation
Reviewing Time
More Intense
More Team
Participation
Completed with
a longer time
50. Defective
i.e., files that have defects
Past
We investigate defective files along 2 perspectives
FutureFuture-Defective Files
Files that will eventually have defects
Reviews of future-defective files
tend to be less rigorous than
reviews of clean files
Risky Files
Files that have historically been defective
Conjecture: Reviews of risky files
should be
• more intense,
• with more team participation,
• reviewed for a longer time
to reduce the risk of having defects
in the future
51. Defective
i.e., files that have defects
Past
We investigate defective files along 2 perspectives
FutureFuture-Defective Files
Files that will eventually have defects
Reviews of future-defective files
tend to be less rigorous than
reviews of clean files
Risky Files
Files that have historically been defective
Developers are not as careful
when they review risky files.
52. Defective
i.e., files that have defects
Past
We investigate defective files along 2 perspectives
Future
Reviews of future-defective files
tend to be less rigorous than
reviews of clean files
Developers are not as careful
when they review risky files.
Future-Defective Files
Files that will eventually have defects
Risky Files
Files that have historically been defective
53. Defective
i.e., files that have defects
Past
We investigate defective files along 2 perspectives
Future
Reviews of future-defective files
tend to be less rigorous than
reviews of clean files
Developers are not as careful
when they review risky files.
Future-Defective Files
Files that will eventually have defects
Risky Files
Files that have historically been defective
Will careless reviews of risky files lead to future defects?
54. Defective
i.e., files that have defects
Past
We investigate defective files along 2 perspectives
Future
Reviews of future-defective files
tend to be less rigorous than
reviews of clean files
Developers are not as careful
when they review risky files.
Future-Defective Files
Files that will eventually have defects
Risky Files
Files that have historically been defective
Will careless reviews of risky files lead to future defects?
Investigating code review
practice in risky & future-
defective files
56. Risky & Future-Defective Files: Risky files that will
eventually have defects
VCS
Repositories
Bug-fixing commit
Release date
Prior release date
Bug-fixing
commit
57. Risky & Future-Defective Files: Risky files that will
eventually have defects
VCS
Repositories
Bug-fixing commit
Release date
Prior release date
Bug-fixing
commit
Risky & Future-Defective
58. Risky & Future-Defective Files: Risky files that will
eventually have defects
VCS
Repositories
Bug-fixing commit
Release date
Prior release date
Bug-fixing
commit
No bug-fixing
commits
Release datePrior release date
Bug-fixing commit
Risky & Future-Defective
59. Risky & Future-Defective Files: Risky files that will
eventually have defects
VCS
Repositories
Bug-fixing commit
Release date
Prior release date
Bug-fixing
commit
No bug-fixing
commits
Release datePrior release date
Bug-fixing commit
Risky & Clean
Risky & Future-Defective
60. Risky & Future-Defective Files: Risky files that will
eventually have defects
Studied Reviews
VCS
Repositories
Bug-fixing commit
Release date
Prior release date
Bug-fixing
commit
No bug-fixing
commits
Release datePrior release date
Bug-fixing commit
6 months
Risky & Clean
Risky & Future-Defective
61. Risky & Future-Defective Files: Risky files that will
eventually have defects
Studied Reviews
VCS
Repositories
Bug-fixing commit
Release date
Prior release date
Bug-fixing
commit
No bug-fixing
commits
Release datePrior release date
Bug-fixing commit
6 months
206 Files
1,299 Reviews
962 Files
1,372 Reviews
5.1.0
Risky & Clean
Risky & Future-Defective
62. Findings
Code review activity in the reviews of
risky & future-defective files
Conjecture
Less Intense
Less Team
Participation
Receive Slow
Feedback &
Faster Code
Reading Rate
Results
Review Intensity
Review Participation
Reviewing Time
Less Intense
Less Team
Participation
Completed with
a shorter time
63. Defective
i.e., files that have defects
Past
We investigate defective files along 2 perspectives
Future
Reviews of future-defective files
tend to be less rigorous than
reviews of clean files
Developers are not as careful
when they review risky files.
Future-Defective Files
Files that will eventually have defects
Risky Files
Files that have historically been defective
Will careless reviews of risky files lead to future defects?
Investigating code review
practice in risky & future-
defective files
64. Defective
i.e., files that have defects
Past
We investigate defective files along 2 perspectives
Future
Reviews of future-defective files
tend to be less rigorous than
reviews of clean files
Developers are not as careful
when they review risky files.
Future-Defective Files
Files that will eventually have defects
Risky Files
Files that have historically been defective
Reviews of files that are both risky & future defective are less
rigorous than files that are risky but clean
65. Evolvability
e.g., Fixing code comments,
Decomposing complex function
Functionality
e.g., Fixing incorrect
program logic
Traceability
e.g., Updating commit
message
We compare concerns that are addressed during
reviews of defective and clean files
66. Evolvability
Functionality Traceability
Proportion of reviews in future-defective files in Qt5.0.0
82%
40%40%
Reviews of defective files often address
evolvability concernsResults
10% higher than
clean files
5% higher than
clean files
10% lower than
clean files
We observe the similar results for the reviews of risky files and
risky & future-defective files
67.
68. Modern Code Review: A lightweight, tool-supported
code review process
Upstream VCS
repositories
Code change
A lack of code review
activity can increase the
risk of post-release defects
[McIntosh et. al., MSR2014]
My code is awesome!
No needs for a review
Code Review Tool
Code change
How should reviewers do a code
review to reduce the risk of
having defects?
Examine Code
69. Modern Code Review: A lightweight, tool-supported
code review process
Upstream VCS
repositories
Code change
A lack of code review
activity can increase the
risk of post-release defects
[McIntosh et. al., MSR2014]
My code is awesome!
No needs for a review
Code Review Tool
Code change
How should reviewers do a code
review to reduce the risk of
having defects?
Examine Code
Defect-free (Clean)
i.e., files that do not have defects
Review Practice B
What is the difference between code review
practices of defective and clean files?
Review Practice A
VS
Defective
i.e., files that have defects
70. Modern Code Review: A lightweight, tool-supported
code review process
Upstream VCS
repositories
Code change
A lack of code review
activity can increase the
risk of post-release defects
[McIntosh et. al., MSR2014]
My code is awesome!
No needs for a review
Code Review Tool
Code change
How should reviewers do a code
review to reduce the risk of
having defects?
Examine Code
Defect-free (Clean)
i.e., files that do not have defects
Review Practice B
What is the difference between code review
practices of defective and clean files?
Review Practice A
VS
Defective
i.e., files that have defects
We measure 3 dimensions of review activity metrics
Review Intensity
e.g., #Review Iterations,
Discussion Length
Review Participation
e.g., #Reviewers,
Review Agreement
Reviewing Time
e.g., Review Length,
Code Reading Speed
71. Modern Code Review: A lightweight, tool-supported
code review process
Upstream VCS
repositories
Code change
A lack of code review
activity can increase the
risk of post-release defects
[McIntosh et. al., MSR2014]
My code is awesome!
No needs for a review
Code Review Tool
Code change
How should reviewers do a code
review to reduce the risk of
having defects?
Examine Code
Defect-free (Clean)
i.e., files that do not have defects
Review Practice B
What is the difference between code review
practices of defective and clean files?
Review Practice A
VS
Defective
i.e., files that have defects
We measure 3 dimensions of review activity metrics
Review Intensity
e.g., #Review Iterations,
Discussion Length
Review Participation
e.g., #Reviewers,
Review Agreement
Reviewing Time
e.g., Review Length,
Code Reading Speed
Defective
i.e., files that have defects
Past
We investigate defective files along 2 perspectives
Future
Reviews of future-defective files
tend to be less rigorous than
reviews of clean files
Developers are not as careful
when they review risky files.
Future-Defective Files
Files that will eventually have defects
Risky Files
Files that have historically been defective
Reviews of files that are both risky & future defective are less
rigorous than files that are risky but clean
72. Defect-free (Clean)
i.e., files that do not have defects
Review Practice B
What is the difference between code review
practices of defective and clean files?
Review Practice A
VS
Defective
i.e., files that have defects
We measure 3 dimensions of review activity metrics
Review Intensity
e.g., #Review Iterations,
Discussion Length
Review Participation
e.g., #Reviewers,
Review Agreement
Reviewing Time
e.g., Review Length,
Code Reading Speed
Defective
i.e., files that have defects
Past
We investigate defective files along 2 perspectives
Future
Reviews of future-defective files
tend to be less rigorous than
reviews of clean files
Developers are not as careful
when they review risky files.
Future-Defective Files
Files that will eventually have defects
Risky Files
Files that have historically been defective
Reviews of files that are both risky & future defective are less
rigorous than files that are risky but cleanpatanamon-t@is.naist.jp @pamon
Investigating Code Review Practices in Defective Files
Modern Code Review: A lightweight, tool-supported
code review process
Upstream VCS
repositories
Code change
A lack of code review
activity can increase the
risk of post-release defects
[McIntosh et. al., MSR2014]
My code is awesome!
No needs for a review
Code Review Tool
Code change
How should reviewers do a code
review to reduce the risk of
having defects?
Examine Code