2022. 6. 4. 14:02ㆍ소프트웨어 공학
코딩 로드맵
소프트웨어 제품의 품질은 결국 원시 코드에 모두 귀결
- 설계가 완료되면 코딩 단계 시작
- 코딩 단계에 투입되는 시간이 다른 단계보다 상대적으로 적음
- 허나, 품질에 미치는 영향은 매우 큼
목표
- 설계 명세에 나타낸 대로 요구를 만족할 수 있는 프로그래밍
- 오류가 적은 품질 좋은 프로그램
- 작업과정
1. 원시 코드를 같은 스타일로 만들기 위해 코딩 표준 제작
2. 아키텍처 설계 결과 프레임워크 패키지와 응용 패키지를 결정
3. 클래스 구현이 끝나는 대로 인스펙션
4. 클래스 단위로 테스트
5. 클래스나 패키지를 릴리스 -> 응용 시스템으로 통합
코딩 표준
코딩 스타일 :
- 문장 패턴이나 구성 등읠 일관된 유형
좋은 코딩 스타일 :
- 간결함 : 복잡하지 않고 명확하여 이해가 쉬운 것
- 읽기 쉬움 : 프로그램을 대충 훑어봐도 이해하기 쉬운 것
코드의 간결성을 설계 품질에 좌우
- 모듈화의 목표, 높은 응집력, 낮은 결합도를 달성하면 모듈은 간단해짐
명명 규칙
패키지, 클래스, 인터페이스, 메서드 등 요소에 대해 이름을 붙이는 방법
- 카멜 케이스 : 여러 단어를 함께 붙여 쓰되, 맨 앞에 오는 단어만 첫 문자는 소문자로, 뒤에 각 단어는 대문자로
상수는 모두 대문자로
- 클래스와 인터페이스 이름 : 명사 또는 명사구이며, 첫 단어는 대문자로 시작 : 파스칼 케이스
- 메서드 이름 : 일반적으로 소문자로 시작
- 함수 이름은 일반적으로 값을 설명하는 명사구로
- 필드의 값을 접근하여 리턴하는 함수는 get...
- 조건을 묻는 bool 함수의 이름은 대개 is로 시작
- 변수 이름 : 소문자로 시작
용도에 대한 힌트 제공
모호한 이름 사용 x
대상이 사용된 위치 고려
매개 변수 : 되도록 짧게
필드 변수 : 가능한 의미가 담겨 있게
- 패키지 이름 : 모두 소문자이며 명사로
헝가리안 표기법 : 변수 이름 앞에 타입 구별
ex) lAccount, bReadLine strName
- 변수 목적 똔느 변수가 무엇인지 힌트를 줌
ex) usNAme , szName
- 형식
들여쓰기, 괄호 : 프로그램 구조를 명확하게 하기 위해 사용
문장의 일부와 선언문을 들여 쓰기
오류 처리
- 잘못된 데이터를 어떻게 다룰 것인가 - 체계적인 접근 방법 필수
- 입력 오류 방지
- 리스트 박스
- 디폴트 값을 지정
주석
- 다른 사람들이 프로그램을 이해하기 쉽도록 기술
- 디버깅하는 동안 얻을 수 있는 도움
- 주석 다는 법
- 불필요한 단어는 생략
- 과도한 주석 피함
- 클래스 불변 조건
- 클래스의 속성에 대한 의미와 제약 기술
- 메서드 주석 : 메서드가 하는 일을 설명하는 javadoc 스펙 선행 조건과 함꼐 작성
ex) @param b
무언가를 수행한다는 문장으로 작성, 관련 매개 변수 언급
- 클래스 주석
파일 시작 부분에 클래스 용도를 설명하는 주석이 포함
- 문장 주석
논리적 단위로 그룹화
IDE 도구
- UML 다이어그램으로 부터 원시 코드 골격을 자동 생성
- 연관 코딩
- 1:1, 1:N, N:N
리펙터링
- 소프트웨어를 보다 쉽게 이해하게 함
- 적은 비용으로 수정할 수 있도록 겉으로 보이는 동작 변화 없이 내부 구조 변경
- 결과의 변경 없이 코드 구조를 재조정
- 이미 존재하는 코드의 디자인을 안전하게 향상
- 가독성을 높이고 유지보수를 용이하게 함
- 리펙터링의 목적
- 버그 식별 용이
- SW 디자인 및 구조 개선
- 코드 가독성 향상
- 코드 작업 생산성
- 리펙터링 과정
1. 소규모 변경 - 단일 리팩터링
2. 코드가 전부 잘 작동되는지 테스트
3. 전체가 잘 작동하면 다음 리펙터링 단계로 전진
4. 작동이 안되면 문제를 해결하고 리펙터링한 것을 undo하여 시스템이 작동되도록 유지
코드 스멜
- 리펙터링에서 프로그램 작업을 어렵게 만드는 경우
- 나쁜 코드의 냄세
예)
- 읽기 어려운 프로그램
- 중복된 로직을 가진 프로그램
- 실행 중인 코드를 변경해야 하는 특별한 동작을 요구하는 프로그램
- 복잡한 조건문이 포함된 프로그램
리펙터링 기법
- 메서드 추출
- 그룹으로 함꼐 묶을 수 있는 코드 조각이 있으면 코드의 목적이 잘 드러나도록 메서드 이름을 지어 별도의 메서드를 추출
- 클래스 추출
- 두 개의 클래스가 해야 할 일을 하나의 클래스가 하고 있는 경우 새로운 클래스를 만들어 관련 있는 필드와 메서드를 예전 클래스에서 새로운 클래스로 이동
- 서브 클래스 추출
- 어떤 클래스가 일부 인스턴스에 의해서만 사용되는 기능을 가지고 있다면 인스턴스만 사용하는 기능을 담당하는 서브클래스를 제작
- 메서드 이동
- 메서드가 자신이 정의된 클래스보다 다른 클래스의 기능을 더 많이 사용하고 있다면 다른 메서드로 옮김
- 인터페이스 추출
- 여러 클라이언트가 한 클래스의 인터페이스의 동일한 부분집합을 사용하고 있다면 부분집합을 인터페이스로 추출
- 템풀리 메서드 형성
- 각 서브 클래스에 있는 두 메서드가 완전히 같지 않지만 비슷한 작업을 한다면 하나로 통일하여 상위 클래스로 옮김
코드 인스펙션
- 프로그램을 읽어보고 눈으로 확인하는 방법
- 프로그램이 성공적으로 컴파일되고 정적 분석 도구에 의하여 검사된 후에 이루어짐
- 프로그래머와 설계자, 테스터가 잠여
- 코드와 설계 문서를 리뷰
- 코드에 묻혀있는 결함 탐색
- 체크리스트 사용
- 효율성, 코딩 표준의 준수 여부 등
- 심각도를 통해 결함의 우선순위를 나타냄
- 결함의 타입
- 로직 문제
- 컴퓨팅 문제(잘못된 수식, 부호)
- 인터페이스/타이밍 문제(IO, 서브루틴 불일치)
- 데이터 처리(데이터 부정확)
정적 분석
- 수행되지 않은 데드 코드가 없는지, 선언이 되지 않고 사용한 변수가 없는지 등 검사
- 프로그램 텍스트를 조직적으로 분석하여 결함 탐색
- 소프트웨어 도구를 이용하여 자동으로 가능
- 결함 탐색 방법
- 코드에 존재하는 결함으로 나타날 비정상적인 패턴이나 원하지 않는 패턴 탐색
- 자료 흐름 또는 논리 흐름 분석
- 실행할 떄 프로그램의 고장을 일으킬 코드 상에 존재하는 결함 직접 탐색
- 자료 변칙 : 자료 흐름도를 분석하면 자료가 정의되지 않고 사용되거나 정의되고 사용되지 않는 비정상적인 패턴을 찾는 것
- 사족 :
- 불필요한 부분
- 데드 코드는 컴파일러에 의하여 검출되지 않음 : 실행될 일이 없는 코드
- 중복된 배정문, 데드코드, 조건 중복 등
테스트 중심 개발
테스트를 위한 코드를 작성한 후 기능을 구현
주로 클래스 안에 있는 메서드를 시험
개발 과정
페어 프로그래밍
- 애자일 방법에서 프로그래밍과 테스팅을 담당하는 두 사람이 컴퓨터 머신을 공유하며 개발과 테스팅
- 장점
- 두 사람이 캍은 컴퓨터를 사용하여 같이 프로그래밍 함
- 스트레스와 성공의 기쁨을 나눌 상대가 있음 --> 재미있고 압박을 줄일 수 있음
- 파트너와 아이디어를 교환하기 때문에 팀의 소통을 향상시킬 수 있음
- 팀 구성원이 서로를 이해하고 서로에게서 배우기 때문에 상호 이해와 협력이 향상
- 토론이 창의적인 사고로 발전하여 문제 해결에 도움이 되므로 간단하고 효율적인 해법 제작 가능