Supporting Developers' Coordination in the IDE

Guzzi, Anja; Bacchelli, Alberto; Riche, Yann; Deursen, Arie van

doi:10.1145/2675133.2675177

Cited by 23 publications

(13 citation statements)

References 64 publications

(59 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…• Review -Reviewers have to understand the code changes of all the activities at once [6]- [8]; • Reversion -Developers have to revert all changes of a problematic commit even when only the code change of one activity is problematic [1]; • Integration -Integrators have to merge or reject whole commits, e.g., they will typically reject a code formatting operation and a bug fix included in the same commit [9]; • Historical analysis -Researchers need to associate activities to files to conduct statistical analyses while, e.g., mining software repositories [4].…”

Section: Problem Descriptionmentioning

confidence: 99%

“…Version Control Systems (VCS), such as Git and Subversion, allow programmers to control changes to source code and make it possible to find who made each software change, when, and where. This information is important to support both the coordination of developers working in teams [1] and the creation of many recommendation and prediction systems related to software quality [2].…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Untangling fine-grained code changes

Dias¹,

Bacchelli²,

Gousios³

et al. 2015

2015 IEEE 22nd International Conference on Software Analysis, Evolution, and Reengineering (SANER)

Self Cite

View full text Add to dashboard Cite

After working for some time, developers commit their code changes to a version control system. When doing so, they often bundle unrelated changes (e.g., bug fix and refactoring) in a single commit, thus creating a so-called tangled commit. Sharing tangled commits is problematic because it makes review, reversion, and integration of these commits harder and historical analyses of the project less reliable.Researchers have worked at untangling existing commits, i.e., finding which part of a commit relates to which task. In this paper, we contribute to this line of work in two ways: (1) A publicly available dataset of untangled code changes, created with the help of two developers who accurately split their code changes into self contained tasks over a period of four months;(2) a novel approach, EpiceaUntangler, to help developers share untangled commits (aka. atomic commits) by using fine-grained code change information. EpiceaUntangler is based and tested on the publicly available dataset, and further evaluated by deploying it to 7 developers, who used it for 2 weeks. We recorded a median success rate of 91% and average one of 75%, in automatically creating clusters of untangled fine-grained code changes.

show abstract

Section: Problem Descriptionmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Untangling fine-grained code changes

Dias¹,

Bacchelli²,

Gousios³

et al. 2015

2015 IEEE 22nd International Conference on Software Analysis, Evolution, and Reengineering (SANER)

Self Cite

View full text Add to dashboard Cite

show abstract

“…We grouped the remaining articles (23 articles, 50%) into studies that focus on the programming environments used by professional programmers. The articles show the following types of improvements for programming environments: (i) related to error comprehension [48]- [51]; (ii) in the visualization of codes [52]- [55]; (iii) in the ease of code refactoring [56], [57]; and (iv) the ease of making code changes and maintaining control over changes [58]- [61].…”

Section: B: Programmer Environment For Programmersmentioning

confidence: 99%

Programmer eXperience: A Systematic Literature Review

et al. 2019

View full text Add to dashboard Cite

Programmers use various software development artifacts in their work, such as programming environments, design documents, and programming codes. These software artifacts can be studied and improved based on usability and User eXperience (UX) factors. In this paper, we consider programmers to be a specific case of users and analyze different elements that influence their experience in this specific context. We conducted a systematic literature review of papers published over the last ten years related to 1) the definition of the Programmer eXperience (PX); 2) the PX, UX, and usability factors regarding the programming environments, design documents, and programming codes; and 3) sets of heuristics to evaluate the software development artifacts mentioned before. We analyzed 73 articles, and the results obtained show that: 1) the important elements that influence the PX are the motivation of programmers and the choice of tools they use in their work, such as programming environments; 2) most of the identified studies (59%) aimed to evaluate the influence of the PX, UX, and usability on programming environments; 3) the majority of the studies (70%) used methods such as usability tests and/or heuristic evaluation methods; and 4) four sets of heuristics are used to evaluate software development artifacts in relation to programming environments, programming languages, and application programming interfaces. The results suggest that further research in this area is necessary to better understand and evaluate the concept of the PX.

show abstract

“…In addition to loss of time and money, this causes frustration [9,42]. Studies have shown that these problems can be avoided by following strategies such as effective communication within the team [28], and developing awareness about others' changes that have a potential to incur conflicts [22].…”

Section: Introductionmentioning

confidence: 99%

ConE: A Concurrent Edit Detection Tool for Large-scale Software Development

Maddila

Nagappan

Bird

et al. 2021

ACM Trans. Softw. Eng. Methodol.

Self Cite

View full text Add to dashboard Cite

Modern, complex software systems are being continuously extended and adjusted. The developers responsible for this may come from different teams or organizations, and may be distributed over the world. This may make it difficult to keep track of what other developers are doing, which may result in multiple developers concurrently editing the same code areas. This, in turn, may lead to hard-to-merge changes or even merge conflicts, logical bugs that are difficult to detect, duplication of work, and wasted developer productivity. To address this, we explore the extent of this problem in the pull-request-based software development model. We study half a year of changes made to six large repositories in Microsoft in which at least 1,000 pull requests are created each month. We find that files concurrently edited in different pull requests are more likely to introduce bugs. Motivated by these findings, we design, implement, and deploy a service named Concurrent Edit Detector (ConE) that proactively detects pull requests containing concurrent edits, to help mitigate the problems caused by them. ConE has been designed to scale, and to minimize false alarms while still flagging relevant concurrently edited files. Key concepts of ConE include the detection of the Extent of Overlap between pull requests, and the identification of Rarely Concurrently Edited Files . To evaluate ConE, we report on its operational deployment on 234 repositories inside Microsoft. ConE assessed 26,000 pull requests and made 775 recommendations about conflicting changes, which were rated as useful in over 70% (554) of the cases. From interviews with 48 users, we learned that they believed ConE would save time in conflict resolution and avoiding duplicate work, and that over 90% intend to keep using the service on a daily basis.

show abstract

Supporting Developers' Coordination in the IDE

Cited by 23 publications

References 64 publications

Untangling fine-grained code changes

Untangling fine-grained code changes

Programmer eXperience: A Systematic Literature Review

ConE: A Concurrent Edit Detection Tool for Large-scale Software Development

Contact Info

Product

Resources

About