1. Technical Field
This disclosure relates generally to software development and, in particular, to identifying and managing source code snippets that have been identified as having defects.
2. Background of the Related Art
Software developers utilize integrated development environments (IDEs) to develop and debug software. Prior to the current reliance on such IDEs, software developers needed to use separate and distinct tools for syntax checking their code, compiling, debugging, handling version control, and so forth. Modern software IDEs typically merge all this functionality so that software developers do not see (and need not be distracted by) such separate and distinct tools.
During the development process, software developer teams often collaborate on a set of artifacts, which are typically referred to as “source code.” Using an IDE framework, teams can make changes to these artifacts regularly, and the changes are then shared. To facilitate this process, a team development environment often includes the following software systems: configuration management, version management, change management, as well as build support. The software configuration management (SCM) systems are utilized to manage the artifacts. These systems help developers in many ways, such as tracking the revision history of these artifacts, ensuring that developers have access to appropriate configurations of these artifacts, making developers aware of changes made by others on their team to other source artifacts, helping them obtain these changes in their work environment, and so forth.
Once the developed software is completed and is in use, the change management software is used for software defect tracking. In a typical use case, once a defect (or bug) is reported from a customer (or otherwise), a support escalation path is traversed. At some point within a support matrix (or other defect handling procedure), a defect report is escalated to a support engineer or developer for assistance. When that person (sometimes referred to herein as a user) looks into the issue and finds it to be a valid defect, he or she typically does a code scan (e.g., based on logs gathered from the field) and correlates the results to the flow of how the code logic works or was designed to work. In the event that a particular code snippet is identified to be the cause of a bug, the developer may then address the defect.
While this approach may resolve the particular defect satisfactorily, the defect may not be an isolated issue. There may be many other instances of the code running throughout a set of code (a “codebase”) or in other software systems but where, due to the nature of the defect or due to other reasons, the defect has not been triggered, logged or otherwise noticed. In a typical support organization, the rule of thumb is to correct a defect against the product (or code) it is logged against. As a result, the continued use of the original code in these other systems may give rise to future support issues.
USPTO Backgrounds
USPTO Backgrounds