Code Readability Testing, an Empirical Study
https://www.researchgate.net/publication/299412540_Code_Readability_Testing_an_Empirical_Study
코드 유지 보수성을 향상시키는 요인 중 하나는 가독성입니다. 코드를 읽기 어려우면 후속 개발자가 그 흐름과 부작용을 이해하기 어렵습니다. 그들은 오랜된 버그를 수정하거나 새로운 기능을 추가하는 동안 새로운 버그를 도입 할 가능성이 있습니다. 그러나 소프트웨어 개발자는 자신이 읽을 수 있는 코드를 작성했는 지 어떻게 알 수 있습니까?
이 페이퍼에서는 코드를 읽을 수 있는 지 여부를 확인하고 이 기법이 프로그래머가 읽을 수 있는 코드를 작성하는 능력을 향상 시키는 지 여부를 평가하는 새로운 기술인 코드 읽기 능력 테스트를 제공합니다.
연구원은 21명의 소프트웨어 엔지니어링 마스터 학생을 대상으로 현장 연구를 수행하고 각 학생과 함께 서로 다른 "프로덕션 준비" 소프트웨어를 평가하는 4개의 개별 세션에서 코드 가독성 테스트를 따랐습니다. 관찰 후 설문지를 통해 프로그래머의 관점을 평가했습니다.
코드 가독성 테스트를 수행 한 결과, "읽을 수 없는" 코드를 작성하는 프로그래머의 절반은 4회의 세션 후에 "읽을 수 있는" 코드를 작성하기 시작했습니다. "읽을 수 있는" 코드를 작성하는 프로그래머는 또한 읽을 수 있는 코드를 작성하는 능력을 향상 시켰습니다. 이 연구는 코드 가독성을 높이기 위한 가장 빈번한 제안은 변수 이름 개선, 메소드 이름 개선, 코드 중복을 줄이기 위한 새로운 메소드 생성, if 조건 및 구조 단순화, 루프 조건 단순화라는 것을 보여줍니다. 프로그래머들은 가독성 테스트가 시간 가치가 있다고 보고합니다. 그들은 읽을 수 있는 코드를 작성하는 능력이 증가하는 것을 관찰합니다. 프로그래머가 자신의 코드를 이해하는 데 어려움을 겪는 독자를 경험하면 읽을 수 있는 코드를 작성하려는 동기가 부여됩니다.
이 페이퍼에서는 코드 가독성을 정의하고 코드 가독성 테스트가 프로그래머의 가독성 코드 작성 능력을 향상 시키며 코드 가독성을 향상시키는 데 필요한 빈번한 수정사항을 확인합니다.
읽기 쉬운 코드를 작성하면 소프트웨어 시스템의 개발 및 유지 관리 비용이 절감됩니다. 소프트웨어 개발 비용의 상당 부분은 새로운 기능을 추가하고 결함을 수정하기 위한 지속적인 유지 관리입니다 [1]. 소프트웨어 진화의 초기 단계에서도 기존 코드를 읽고 빠르게 이해하는 능력은 코드의 변경 능력에 영향을 미치는 핵심 요소입니다.
읽을 수 있는 코드를 작성하는 프로그래머를 만드는 것은 소프트웨어 산업에서 새로운 문제는 아니지만, 이전 작업에서는 프로그래머가 읽을 수 있는 코드를 작성하도록 교육하는 방법이 아니라 코드의 모양에 초점을 맞추었습니다. 개발자는 동료가 읽을 수 있는 코드 작성의 중요성을 인식하지만 코드를 읽을 수 있는 지 여부에 대한 피드백을 받지 못하는 경우가 많습니다. 작성자에게 명확한 프로그래밍 구조는 다음 개발자를 혼란스럽게 할 수 있습니다. 일부 프로그래머는 6개월 후에 자신의 코드를 읽을 수 없다고 한탄합니다. 코드가 작동하면 분명히 컴퓨터가 이해할 수 있지만 팀의 다른 사람을 할 수 있습니까?
이 기술을 가르치는 것은 컴퓨터 과학 및 소프트웨어 공학 커리큘럼에서 최우선 순위가 아닙니다. 컴퓨터 과학 커리큘럼은 읽기 쉬운 코드를 작성하는 방법이 아니라 특정 언어(예: functional vs. non-functional)의 프로그래밍 패러다임을 이해하도록 장려합니다 [2]. SWEBOK(Software Engineering Body of Knowledge)는 소프트웨어 구성 지식 영역에 대한 코딩 실용적 고려사항[3]에서 "이해할 수 있는 코드"작성을 참조합니다. 이것은 SWEBOK의 229개의 하위 주제 중 하나에 불과합니다. 대학원 소프트웨어 엔지니어링 참고 커리큘럼(GSwE)은 이 주제에 대해 SWEBOK 이외의 추가 권장 사항을 규정하지 않습니다 [4]. 일부 학부 과정에서는 프로그래밍 스타일 문제를 간단하게 다룹니다. 몇 가지 과정은 읽을 수 없는 코드를 생성하는 학생에게 불이익을 줍니다. In rare courses, 학생들은 다른 사람의 코드를 이어받은 경험을 시뮬레이션하는 과제를 교환합니다. 이것은 학생들이 읽을 수 있는 코드를 작성해야 하는 필요성에 민감해지지만, 경험을 기술을 향상시킬 구체적인 단계가 부족합니다. 컴퓨터 과학 커리큘럼 또는 소프트웨어 엔지니어링 커리큘럼의 강조는 참조 커리큘럼의 실질적인 주제에 있습니다.
회사는 프로그래머가 이 기술을 가지고 입사하거나 직업 훈련을 통해 배울 것이라고 가정하는 경향이 있습니다. 프로젝트 팀은 코스 스타일 지침 또는 코드 작성에 대한 모법 사례를 가질 수 있습니다. 예를 들어 프로그래머가 데이터베이스 연결을 열면 즉시 close 문을 작성합니다.
소프트웨어 검사 및 코드 리뷰의 효율성을 뒷받침하는 강력한 경험적 증거가 있습니다. 이러한 기술을 가독성 문제를 식별 할 수 있지만 개발자에게 가독성있는 코드 작성 방법을 가르치도록 설계 되지 않았습니다. 작성자가 결함 목록을 받으면 작성자는 코드가 독자를 어떻게 혼동하는 지 배울 기회를 잃게 됩니다.
Code Readability Testing은 코드를 읽을 수 없는 영역을 보여주고 코더와 리더 사이의 대화를 가능하게 합니다. 작성자는 코드를 읽는 사람이 코드를 정확히 어떻게 해석하는 지 알기 때문에 피드백은 즉각적입니다.
GQM(Goal Question Metric)의 목표 템플릿을 사용하는 목표는 연구원의 관점에서 효율성과 관련하여 프로그래머가 읽을 수 있는 코드를 작성하는 능력을 향상시키는 데 그 효과를 결정하기 위해 코드 가독성 테스트를 분석하는 것입니다. Carnegie Mellon University의 "소프트웨어 개발 기술"과정의 맥락에서 이 페이퍼에서는 이 목표를 네 가지 질문으로 분해합니다.
- 연구 질문 1: 코드 가독성 테스트를 반복적으로 따르는 프로그래머가 코드의 가독성을 높일 수 있습니까?
- 연구 질문 2: 코드 가독성 테스트가 어떤 종류의 문제를 감지합니까?
- 연구 질문 3: 가독성 테스트는 얼마나 많은 시간이 소요됩니까?
- 연구 질문 4: 프로그래머는 코드 가독성 테스트를 어떻게 인식 했습니까?
코드 가독성과 프로그래밍 스타일을 개선하는 것은 소프트웨어 산업의 새로운 주제가 아닙니다.
Kernighhan과 Plauger는 1974년 저서 The Elements of Programming Style에서 컴퓨터 과학 교과서에 사용된 코드를 다시 작성하여 코딩 관행과 코드 가독성을 개선하기 위한 휴리스틱스를 문서화합니다 [5]. 1982년 저서, Understanding the Professional Programmer에서 Gerald Weinberg는 프로그래머가 컴퓨터의 컴파일러나 인터프리터보다 코드를 읽는 사람이 더 중요한점을 강조합니다. 그는 영문 텍스트의 작성 과정과 마찬가지로 코드가 모범적인 코드가 되기 전에 여러번 다시 작성해야 한다고 제안합니다. 그는 프로그래머가 미래에 자주 읽을 코드를 재작업하는 데 시간을 할애 하도록 권장합니다 [6].
전문 프로그래머를 대상으로 한 최근의 책에서 Andrew Hunt, David Thomas, Kent Beck 및 Robert Martin은 다양한 방식으로 스타일을 다루고 있습니다. Pragmatic Programmers에서 Hunt와 Thomas는 프로그래머가 자신의 기술을 습득하는 데 도움이 되는 도구, 프로세스 및 트릭을 조사합니다 [7]. Clean Code에서 Robert Martin은 개발자가 더 나은 프로그래머가 되는 데 도움이 되는 기술을 다룹니다 [8]. Implementation Patterns에서 Kent Beck은 좋은 소프트웨어 개발 디자인 패턴을 다룹니다 [9]. 한마디로 말하면, 그들은 평생의 경험을 모범 사례로 추출하고 그중 일부는 코드 가독성을 다룹니다.
최근 연구에서 연구원들은 다양한 접근 방식에서 코드 가독성을 조사합니다: 자동화된 개선 기술, 식별자 이름 지정, 구문 및 자동화된 메트릭. 여러 연구에서 코드 가독성을 높이기 위해 기술을 자동화하려고 합니다. Wang은 가독성을 높이기 위해 코드에 빈 줄이 자동으로 삽입되는 것을 조사하고 [10] Sasaki는 사용직전에 변수를 선언하여 가독성을 높이기 위해 프로그래밍 문을 재정렬합니다 [11]. 몇몇 연구자들은 식별자의 이름을 조사합니다 [12], [13], [14], [15]. Relf의 도구는 개발자가 변수 및 메서드 이름을 개선하도록 권장합니다 [15]. Binkley는 camel case가 underscore 변수보다 읽기 쉽다는 것을 관찰합니다 [16]. Jones는 코드 가독성에서 연산자 우선 순위 문제를 조사합니다 [17].
인간 평가는 코드 가독성의 표준으로 남아 있지만 자동화된 메트릭은 종종 프록시 역할을 합니다. 몇몇 연구는 컴퓨터 프로그램이 가독성을 결정할 수 있도록 코드 가독성 메트릭을 만들기 위해 노력하고 있습니다 [18], [19], [20].
이러한 메트릭을 정적 분석 도구, 개발 환경 및 IDE에 통합하면 비용이 많이 드는 평가가 제공됩니다. 컴퓨터를 사람으로 대체하면 문제가 발생합니다. 문자수 또는 사전 단어를 사용하는 측정 항목은 "정확히 내가 의미하는 바"인 변수와 동일하게 읽을 수 있는 "뭔가 혼란 스러움" 또는 "모호함"이라는 변수에 점수를 매길 수 있습니다. 가독성 측정 항목에 대한 통계적 접근 방식이 도움이 되지만 이러한 측정 값은 프로그래머의 의도를 드러내지 않습니다.
| Technique | Code Readability | Code Review | Fagan Inspection | Pair Programming |
|---|---|---|---|---|
| Purpose | Understand code | Find defects, Understand code | Find defects | High quality code |
| Roles | Author, Reader | Author, Reviewer | Author, Moderator, Inspector (2+), Recorder, Reader / Timekeeper | Author, Author |
| Feedback to the author is | Synchronous | Asynchronous | Asynchronous | N/A |
Fagan Inspections, Code Reviews 및 Pair Programming은 표 I에 요약된 대로 코드 품질을 향상시키는 다른 기술입니다. Fagan Inspections은 개발자 위원회가 코드를 검토하는 결함을 찾기 위한 입증된 시간 집약적인 프로세스입니다 [21]. 검사에는 종종 프로그래밍 스타일 가이드와 코딩 표준이 포함됩니다. 작성자가 참석하는 동안 강조점을 결함 식별에 있으며 리뷰어가 코드로 인해 혼동 될 수 있는 이유를 밝히지 않습니다. Code Reviews 영역은 한 개발자가 소스 코드 관리 시스템의 마스터 브랜치 또는 트렁크에 커밋되기 전에 코드를 검토하는 인기있고 가벼운 프로세스입니다 [22]. 저자는 수정을 위해 제안된 변경 사항 또는 문제 목록을 받습니다. 작성자가 없기 때문에 작성자는 검토자가 코드를 이해하기 위해 거치는 프로세스를 볼 수 없습니다. 개발자는 개발자가 읽을 수 있는 코드를 작성하는 방법을 교육하는 것이 아니라 주로 버그 감지 [22], [23]에 코드 리뷰를 사용합니다. Pair Programming은 두 개발자가 동시에 코드를 작성할 때 발생합니다. Pair Programming을 사용하면 코드를 지속적으로 검토 할 수 있지만 작성자가 관찰 할 수 없는 문제를 드러 낼 수 있는 새로운 관점을 제공하지는 않습니다. 채택에 대한 저항은 Solo Programming 보다 더 비싸다고 생각하는 경영진이나 그 과정의 사회적 의미를 좋아하지 않는 프로그래머에게서 나옵니다.
노트: Bacchelli와 Bird는 실제로 프로그래머가 코드에 대한 이해를 높이고 있을 때 프로그래머가 Code Review의 목적이 결함을 찾는 것이라고 생각했다고 보고합니다 [23]. 이것이 Code Review의 주요 이점이라면 Code Review 기술보다도 코드 이해 능력을 더 효율적으로 높이기 위해 다른 메커니즘을 설계 할 수 있습니다.
Perspective-Based-Reading은 사용자, 개발자, 테스터와 같은 규정된 역할과 함께 요구사항 문서를 검토합니다 [25]. 개발자는 요구사항을 설계로 변환하고 테스터는 요구사항에 누락 및 결함이 있는 지 확인하기 위해 요구사항을 테스트 계획으로 변환합니다.
그러나 "관련 커뮤니티가 코드를 이해하고 유지할 수 있습니까?"라는 질문이 남아 있습니다. 따라서 우리는 "코드를 읽을 수 있는지 어떻게 알 수 있습니까?"라고 자문 할 수 있습니다.
세션에서 코드 작성자는 문제가 발생하는지 여부와 위치를 관찰합니다. 세션이 끝나면 두 프로그래머가 코드 가독성을 향상시키는 방법에 대해 논의합니다. 이 프로세스는 다른 프로그래머가 작성자의 코드를 구문 분석하고 이해하는 방법을 코드 작성자에게 보여줍니다 [26].
-
작성자는 독자에게 주요 사용 사례, 스토리 카드 또는 생성된 기능을 알려줍니다. 작성자는 디자인이나 코드를 설명하지 않습니다.
-
작성자는 어떤 파일이 추가되거나 수정되었는지 표시하며, 테스트 케이스부터 시작하면 클라이언트 코드에서 코드가 어떻게 사용되는지 이해하는 데 도움이 됩니다.
-
독자는 코드를 소리내어 읽고 독자의 사고 과정을 설명합니다. 코드가 명확하지 않으면 독자는 코드의 의도를 추측합니다. 독자는 코드 동작에 대해 어떻게 생각하는지 구두로 설명하고 사고 과정을 설명합니다. 음성 질문은 독자와 작성자에게 초점을 맞추는 데 도움이 됩니다. 독자가 익숙하지 않는 프로그래밍 구문으로 인해 코드 줄을 이해하지 못하는 경우 독자는 작성자에게 수행 동작에 대해 묻습니다.
-
작성자는 독자가 생각하거나 묻는 것에 응답하지 않습니다. 작성자는 특정 섹션을 혼란스럽게 만드는 요소에 대해 메모 할 수 있습니다.
-
마지막에 독자는 독자가 코드를 올바르게 이해하고 있음을 작성자에게 확인합니다. 그런 다음 작성자는 경험에 대한 명확한 질문을 독자에게 묻습니다.
-
작성자와 독자가 코드를 개선하는 방법을 논의합니다.
Human Computer Interaction의 사용성 테스트 기법[27]은 이 프로세스의 모델 역할을 합니다. 사용성 테스트에서 사용자 경험 디자이너는 대표 사용자가 프로토타입 또는 제품의 실체 인터페이스에서 작업을 시도하는 것을 지켜봅니다. 연구원은 사용자를 관찰하여 무엇이 분명하고 무엇이 사용자를 혼란스럽게하는지 결정합니다. 특히 시스템과 사용자의 자연스러운 상호 작용은 사용자 경험 디자인에 자연스러운 affordances를 알려줍니다. 사용자의 기대에서 벗어나는 시스템은 개선된 디자인의 기회를 나타냅니다. Code Readability Testing에서 제품은 소스 코드이고 사용자는 다른 개발자입니다.
이상적인 독자는 미래의 개발자와 시스템을 유지할 사람들을 나타냅니다. 일반적인 팀의 경우 같은 팀의 개발자가 이상적인 독자 역할을 합니다. 오픈 소스 프로젝트의 경우 핵심 개발자와 컨트리뷰터가 이상적인 독자 역할을 하며, 이상적인 독자는 작성자와 유사한 경험을 보유하고 사용된 프로그래밍 언어, 프레임워크 및 라이브러리에 능숙합니다. 프로그래머가 경험이 적은 프로그래머가 자신의 코드를 일상적으로 읽을 수 있기를 기대한다면 초보자는 이상적인 독자가 될 것입니다.
연구원은 4개의 개별 일대일 세션에서 각 프로그래머와 함께 Code Readability Testing을 수행하여 시간이 지남에 따라 효율성을 평가하고 개선사항을 관찰했습니다. 프로그래머는 2013년 봄 학기 동안 실리콘 벨리의 Carnegie Mellon University에서 "Craft of Software Development" 과정에 등록한 21명의 소프트웨어 공학 대학원생이었습니다.
연구원은 각 세션을 30분 동안 3주 간격으로 스케줄하여 84개의 데이터 포인트를 생성했습니다. 각 세션에서 연구원은 학생들에게 "생산 준비가된" 코드를 가져 오도록 요청했습니다. 소프트웨어는 실제 프로젝트에 출시될 준비가 되었습니다. 학생들은 자신의 프로젝트를 선택했습니다. 각 세션이 끝날 때 연구원은 검토 기간, 발견된 문제의 수와 유형, 전체 가독성 점수 평가를 기록했습니다.
학생의 전문 개발 경험은 0년에서 8년 사이였습니다. 평균 경력 연수는 3년이었습니다.
이 문서에서는 코드를 이해하는 데 필요한 정신적 노력의 양으로 코드 가독성을 정의합니다. 코드를 조사한 후 연구원은 이 척도에 따라 가독성 점수를 할당했습니다.
4) Easy to read
3) Pretty easy to read
2) Medium difficulty
1) Very challenging
기존 연구 [10], [11], [20], [28], [29]에는 표준 가독성 정의나 점수가 없습니다. Buse와 Dorn 연구 모두에서 참가자는 Likert 척도로 코드를 "very unreadable" 1에서 "very readable" 5, "unreadable"에서 readable"를 평가했습니다 [18], [19]. 참가자는 읽을 수 있도록 자신의 의미를 정의합니다.
이 scale은 사용하면서 연구원은 검토 기간이 필요한 노력의 양과 관련이 있음을 발견했습니다. 예를 들어, "easy to read" 코드를 검토하는 것은 검토하는 데 많은 시간이 걸리지 않습니다. 평균 길이는 4분 차이로 8분이었습니다. 코드를 읽기 위해 "very challenging" 검토는 종종 전체 세션을 소비했습니다. 가독성 점수와 검토 시간 간의 상관 관계는 0.77이었습니다.
일반적으로 "easy to read" 코드는 독자에게 간단한 설명을 제공하여 단기 기억에 몇 가지 항목을 유지합니다. "very challenging" 코드는 프로그래머의 의도를 흐리게 합니다. 독자가 한 장의 종이를 잡고 프로그램 로직을 이해하기 위해 변수값을 적어 컴퓨터 프로그램을 수동으로 실행하면 코드는 읽기가 "very challenging" 합니다.
많은 프로그래밍 문제에 대한 일반적인 해결책이 있습니다. "very challenging" 코드는 솔루션에대한 일반적인 솔루션이나 일반적인 구성을 피할 수 있습니다. 코드의 솔루션이 솔루션에 대한 독자의 기대와 다르면 독자는 코드가 "very challenging" 임을 알게됩니다.
데이터를 검토 한 후 데이터가 "readable" 코드와 "unreadable" 코드의 두 그룹으로 축소 될 수 있다는 것이 분명해졌습니다. 연구원은 "easy to read" 코드와 "Pretty easy to read" 코드 샘플을 "readable" 코드로 분류하고 "very challenging" 및 "medium difficulty" 코드 샘플을 "unreadable" 코드로 분류했습니다. unreadable 코드의 경우 프로젝트에 제출하기 전에 코드를 재작업해야 했습니다. 이 두 그룹을 비교할 때 코드 샘플은 실제로 밤낮이었습니다.