KR101690075B1 - 로그기반 소스코드파일 이슈도 구현 방법 - Google Patents
로그기반 소스코드파일 이슈도 구현 방법Info
- Publication number
- KR101690075B1 KR101690075B1 KR1020150182044A KR20150182044A KR101690075B1 KR 101690075 B1 KR101690075 B1 KR 101690075B1 KR 1020150182044 A KR1020150182044 A KR 1020150182044A KR 20150182044 A KR20150182044 A KR 20150182044A KR 101690075 B1 KR101690075 B1 KR 101690075B1
- Authority
- KR
- South Korea
- Prior art keywords
- line
- commit
- source code
- issue
- lines
- Prior art date
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/3624—Software debugging by performing operations on the source code, e.g. via a compiler
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3604—Software analysis for verifying properties of programs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/3628—Software debugging of optimised code
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Software Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
본 발명은 소프트웨어의 부작용이 발생한 원인을 파악하고, 발생하는 위치를 예측하기 위해서 소스코드파일의 이슈도를 만들어 참고하여 에러 발생 시 에러 영역을 바로 찾아 빠르게 대응할 수 있는 로그기반 소스코드파일 이슈도 구현 방법에 관한 것으로, 동일한 정보에 대한 여러 버전을 관리하는 저장소인 소스코드 저장소에서 소스코드 추출부가 소스 파일의 로그만 추출하여 분석하기 위한 형태로 변환하는 추출작업을 수행하는 단계; 상기 소스코드 추출부에서 작업단위로 소스코드파일 변경된 내용을 분석하여 이슈도 작성을 위한 정보를 보관하는 분석작업을 소스코드 분석부에서 수행하는 단계; 및 상기 소스코드 분석부에서 분석한 정보를 이용하여 소스코드파일을 라인단위로 이슈도를 표시부에서 표시하도록 하는 보고작업을 소스코드 보고부에서 수행하는 단계;를 포함하여 이루어지는 것을 특징으로 하는 로그기반 소스코드파일 이슈도 구현 방법을 제공한다.
Description
본 발명은 소스코드파일의 이슈도 구현에 관한 것으로, 더욱 상세하게는 소프트웨어의 부작용이 발생한 원인을 파악하고, 발생하는 위치를 예측하기 위한 소스코드파일 이슈도 구현 방법에 관한 것이다.
SW를 개발하는 현장에서 새로운 기능을 추가하거나 이슈(bug)를 해결하기 위해 소스코드를 수정하였는데, 전혀 예상치 못 한 심각한 부작용(side effect)이 종종 발생한다.
개발자가 부작용 발생 위치를 미리 알 수 있다면 부작용을 고려하여 수정하면 소프트웨어(SW) 제품의 안정성이 향상될 수 있다. 또한 부작용을 예측하면 디버깅 시간을 줄일 수 있어 소프트웨어(SW) 제품 생산성을 향상시킬 수 있을 것이다
본 발명은 상기와 같은 종래 기술의 문제점을 해결하기 위한 것으로, 본 발명은 소프트웨어의 부작용이 발생한 원인을 파악하고, 발생하는 위치를 예측하기 위해서 소스코드파일의 이슈도를 만들어 참고하여 에러 발생 시 에러 영역을 바로 찾아 빠르게 대응할 수 있는 로그기반 소스코드파일 이슈도 구현 방법을 제공하는데 그 목적이 있다.
상기한 목적을 달성하기 위하여 본 발명 로그기반 소스코드파일 이슈도 구현 방법은 동일한 정보에 대한 여러 버전을 관리하는 저장소인 소스코드 저장소에서 소스코드 추출부가 소스 파일의 로그만 추출하여 분석하기 위한 형태로 변환하는 추출작업을 수행하는 단계; 상기 소스코드 추출부에서 작업단위로 소스코드파일 변경된 내용을 분석하여 이슈도 작성을 위한 정보를 보관하는 분석작업을 소스코드 분석부에서 수행하는 단계; 및 상기 소스코드 분석부에서 분석한 정보를 이용하여 소스코드파일을 라인단위로 이슈도를 표시부에서 표시하도록 하는 보고작업을 소스코드 보고부에서 수행하는 단계;를 포함하여 이루어지는 것을 특징으로 한다.
여기서 소스코드 추출부가 소스 파일의 로그만 추출하여 분석하기 위한 형태로 변환하는 추출작업을 수행하는 단계에서 추출되는 데이터 구조는, 변경한 작업을 상기 소스코드 저장소에 기록하는 행위인 커밋(commit)에 대한 정보를 리스트로 보관하는 커밋들(commits)로써, 상기 커밋들을 구성하는 커밋은, 상기 커밋을 구분하기 위한 ID인 커밋 키값(commit hash 값)이 부여되고, 상기 각각의 커밋은, 커밋 시작을 표시하는 정보로서 커밋(commit) 값(해쉬값)을 표시하는 커밋 헤더(commit header)와, 상기 소스코드저장소(SCM)에 변경한 정보를 커밋(보관)하기 위해 남기는 메모인 커밋 메시지(commit message)와, 소스코드파일에서 변경한 작업의 일부분인 청크(chunk)와, 상기 청크(chunk) 시작위치 정보인 청크 헤더(chunk header)로 한다.
한편 소스코드 분석부에서 분석완료 후 생성되는 출력 데이터는 상기 소스코드 보고부에서 소스코드파일을 라인단위로 보고하도록 해당 라인의 커밋키값들과 해당 커밋과 연관된 이슈들을 보관하는 라인을 리스트로 보관하며, 상기 해당 라인의 커밋 키값들과 커밋과 연관된 이슈들(issues)을 리스트로 보관하되 연관된 이슈가 없으면 이슈들(issues)는 길이(length)가 0인 리스트이며, 상기 라인(line)을 라인들(lines) 리스트로 보관하는 것을 특징으로 한다.
그리고 분석단계에서 상기 청크(chunk) 정보에서 라인이 삭제된 경우 삭제된 해당 라인 번호(line_no)를 키값으로, 라인들(lines)에서 해당 라인의 라인(line) 정보를 임시로 보관하고, 상기 청크(chunk) 정보에서 라인이 삭제 및 추가된 경우 삭제 라인들(deleted_lines)에 보관된 정보를 참고하여 삭제된 라인과 추가되는 라인이 같은 경우, 삭제된 라인의 라인(line) 정보에 추가된 라인의 라인(line) 정보를 첨부(append)하는 것을 특징으로 한다.
또한 소스코드 추출부의 추출작업 단계는, 소스코드저장소(SCM)에서 소스코드 이슈도를 확인하려는 해당 소스코드파일에 대한 로그 및 변경 내용을 커밋(commit)단위로 커밋들(commits)에 보관하는 단계와, 커밋(commit) 순서를 위해서 시간순으로 정렬하는 단계를 포함하여 이루어지는 것을 특징으로 한다.
여기서, 소스코드 분석부의 분석 방법은, 커밋(commit) 라인의 끝인가를 판단하여 끝이면 분석 단계를 종료하고, 커밋 라인의 끝이 아니라면, 커밋(작업) 헤더(commit header)인가를 판단하여 상기 커밋 헤더이면 커밋값(commit hash 값)을 상기 커밋(commit)에 보관하고, 이슈들(issues) 리스트를 초기화하는 단계, 변경 내용 청크(chunk : 범위) 안쪽이라면서 라인추가이면, add_line() 서브함수를 호출하여 해당 라인번호의 라인들(lines) 리스트에 커밋, 이슈(commit, issues)를 append(추가)하는 단계, 변경 내용 범위(chunk) 안쪽이고(S230), 라인추가가 아니라면 라인 삭제인가를 판단하여(S260) 라인 삭제이면, del_line() 서브함수를 호출하여 deleted_lines에 해당 라인번호(line_no)를 키로, 해당 라인정보(line)을 값으로 보관하고, 라인들(lines) 리스트에서 해당 라인(line) 정보를 삭제하는 단계, 커밋 메시지(commit message) 영역에서 이슈가 발견되었는가를 판단하여 모든 이슈들을 이슈들(issues) 리스트에 append(추가)하고, 발견된 이슈가 변경내용범위 헤더(chunk header) 이면, 상기 청크 헤더(chunk header)에서 필요한 정보들을 보관하고, 새로운 청크(chunk)를 반영하기 위해서 deleted_lines를 클리어(clear)하는 단계, line_no를 하나 증가 후 커밋(commit)의 다음 라인을 조사하는 단계를 포함하여 이루어지는 것을 특징으로 한다.
한편, 라인 추가 방법은 deleted_lines에서 현재 line_no에 해당하는 key가 존재하면, 상기 deleted_lines에서 상기 line_no에 해당하는 값을 라인(line)에 보관 후 분석단계에서 전달받은 커밋, 이슈들(commit, issues)를 라인(line)에 추가(append)하고, 상기 deleted_lines에서 상기 line_no에 해당하는 값을 제거(삭제)하고, 상기 deleted_llines에서 현재 line_no에 해당하는 key가 없으면, 분석단계에서 전달받은 커밋, 이슈들(commit, issues)을 라인(line)에 보관하는 단계; 라인들(lines) 리스트 길이가 line_no 보다 작다면, 상기 라인(line)을 라이들(lines) 리스트에 append(추가)하고, 상기 라인들(lines) 리스트 길이가 line_no 보다 작지 않으면, 상기 라인들(lines) 리스트의 line_no - 1 위치에 라인(line)을 insert(삽입)하는 단계를 더 포함하여 이루어지는 것을 특징으로 한다.
그리고 라인 삭제 방법은 상기 라인들(lines) 리스트 길이가 line_no와 크거나 같은가에 따라 라인들(lines) 리스트 길이가 line_no 보다 작으면 종료하고, 라인들(lines) 리스트 길이가 line_no와 크거나 같다면 deleted_lines 보관을 위해 필요한 정보를 설정 및 사전작업을 하되, 라인들(lines) 리스트에서 line_no - 1에 해당하는 값을 라인(line)에 보관하고, 라인들(lines) 리스트에서 line_no - 1에 해당하는 값을 삭제하며, line_no를 deleted_line_no에 보관하는 단계, deleted_line_no가 deleted_lines에 존재하는 키이면, 상기 deleted_line_no를 계속 증가하면서 존재하지 않는 키가 발견될 때까지 반복하는 단계, 라인(line) 값을 deleted_lines 에 deleted_line_no 키로 보관하는 단계 및 상기 분석단계에서 청크(chunk) 분석할 때 라인번호 일관성을 유지하기 위해서 line_no를 감소하는 단계를 포함하여 이루어지는 것을 특징으로 한다.
한편 소스코드 보고부의 보고 단계는 소스코드라인과 이슈도 출력을 위해 필요한 정보를 초기화하는 단계, 파일의 끝인가를 판단하여 파일의 끝이면 상기 소스코드파일을 닫고 소스코드파일 전체 이슈도를 total_issue_percentage = total_issues의 개수 / total_commits의 개수 * 100 으로 계산한다하고, 상기 total_issue_percentage, total_issues의 개수, total_commits의 개수를 상기 표시부 화면에 출력하고, 파일의 끝이 아니라면 소스코드 라인단위 commit 개수와 issue 개수를 계산하기 위해 필요한 정보를 초기화하는 단계, 해당 라인에 커밋(commit)이 존재한다면, commit_count를 증가시키고, 해당 커밋(commit)과 연관된 모든 이슈 개수만큼 issue_count를 증가하는 단계, 커밋(commit)을 total_commits에 존재하지 않으면 추가하고, 커밋(commit)과 관련된 모든 이슈도 total_issues에 존재하지 않는 이슈들 모두 추가하고, 해당 라인에 커밋(commit)이 더 이상 존재하지 않는다면, 현재 라인의 이슈도를 issue_percentage = issue_count / commit_count * 100 를 이용하여 계산하고, issue_percentage, issue_count, commit_count, line_no, 소스코드 해당 라인 내용을 상기 표시부의 화면에 출력하는 단계, 소스파일의 다음 라인을 조사하기 위해 소스파일의 다음 라인으로 이동하고 line_no도 증가시키는 단계를 포함하여 이루어지는 것을 특징으로 한다.
본 발명은 다음과 같은 효과가 있다.
첫째, 소스코드파일의 이슈도를 참고하면 부작용(side effect)을 예측하여 안전성 높은 소스코드 작성할 수 있어 소프트웨어 제품 안정성을 향상할 수 있다.
둘째, 에러가 발생한 경우 소스코드파일의 이슈도를 참고하면 해당 에러 영역을 바로 찾을 수 있어 빠르게 대응할 수 있어 소프트웨어 제품 개발 생산성을 향상할 수 있다.
셋째, 소프트웨어 부작용을 예측하고 오류에 빠르게 대응하여 소프트웨어 품질을 향상할 수 있다.
도 1은 본 발명에 따른 로그기반 소스코드파일 이슈도 구현 흐름을 설명하기 위한 도면이다.
도 2는 본 발명에 따른 로그기반 소스코드파일 이슈도 구현을 위한 데이터 구조 중 커밋들(commits)을 설명하기 위한 도면이다.
도 3은 도 2에 나타낸 커밋(commit)을 상세히 나타낸 도면이다.
도 4는 도 2 및 도 3에 나타낸 커밋들(commits)과 커밋(commit)의 관계를 나타낸 도면이다.
도 5는 본 발명에 따른 로그기반 소스코드파일 이슈도 구현 흐름에서 분석단계에서 생성되는 출력 데이터를 설명하기 위한 도면이다.
도 6은 본 발명에 따른 로그기반 소스코드파일 이슈도 구현 흐름에서 분석단계에서 생성되는 데이터를 설명하기 위한 도면이다.
도 7은 도 6에 나타낸 커밋과 연관된 이슈들을 리스트로 나타낸 도면이다.
도 8은 도 5와 도 6에 나타낸 라인들(lines)과 라인(line)의 관계를 설명하기 위한 도면이다.
도 9는 도 1에 나타낸 로그기반 소스코드파일 이슈도 구현 흐름에서 분석단계에서 사용하는 해쉬/Dictionary 형태의 데이터를 설명하기 위한 도면이다.
도 10은 도 1에 나타낸 로그기반 소스코드파일 이슈도 구현 흐름에서 추출 방법을 설명하기 위한 흐름도이다.
도 11은 도 1에 나타낸 로그기반 소스코드파일 이슈도 구현 흐름에서 분석 방법을 설명하기 위한 흐름도이다.
도 12는 도 11에 나타낸 분석 단계의 서브 기능 중 하나인 라인 추가 방법을 설명하기 위한 흐름도이다.
도 13은 도 11에 나타낸 분석 단계의 서브 기능 중 하나인 삭제 방법을 설명하기 위한 흐름도이다.
도 14는 도 1에 나타낸 로그기반 소스코드파일 이슈도 구현 흐름에서 보고 방법을 설명하기 위한 흐름도이다.
도 15는 본 발명에 따른 로그기반 소스코드파일 이슈도 구현 예 및 활용을 설명하기 위한 도면이다.
도 16은 도 15에 나타낸 로그기반 소스코드파일 이슈도에서 11번째 라인의 커밋과 이슈의 히스토리를 설명하기 위한 도면이다.
도 2는 본 발명에 따른 로그기반 소스코드파일 이슈도 구현을 위한 데이터 구조 중 커밋들(commits)을 설명하기 위한 도면이다.
도 3은 도 2에 나타낸 커밋(commit)을 상세히 나타낸 도면이다.
도 4는 도 2 및 도 3에 나타낸 커밋들(commits)과 커밋(commit)의 관계를 나타낸 도면이다.
도 5는 본 발명에 따른 로그기반 소스코드파일 이슈도 구현 흐름에서 분석단계에서 생성되는 출력 데이터를 설명하기 위한 도면이다.
도 6은 본 발명에 따른 로그기반 소스코드파일 이슈도 구현 흐름에서 분석단계에서 생성되는 데이터를 설명하기 위한 도면이다.
도 7은 도 6에 나타낸 커밋과 연관된 이슈들을 리스트로 나타낸 도면이다.
도 8은 도 5와 도 6에 나타낸 라인들(lines)과 라인(line)의 관계를 설명하기 위한 도면이다.
도 9는 도 1에 나타낸 로그기반 소스코드파일 이슈도 구현 흐름에서 분석단계에서 사용하는 해쉬/Dictionary 형태의 데이터를 설명하기 위한 도면이다.
도 10은 도 1에 나타낸 로그기반 소스코드파일 이슈도 구현 흐름에서 추출 방법을 설명하기 위한 흐름도이다.
도 11은 도 1에 나타낸 로그기반 소스코드파일 이슈도 구현 흐름에서 분석 방법을 설명하기 위한 흐름도이다.
도 12는 도 11에 나타낸 분석 단계의 서브 기능 중 하나인 라인 추가 방법을 설명하기 위한 흐름도이다.
도 13은 도 11에 나타낸 분석 단계의 서브 기능 중 하나인 삭제 방법을 설명하기 위한 흐름도이다.
도 14는 도 1에 나타낸 로그기반 소스코드파일 이슈도 구현 흐름에서 보고 방법을 설명하기 위한 흐름도이다.
도 15는 본 발명에 따른 로그기반 소스코드파일 이슈도 구현 예 및 활용을 설명하기 위한 도면이다.
도 16은 도 15에 나타낸 로그기반 소스코드파일 이슈도에서 11번째 라인의 커밋과 이슈의 히스토리를 설명하기 위한 도면이다.
본 발명의 바람직한 실시 예를 첨부된 도면에 의하여 상세히 설명하면 다음과 같다.
아울러, 본 발명에서 사용되는 용어는 가능한 한 현재 널리 사용되는 일반적인 용어를 선택하였으나, 특정한 경우는 출원인이 임의로 선정한 용어도 있으며 이 경우는 해당되는 발명의 설명부분에서 상세히 그 의미를 기재하였으므로, 단순한 용어의 명칭이 아닌 용어가 가지는 의미로서 본 발명을 파악하여야 함을 밝혀두고자 한다. 또한 실시예를 설명함에 있어서 본 발명이 속하는 기술 분야에 익히 알려져 있고, 본 발명과 직접적으로 관련이 없는 기술 내용에 대해서는 설명을 생략한다. 이는 불필요한 설명을 생략함으로써 본 발명의 요지를 흐리지 않고 더욱 명확히 전달하기 위함이다.
도 1은 본 발명에 따른 로그기반 소스코드파일 이슈도 구현 흐름을 설명하기 위한 도면이다.
본 발명에 따른 로그기반 소스코드파일 이슈도 구현 흐름은 도 1에 나타낸 바와 같은데, 소스코드 저장소(100)에서 소스코드를 추출하고, 분석하여, 보고하도록 되어 있다.
이를 위하여 소스코드를 추출하는 소스코드 추출부(210)와, 소스코드를 분석하는 소스코드 분석부(220) 및 소스코드를 보고하는 소스코드 보고부(230)로 구성된다. 이러한 소스코드 추출부(210), 소스코드 분석부(220) 및 소스코드 보고부(230)는 PC 또는 서버로 구현할 수 있다.
소스코드 추출부(210)는 소스코드 저장소(100)에서 해당 소스 파일의 로그만 추출하여 분석하기 위한 형태로 변환하는 추출작업을 수행한다.
소스코드 분석부(220)는 소스코드 추출부(210)에서 작업단위로 소스코드파일 변경된 내용을 분석하여 이슈도 작성을 위한 정보를 보관하는 분석작업을 수행한다.
소스코드 보고부(230)는 소스코드 분석부(220)에서 분석한 정보를 이용하여 소스코드파일 라인단위로 이슈도를 표시부(300)에서 표시하도록 하는 보고작업을 수행한다.
여기서 소스코드저장소(SCM)는 동일한 정보에 대한 여러 버전을 관리하는 저장소이다.
참고로 본 발명을 상세히 설명하기에 앞서 본 발명에서 사용되는 용어들을 정리하면, 커밋(commit)은 변경한 작업을 저장소에 기록하는 행위이다.
커밋 키값(commit hash 값)은 커밋을 구분하기 위한 ID 이다.
커밋 헤더(commit header)는 커밋 시작을 표시하는 정보로서 commit 값(해쉬값)을 표시한다.
커밋 메시지(commit message)는 소스코드저장소(SCM)에 변경한 정보를 커밋하기 위해 남기는 메모이다.
diff는 변경작업 전과 변경작업 후 차이이다.
청크(chunk)는 소스코드파일에서 변경한 작업의 일부분이다.
그리고 청크 헤더(chunk header)는 청크(chunk) 시작위치 정보이다.
도 2는 본 발명에 따른 로그기반 소스코드파일 이슈도 구현을 위한 데이터 구조 중 커밋들(commits)을 나타낸 도면이고, 도 3은 도 2에 나타낸 커밋(commit)을 상세히 나타낸 도면이며, 도 4는 도 2 및 도 3에 나타낸 커밋들(commits)과 커밋(commit)의 관계를 나타낸 도면이다.
본 발명에 따른 로그기반 소스코드파일 이슈도 구현을 위한 데이터 구조들 중 도 2에 나타낸 커밋들은 커밋에 대한 정보를 리스트로 보관하는데, 도 1에 나타낸 소스코드저장소에서의 추출단계 완료 후 생성되는 최종 출력 데이터로서 분석단계의 입력데이터이다.
그리고 도 3에 나타낸 커밋은 커밋과 관련된 정보들을 보관한다.
앞에서 설명한 바와 같이, 커밋과 관련된 정보들을 다시 한 번 설명하면 커밋 키값(commit hash 값)은 커밋 구분하기 위한 ID 이고, 커밋 헤더(commit header)는 커밋 시작을 표시하는 정보로서 commit 값(해쉬값)을 표시하며, 커밋 메시지(commit message)는 소스코드저장소(SCM)에 변경한 정보를 커밋(보관)하기 위해 남기는 메모이고, diff는 변경작업 전과 변경작업 후 차이이며, 청크(chunk)는 소스코드파일에서 변경한 작업의 일부분이다. 그리고 청크 헤더(chunk header)는 청크(chunk) 시작위치 정보이다.
도 5는 도 1에 나타낸 로그기반 소스코드파일 이슈도 구현 흐름에서 분석단계 완료 후 생성되는 출력 데이터를 설명하기 위한 도면이다.
도 1에 나타낸 로그기반 소스코드파일 이슈도 구현 흐름에서 분석단계 완료 후 생성되는 출력 데이터는 도 5에 나타낸 바와 같은데, 해당 라인의 커밋키값들과 해당 커밋과 연관된 이슈들을 보관하는 라인을 리스트로 보관한다.
도 6은 본 발명에 따른 로그기반 소스코드파일 이슈도 구현 흐름에서 분석단계에서 생성되는 출력 데이터를 설명하기 위한 도면이다.
본 발명에 따른 로그기반 소스코드파일 이슈도 구현 흐름에서 분석단계에서 생성되는 출력 데이터는 도 6에 나타낸 바와 같이, 해당 라인의 커밋 키값들과 커밋과 연관된 이슈들(issues)을 리스트로 보관한다.
도 7은 도 6에 나타낸 커밋과 연관된 이슈들을 리스트로 나타낸 도면이다.
도 6에 나타낸 커밋과 관련된 리슈들을 리스트로 보관하는데, 연관된 이슈가 없으면 이슈들(issues)는 길이(length)가 0인 리스트이다.
도 8은 도 5와 도 6에 나타낸 라인들(lines)과 라인(line)의 관계를 설명하기 위한 도면이다.
도 5에 나타낸 라인들과 도 6에 나타낸 라인의 관계는 도 8에 나타낸 바와 같은데 도 4에 나타낸 커밋들과 커밋의 관계와 비슷하게 라인들은 라인을 리스트로 보관한다.
도 9는 도 1에 나타낸 로그기반 소스코드파일 이슈도 구현 흐름에서 분석단계에서 사용하는 해쉬/Dictionary 형태의 데이터를 설명하기 위한 도면이다.
도 1에 나타낸 로그기반 소스코드파일 이슈도 구현 흐름에서 분석단계에서 사용하는 해쉬/Dictionary 형태의 데이터는 도 9에 나타낸 바와 같은데, 청크(chunk) 정보에서 라인이 삭제된 경우 삭제된 해당 라인 번호(line_no)를 키값으로, lines에서 해당 라인의 line 정보를 임시로 보관한다.
그리고 청크(chunk) 정보에서 라인이 삭제 및 추가된 경우 삭제 라인들(deleted_lines)에 보관된 정보를 참고한다.
삭제된 라인과 추가되는 라인이 같은 경우, 삭제된 라인의 line 정보에 추가된 라인의 line 정보를 첨부(append)한다.
여기서, line_no는 분석단계에서 청크(chunk) 정보를 해석할 때 사용하는 데이터이다. 해당 라인번호를 보관하며, 청크 헤더(chunk header)를 발견할 때마다 chunk_new_line - 1(첫 번째 라인번호는 1) 값으로 설정한다.
그리고 chunk_new_line은 커밋(commit)을 통해 변경되는 청크(chunk)의 라인번호이다. 아래의 청크 헤더(chunk header)에서 "1"이 해당 청크(chunk)에서 변경(영향)되는 시작 라인번호이다.
@@ -0,0 +1,7 @@ ---> chunk_new_line = 1 이다.
한편 chunk_new_range는 커밋(commit)을 통해 변경되는 청크(chunk)의 영향 범위로서, chunk_new_line부터 라인 수이다.
아래의 청크 헤더(chunk header)에서 "7"이 chunk_new_range에 설정이 되며, 청크(chunk)에서 변경(영향) 범위는 라인번호 1부터 라인번호 7까지이다.
@@ -0,0 +1,7 @@ ---> chunk_new_range = 7 이다.
도 10은 도 1에 나타낸 로그기반 소스코드파일 이슈도 구현 흐름에서 추출 방법을 설명하기 위한 흐름도이다.
도 1에 나타낸 로그기반 소스코드파일 이슈도 구현 흐름에서 추출 방법은 도 10에 나타낸 바와 같이, 소스코드저장소(SCM)에서 소스코드 이슈도를 확인하려는 해당 소스코드파일에 대한 로그 및 변경 내용을 커밋(commit)단위로 커밋들(commits)에 보관한다(S100).
이때, 커밋(commit) 순서는 분석단계의 알고리즘을 단순화하기 위해서 시간순으로 정렬한다(S110). 참고로 커밋들과 커밋의 데이터 구조는 도 2 내지 도 4와 같이 구성된다.
도 11은 도 1에 나타낸 로그기반 소스코드파일 이슈도 구현 흐름에서 분석 방법을 설명하기 위한 흐름도이다.
도 1에 나타낸 로그기반 소스코드파일 이슈도 구현 흐름에서 분석 방법은 추출 단계에서 생성한 커밋들(commits)의 모든 커밋(commit)에 대해 각각 분석단계를 수행하는데 우선, 도 11에 나타낸 바와 같이, 커밋(commit) 라인의 끝인가를 판단한다(S200).
판단결과(S200) 커밋 라인의 끝이면 분석 단계를 종료한다.
그러나 커밋 라인의 끝이 아니라면, 커밋(작업) 헤더(commit header)인가를 판단한다(S210).
판단결과(S210) 커밋 헤더이면 커밋값(commit hash 값)을 커밋(commit)에 보관하고, 이슈들(issues) 리스트를 초기화한다(S220). 이때, 도 3의 커밋 헤더에서 커밋값은 "2e0f9db3eec051322e10fe31ea4adc8ade4b7b29"로 되어 있다.
그 다음 변경 내용 청크(chunk : 범위) 안쪽인가를 판단하여(S230), 안쪽이라면 라인 추가인가를 판단하고(S240), 라인추가이면, add_line() 서브함수를 호출하여 해당 라인번호의 lines 리스트에 커밋, 이슈(commit, issues)를 append(추가)한다(S250). 이때, add_line() 서브함수의 자세한 알고리즘은 후술하는 도 12에서 상세히 설명하기로 한다.
그러나 변경 내용 범위(chunk) 안쪽이고(S230), 라인 추가인가 판단결과(S240), 라인추가가 아니라면 라인 삭제인가를 판단하여(S260) 라인 삭제이면, del_line() 서브함수를 호출하여 deleted_lines에 해당 라인번호(line_no)를 키로, 해당 라인정보(line)을 값으로 보관한다(S270). 그 후 lines 리스트에서 해당 라인정보(line)을 삭제한다. 이러한 del_line() 서브함수의 자세한 알고리즘은 후술하는 도 13에서 상세히 설명하기로 한다.
그 다음 도 3의 커밋 메시지(commit message) 영역에서 이슈가 발견되었는가를 판단한다(S280).
판단결과(S280) 정규표현식으로 검색하여 발견하면, 모든 이슈들을 issues 리스트에 append(추가)한다(S290).
이어서 발견된 이슈가 변경내용범위 헤더(chunk header) 이면(S300), 청크 헤더(chunk header)에서 필요한 정보들을 보관하고, 새로운 청크(chunk)를 반영하기 위해서 deleted_lines를 클리어(clear)한다(S310). 이때, 청크 헤더(chunk header)에서 설정하는 정보들은 chunk_new_line = 해당 chunk에서 변경 시작 라인번호, chunk_new_range = 해당 chunk에서 변경 시작 라인부터의 라인 수, line_no = chunk_new_line - 1 이다.
그 다음 line_no를 하나 증가 후(S320) 커밋(commit)의 다음 라인을 조사를 위해 이동한다.
도 12는 도 11에 나타낸 분석 단계의 서브 기능 중 하나인 라인 추가 방법을 설명하기 위한 흐름도이다.
도 11에 나타낸 분석 단계의 서브 기능 중 하나인 라인 추가 방법은 도 12에 나타낸 바와 같이 분석단계의 서브 기능으로서, deleted_lines에서 현재 line_no에 해당하는 key가 존재하는지를 판단한다(S400).
판단결과(S400) 존재하면, deleted_lines에서 line_no에 해당하는 값을 라인(line)에 보관 후 분석단계에서 전달받은 커밋, 이슈들(commit, issues)를 라인(line)에 추가(append)한다. 그리고 deleted_lines에서 line_no에 해당하는 값을 제거(삭제)한다(S410). 의사코드로 표현하면 아래와 같다.
line = deleted_lines[line_no]
line.append((commit, issues))
del(deleted_lines[line_no])
그러나 판단결과(S400), deleted_lines에서 현재 line_no에 해당하는 key가 없으면, 분석단계에서 전달받은 커밋, 이슈들(commit, issues)을 라인(line)에 보관한다(S420).
그 다음 라인들(lines) 리스트 길이가 line_no 보다 작은가를 판단한다(S430).
판단결과(S430) 작다면, 라인(line)을 라이들(lines) 리스트에 append(추가)한다(S440).
그러나 판단결과(S430) 라인들(lines) 리스트 길이가 line_no 보다 작지 않으면, 라인들(lines) 리스트의 line_no - 1 위치에 라인(line)을 insert(삽입)한다(S450).
도 13은 도 11에 나타낸 분석 단계의 서브 기능 중 하나인 삭제 방법을 설명하기 위한 흐름도이다.
도 11에 나타낸 분석 단계의 서브 기능 중 하나인 삭제 방법은 도 13에 나타낸 바와 같이, 라인들(lines) 리스트 길이가 line_no와 크거나 같은가를 판단한다(S500).
판단결과(S500) 라인들(lines) 리스트 길이가 line_no 보다 작으면 종료한다.
그러나 판단결과(S500) 라인들(lines) 리스트 길이가 line_no와 크거나 같다면 deleted_lines 보관을 위해 필요한 정보를 설정 및 사전작업을 하는데, 라인들(lines) 리스트에서 line_no - 1에 해당하는 값을 라인(line)에 보관하고, 라인들(lines) 리스트에서 line_no - 1에 해당하는 값을 삭제하며, line_no를 deleted_line_no에 보관한다(S510).
그리고 deleted_line_no가 deleted_lines에 존재하는 키이면(S520), deleted_line_no를 계속 증가하면서 존재하지 않는 키가 발견될 때까지 반복한다(S530).
그 다음 라인(line) 값을 deleted_lines 에 deleted_line_no 키로 보관한다(S540).
이어 분석단계에서 청크(chunk) 분석할 때 라인번호 일관성을 유지하기 위해서 line_no를 감소한다(S550).
도 14는 도 1에 나타낸 로그기반 소스코드파일 이슈도 구현 흐름에서 보고 방법을 설명하기 위한 흐름도이다.
도 1에 나타낸 로그기반 소스코드파일 이슈도 구현 흐름에서 보고 방법은 도 14에 나타낸 바와 같은데, 분석단계의 결과인 lines 리스트와 소스코드파일을 오픈하여 라인단위 이슈도를 계산하여 리포팅한다.
우선, 해당 소스코드라인과 이슈도 출력을 위해 필요한 정보를 초기화한다(S600). 이러한 초기화에는, line_no를 0으로 초기화, total_commits 리스트 초기화, total_issues 리스트 초기화 및 소스코드파일 오픈 이 있다.
그 다음 파일의 끝인가를 판단한다(S610).
판단결과(S610), 파일의 끝이면 소스코드파일을 닫고 소스코드파일 전체 이슈도를 total_issue_percentage = total_issues의 개수 / total_commits의 개수 * 100 으로 계산한다(S620).
그 다음 total_issue_percentage, total_issues의 개수, total_commits의 개수를 화면에 출력한다(S630).
그러나 판단결과(S610), 파일의 끝이 아니라면 소스코드 라인단위 commit 개수와 issue 개수를 계산하기 위해 필요한 정보를 초기화한다(S640). 즉 commit_count = 0, issue_count = 0.
이어서 해당 라인에 커밋(commit)이 더 이상 존재하지 않는가를 판단한다(S650).
판단결과(S650) 해당 라인에 커밋(commit)이 존재한다면, commit_count를 증가시키고, 해당 commit과 연관된 모든 이슈 개수만큼 issue_count를 증가한다(S660).
이어서 커밋(commit)을 total_commits에 존재하지 않으면 추가하고, commit과 관련된 모든 이슈도 total_issues에 존재하지 않는 이슈들 모두 추가한다(S670).
판단결과(S650) 해당 라인에 커밋(commit)이 더 이상 존재하지 않는다면, 현재 라인의 이슈도를 issue_percentage = issue_count / commit_count * 100 를 이용하여 계산한다(S680)
이어 issue_percentage, issue_count, commit_count, line_no, 소스코드 해당 라인 내용을 화면에 출력한다(S690).
그리고 소스파일의 다음라인을 조사하기 위해 소스파일의 다음 라인으로 이동하고 line_no도 증가한다(S700).
도 15는 본 발명에 따른 로그기반 소스코드파일 이슈도 구현 예 및 활용 예를 설명하기 위한 도면이다.
본 발명에 따른 로그기반 소스코드파일 이슈도 구현 예 및 활용 예는 도 15에 나타낸 바와 같은데, 소스코드파일 이슈도를 확인하면 11번째 라인은 4번커밋(commit)에서 3개의 이슈(issue)가 발생한 것을 알 수 있다. 그래서 해당 소스코드파일 이슈도를 확인한 개발자는 11번째 라인을 수정할 때 기존에 발생한 issue를 상기하여 안정화된 소스코드를 작성할 수 있다.
마지막 라인은 전체 소스코드파일의 이슈도(30.00%), 전체 발생한 issue 개수(3), 전체 commit 개수(10)이다.
또한 특정 모듈에 속한 모든 소스코드파일의 전체 이슈도를 조사하면 소스코드파일 단위로 이슈도를 알 수 있다.
어떤 모듈에 이슈가 발생하였는데, 어느 소스코드파일부터 확인을 해야 할 지 쉽게 결정할 수 있어 디버깅할 때 많은 시간을 절약할 수 있다.
소스코드파일일 결정되면 해당 소스코드파일의 이슈도를 확인하여 이슈도가 높은 곳부터 확인하면 많은 시간을 절약할 수 있어 SW 품질향상 시간을 단축시킬 수 있다.
도 16은 도 15에 나타낸 로그기반 소스코드파일 이슈도에서 11번째 라인의 커밋과 이슈의 히스토리를 설명하기 위한 도면이다.
소스코드파일 이슈도에서 해당 라인의 커밋 및 이슈 추적은 소스코드파일 이슈도에서 11 번째 라인의 커밋과 이슈의 히스토리를 용이하게 확인할 수 있는데, 11번째 라인이 존재하기까지 작업한 커밋들은 98b8d1c5, 2c5aadbc, 18a626cd, 0792eef6 이다. 11번째 라인이 존재하기까지 작업한 커밋들과 연관된 이슈들은 1111, 222, 3333 이다.
위의 정보들을 이용하면 소스코드파일과 관련된 커밋들 및 이슈들을 추적할 때 많은 시간을 절약할 수 있다.
본 발명을 첨부된 도면과 함께 설명하였으나, 이는 본 발명의 요지를 포함하는 다양한 실시 형태 중의 하나의 실시예에 불과하며, 당업계에서 통상의 지식을 가진 자가 용이하게 실시할 수 있도록 하는 데에 그 목적이 있는 것으로, 본 발명은 상기 설명된 실시예에만 국한되는 것이 아님은 명확하다. 따라서, 본 발명의 보호범위는 하기의 청구범위에 의해 해석되어야 하며, 본 발명의 요지를 벗어나지 않는 범위 내에서의 변경, 치환, 대체 등에 의해 그와 동등한 범위 내에 있는 모든 기술 사상은 본 발명의 권리범위에 포함될 것이다. 또한, 도면의 일부 구성은 구성을 보다 명확하게 설명하기 위한 것으로 실제보다 과장되거나 축소되어 제공된 것임을 명확히 한다.
100 : 소스코드 저장소 210 : 소스코드 추출부
220 : 소스코드 분석부 230 : 소스코드 보고부
300 : 표시부
220 : 소스코드 분석부 230 : 소스코드 보고부
300 : 표시부
Claims (9)
- 동일한 정보에 대한 여러 버전을 관리하는 저장소인 소스코드 저장소에서 소스코드 추출부가 소스 파일의 로그만 추출하여 분석하기 위한 형태로 변환하는 추출작업을 수행하는 단계;
상기 소스코드 추출부에서 작업단위로 소스코드파일 변경된 내용을 분석하여 이슈도 작성을 위한 정보를 보관하는 분석작업을 소스코드 분석부에서 수행하는 단계; 및
상기 소스코드 분석부에서 분석한 정보를 이용하여 소스코드파일을 라인단위로 이슈도를 표시부에서 표시하도록 하는 보고작업을 소스코드 보고부에서 수행하는 단계;를 포함하여 이루어지며,
상기 소스코드 추출부가 소스 파일의 로그만 추출하여 분석하기 위한 형태로 변환하는 추출작업을 수행하는 단계에서 추출되는 데이터 구조는,
변경한 작업을 상기 소스코드 저장소에 기록하는 행위인 커밋(commit)에 대한 정보를 리스트로 보관하는 커밋들(commits)로써, 상기 커밋들을 구성하는 커밋은, 상기 커밋을 구분하기 위한 ID인 커밋 키값(commit hash 값)이 부여되고,
상기 각각의 커밋은, 커밋 시작을 표시하는 정보로서 커밋(commit) 값(해쉬값)을 표시하는 커밋 헤더(commit header)와,
상기 소스코드저장소(SCM)에 변경한 정보를 커밋(보관)하기 위해 남기는 메모인 커밋 메시지(commit message)와,
소스코드파일에서 변경한 작업의 일부분인 청크(chunk)와, 상기 청크(chunk) 시작위치 정보인 청크 헤더(chunk header)로 구성되는 변경작업 전과 변경작업 후 차이인 diff를 포함하여 구성됨을 특징으로 하는 로그기반 소스코드파일 이슈도 구현 방법. - 삭제
- 제1항에 있어서,
상기 소스코드 분석부에서 분석완료 후 생성되는 출력 데이터는
상기 소스코드 보고부에서 소스코드파일을 라인단위로 보고하도록 해당 라인의 커밋키값들과 해당 커밋과 연관된 이슈들을 보관하는 라인을 리스트로 보관하며, 상기 해당 라인의 커밋 키값들과 커밋과 연관된 이슈들(issues)을 리스트로 보관하되 연관된 이슈가 없으면 이슈들(issues)는 길이(length)가 0인 리스트이며,
상기 라인(line)을 라인들(lines) 리스트로 보관하는 것을 특징으로 하는 로그기반 소스코드파일 이슈도 구현 방법. - 제3항에 있어서,
상기 분석단계에서 상기 청크(chunk) 정보에서 라인이 삭제된 경우 삭제된 해당 라인 번호(line_no)를 키값으로, 라인들(lines)에서 해당 라인의 라인(line) 정보를 임시로 보관하고, 상기 청크(chunk) 정보에서 라인이 삭제 및 추가된 경우 삭제 라인들(deleted_lines)에 보관된 정보를 참고하여 삭제된 라인과 추가되는 라인이 같은 경우, 삭제된 라인의 라인(line) 정보에 추가된 라인의 라인(line) 정보를 첨부(append)하는 것을 특징으로 하는 로그기반 소스코드파일 이슈도 구현 방법. - 제1항에 있어서,
상기 소스코드 추출부의 추출작업 단계는,
상기 소스코드저장소(SCM)에서 소스코드 이슈도를 확인하려는 해당 소스코드파일에 대한 로그 및 변경 내용을 커밋(commit)단위로 커밋들(commits)에 보관하는 단계와,
상기 커밋(commit) 순서를 위해서 시간순으로 정렬하는 단계를 포함하여 이루어지는 것을 특징으로 하는 로그기반 소스코드파일 이슈도 구현 방법. - 제3항에 있어서,
상기 소스코드 분석부의 분석 방법은,
상기 커밋(commit) 라인의 끝인가를 판단하여 끝이면 분석 단계를 종료하고,
상기 커밋 라인의 끝이 아니라면, 커밋(작업) 헤더(commit header)인가를 판단하여 상기 커밋 헤더이면 커밋값(commit hash 값)을 상기 커밋(commit)에 보관하고, 이슈들(issues) 리스트를 초기화하는 단계,
그 다음 변경 내용 청크(chunk : 범위) 안쪽이라면서 라인추가이면, add_line() 서브함수를 호출하여 해당 라인번호의 라인들(lines) 리스트에 커밋, 이슈(commit, issues)를 append(추가)하는 단계,
상기 변경 내용 범위(chunk) 안쪽이고(S230), 라인추가가 아니라면 라인 삭제인가를 판단하여(S260) 라인 삭제이면, del_line() 서브함수를 호출하여 deleted_lines에 해당 라인번호(line_no)를 키로, 해당 라인정보(line)을 값으로 보관하고, 라인들(lines) 리스트에서 해당 라인(line) 정보를 삭제하는 단계,
상기 커밋 메시지(commit message) 영역에서 이슈가 발견되었는가를 판단하여 모든 이슈들을 이슈들(issues) 리스트에 append(추가)하고, 발견된 이슈가 변경내용범위 헤더(chunk header) 이면, 상기 청크 헤더(chunk header)에서 필요한 정보들을 보관하고, 새로운 청크(chunk)를 반영하기 위해서 deleted_lines를 클리어(clear)하는 단계,
상기 line_no를 하나 증가 후 커밋(commit)의 다음 라인을 조사하는 단계를 포함하여 이루어지는 것을 특징으로 하는 로그기반 소스코드파일 이슈도 구현 방법. - 제6항에 있어서,
상기 라인 추가 방법은
상기 deleted_lines에서 현재 line_no에 해당하는 key가 존재하면, 상기 deleted_lines에서 상기 line_no에 해당하는 값을 라인(line)에 보관 후 분석단계에서 전달받은 커밋, 이슈들(commit, issues)를 라인(line)에 추가(append)하고, 상기 deleted_lines에서 상기 line_no에 해당하는 값을 제거(삭제)하고, 상기 deleted_llines에서 현재 line_no에 해당하는 key가 없으면, 분석단계에서 전달받은 커밋, 이슈들(commit, issues)을 라인(line)에 보관하는 단계;
상기 라인들(lines) 리스트 길이가 line_no 보다 작다면, 상기 라인(line)을 라이들(lines) 리스트에 append(추가)하고, 상기 라인들(lines) 리스트 길이가 line_no 보다 작지 않으면, 상기 라인들(lines) 리스트의 line_no - 1 위치에 라인(line)을 insert(삽입)하는 단계를 더 포함하여 이루어지는 것을 특징으로 하는 로그기반 소스코드파일 이슈도 구현 방법. - 제6항에 있어서,
상기 라인 삭제 방법은 상기 라인들(lines) 리스트 길이가 line_no와 크거나 같은가에 따라 라인들(lines) 리스트 길이가 line_no 보다 작으면 종료하고,
상기 라인들(lines) 리스트 길이가 line_no와 크거나 같다면 deleted_lines 보관을 위해 필요한 정보를 설정 및 사전작업을 하되, 라인들(lines) 리스트에서 line_no - 1에 해당하는 값을 라인(line)에 보관하고, 라인들(lines) 리스트에서 line_no - 1에 해당하는 값을 삭제하며, line_no를 deleted_line_no에 보관하는 단계,
상기 deleted_line_no가 deleted_lines에 존재하는 키이면, 상기 deleted_line_no를 계속 증가하면서 존재하지 않는 키가 발견될 때까지 반복하는 단계,
상기 라인(line) 값을 deleted_lines 에 deleted_line_no 키로 보관하는 단계 및
상기 분석단계에서 청크(chunk) 분석할 때 라인번호 일관성을 유지하기 위해서 line_no를 감소하는 단계를 포함하여 이루어지는 것을 특징으로 하는 로그기반 소스코드파일 이슈도 구현 방법. - 제6항에 있어서,
상기 소스코드 보고부의 보고 단계는
상기 소스코드라인과 이슈도 출력을 위해 필요한 정보를 초기화하는 단계,
파일의 끝인가를 판단하여 파일의 끝이면 상기 소스코드파일을 닫고 소스코드파일 전체 이슈도를 total_issue_percentage = total_issues의 개수 / total_commits의 개수 * 100 으로 계산한다하고, 상기 total_issue_percentage, total_issues의 개수, total_commits의 개수를 상기 표시부 화면에 출력하고, 파일의 끝이 아니라면 소스코드 라인단위 commit 개수와 issue 개수를 계산하기 위해 필요한 정보를 초기화하는 단계,
상기 해당 라인에 커밋(commit)이 존재한다면, commit_count를 증가시키고, 해당 커밋(commit)과 연관된 모든 이슈 개수만큼 issue_count를 증가하는 단계,
상기커밋(commit)을 total_commits에 존재하지 않으면 추가하고, 커밋(commit)과 관련된 모든 이슈도 total_issues에 존재하지 않는 이슈들 모두 추가하고, 해당 라인에 커밋(commit)이 더 이상 존재하지 않는다면, 현재 라인의 이슈도를 issue_percentage = issue_count / commit_count * 100 를 이용하여 계산하고, issue_percentage, issue_count, commit_count, line_no, 소스코드 해당 라인 내용을 상기 표시부의 화면에 출력하는 단계,
상기 소스파일의 다음 라인을 조사하기 위해 소스파일의 다음 라인으로 이동하고 line_no도 증가시키는 단계를 포함하여 이루어지는 것을 특징으로 하는 로그기반 소스코드파일 이슈도 구현 방법.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR1020150182044A KR101690075B1 (ko) | 2015-12-18 | 2015-12-18 | 로그기반 소스코드파일 이슈도 구현 방법 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR1020150182044A KR101690075B1 (ko) | 2015-12-18 | 2015-12-18 | 로그기반 소스코드파일 이슈도 구현 방법 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| KR101690075B1 true KR101690075B1 (ko) | 2016-12-27 |
Family
ID=57736991
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020150182044A KR101690075B1 (ko) | 2015-12-18 | 2015-12-18 | 로그기반 소스코드파일 이슈도 구현 방법 |
Country Status (1)
| Country | Link |
|---|---|
| KR (1) | KR101690075B1 (ko) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109800019A (zh) * | 2018-12-17 | 2019-05-24 | 北京达佳互联信息技术有限公司 | 代码管理方法、系统、电子设备和计算机可读存储介质 |
| CN112825069A (zh) * | 2019-11-21 | 2021-05-21 | 阿里巴巴集团控股有限公司 | 数据库数据的分析方法、设备、系统及存储介质 |
| KR20230068516A (ko) | 2021-11-11 | 2023-05-18 | 황희영 | 프로젝트 기여도 측정 장치 |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH09259011A (ja) * | 1996-03-26 | 1997-10-03 | Fujitsu Ltd | ログ情報採取解析装置 |
| JP2001256043A (ja) * | 2000-03-10 | 2001-09-21 | Toshiba Corp | プログラムソースの修正履歴管理方法および修正履歴管理システム |
| KR20060113168A (ko) * | 2005-04-29 | 2006-11-02 | 엘지전자 주식회사 | 표준 코딩 규칙 적용을 위한 소스 코드 분석방법 |
| KR20080050118A (ko) | 2006-12-01 | 2008-06-05 | 삼성전자주식회사 | 임베디드용 소프트웨어의 오류 검출 방법 |
-
2015
- 2015-12-18 KR KR1020150182044A patent/KR101690075B1/ko active IP Right Grant
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH09259011A (ja) * | 1996-03-26 | 1997-10-03 | Fujitsu Ltd | ログ情報採取解析装置 |
| JP2001256043A (ja) * | 2000-03-10 | 2001-09-21 | Toshiba Corp | プログラムソースの修正履歴管理方法および修正履歴管理システム |
| KR20060113168A (ko) * | 2005-04-29 | 2006-11-02 | 엘지전자 주식회사 | 표준 코딩 규칙 적용을 위한 소스 코드 분석방법 |
| KR20080050118A (ko) | 2006-12-01 | 2008-06-05 | 삼성전자주식회사 | 임베디드용 소프트웨어의 오류 검출 방법 |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109800019A (zh) * | 2018-12-17 | 2019-05-24 | 北京达佳互联信息技术有限公司 | 代码管理方法、系统、电子设备和计算机可读存储介质 |
| CN112825069A (zh) * | 2019-11-21 | 2021-05-21 | 阿里巴巴集团控股有限公司 | 数据库数据的分析方法、设备、系统及存储介质 |
| CN112825069B (zh) * | 2019-11-21 | 2024-05-24 | 阿里巴巴集团控股有限公司 | 数据库数据的分析方法、设备、系统及存储介质 |
| KR20230068516A (ko) | 2021-11-11 | 2023-05-18 | 황희영 | 프로젝트 기여도 측정 장치 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108255925B (zh) | 一种数据表结构变更情况的显示方法及其终端 | |
| KR101690075B1 (ko) | 로그기반 소스코드파일 이슈도 구현 방법 | |
| SG191850A1 (en) | Formatting data by example | |
| US20080126878A1 (en) | Highlighting anomalies when displaying trace results | |
| CN109992476B (zh) | 一种日志的分析方法、服务器及存储介质 | |
| CN116132499B (zh) | 调用链的压缩方法、装置、计算机设备及存储介质 | |
| JP5552487B2 (ja) | ラスターイメージプロセッサの自動テスト方法 | |
| CN108009049B (zh) | Myisam存储引擎删除记录离线恢复方法、存储介质 | |
| CN110647447A (zh) | 用于分布式系统的异常实例检测方法、装置、设备和介质 | |
| EP4160421A1 (en) | Method and apparatus for obtaining browser running data, and storage medium | |
| EP4418090A1 (en) | Information interaction method and apparatus for document processing, and electronic device and storage medium | |
| JP4879782B2 (ja) | プログラムプロファイリング方法、及びプログラム | |
| US9213759B2 (en) | System, apparatus, and method for executing a query including boolean and conditional expressions | |
| CN111338759A (zh) | 虚拟磁盘校验码生成方法、装置、设备及存储介质 | |
| CN113434607A (zh) | 基于图数据的行为分析方法、装置、电子设备和存储介质 | |
| CN109977104B (zh) | 数据管理方法及装置 | |
| US9183388B2 (en) | Injustice detecting system, injustice detecting device and injustice detecting method | |
| JP2018181020A (ja) | 計算装置、影響出力システム | |
| CN111078738B (zh) | 数据处理方法、装置、电子设备和存储介质 | |
| CN114090673A (zh) | 一种多数据源的数据处理方法、设备及存储介质 | |
| CN114020717A (zh) | 分布式存储系统的性能数据获取方法、装置、设备及介质 | |
| CN109992475B (zh) | 一种日志的处理方法、服务器及存储介质 | |
| JP6633009B2 (ja) | 表データ分析プログラム | |
| JP4461771B2 (ja) | 異常挙動検出装置および異常挙動検出方法ならびにプログラム、希少挙動部分系列計算装置 | |
| CN111966655A (zh) | 日志采集过程中管理内存中文件对象的方法和装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| E701 | Decision to grant or registration of patent right | ||
| GRNT | Written decision to grant | ||
| FPAY | Annual fee payment |
Payment date: 20191204 Year of fee payment: 4 |