1) 변수는 선언된 곳에서 초기화, 가능한 한 좁은 범위에서 선언
2) 관련된 변수는 같은 문장에서 선언, 관련되지 않은 변수는 같은 문장에서 선언하지 않고 분리 선언
3) 클래스의 인스턴스 변수는 public으로 선언하지 않음
4) 반복 구조의 제어 문장은 루프 안에서만 사용
5) 조건에서 배정문 등 실행문장의 사용을 피함
2) 주석의 문서화
- 주석을 무서화 할 때 유의 사항
1) 원시코드에 익숙하지 않느 사람이 코드를 읽고 이해해야 한다고 가정하고 작성
2) 코드와 문서를 항상 일치시킴
3) 불필요한 것은 생략하고, 명확하고 간결하게 작성
3) 주석 사용법
- 메소드에 대한 주석문서에 포함될 사항
1) 전제 조건과 결과 조건
2) 메소드가 하는 일과 그 일을 하는 이유
3) 전달되어야 할 매개변수 @param
4) 발생가능한 예외사항 @exception
5) 가시성(private,public) 선택 이유
6) 인스턴스 변수값을 변경하는 방법
7) 알려진 버그
8) 테스트에 대한 설명(메소드가 테스트되었는지와 테스트 스크립트의 위치)
9) 형상관리시스템을 사용하지 않는다면 변경 히스토리
10) 메소드가 동작하는 예
11) 스레드 및 동기화된 메소드를 위한 문서화
연관관계의 구현
1) 1대1 연관 : A가 B의 함수를 호출하면 A가 B에 대한 레퍼런스를 갖게 구현
2) 1대n 연관 : A가 B의 함수를 호출하면 -> A가 B에 대한 레퍼런스의 집합을 갖게 구현
3) n대n 연관 : A에서 B로의 레퍼런스 집합으로 구현하며, 반대의 경우도 같은 방법으로 구현 , 또는 두개에 연관된 새로운 클래스를 하나만들어 각각 1대 n 또는 n대 1로 연관 시킨다.
시퀀스 다이어그램의 구현
리팩토링
- 기능의 변경없이 코드의 디자인을 개선 하는 것
- 문제가 될 만한 부분을 찾아내어 수정하고 재구조화하는 작업
- (소프트웨어를 보다 쉽게 이해할 수 있고, 적은 비용으로 수정할 수 있도록) 겉으로 보이는 동작의 변화없이 내부 구조를 변경하는 것
리팩토링 작업 과정
- (단일 리팩토링) 작은 변경을 가함
- (테스트) 모두 잘 작동된다는 것을 확인하기 위해 테스트
- (작동여부 점검) 모두 잘 작동되는지 점검
- (Yes) 다음 리팩토링으로 넘어감
- (No) 문제를 수정하거나 원상복구 -> 시스템에 작동되도록 유지
- 설계를 수정하기 어렵게 만드는 코드
- 코드 스멜의 예
1) 중복코드
2) 긴 메소드
3) 큰 클래스
4) 많은 케이스를 가진 case문장
5) 긴 네비게이션(메소드 호출), 예:a.b().c().d()
6) 지나친 널 객체 체크
7) 유사 데이터의 중복
8) 데이터 클래스 (메소드는 거의 없고 속성만 많은 클래스)
9) 캡슐화되지 않는 필드(public으로 선언된 멤버 변수)
cf) validation(프로그램의 효용 가치, 요구사항 충족 하는가?)
verification(코드 검토, 이런 로직이 코드에 잘 반영됐는가?)
인스펙션
- 정의
1) 수행전
2) 코드에 존재하는 결함과 비효율성, 표준 불일치를 찾기 위한
3) 리뷰
- 수행 시기
1) 프로그램이 성공적으로 컴파일 되고, 정적 분석도구가 적용된 이후
- 체크 리스트의 대상
1) 클래스전체
2) 속성
3) 생성자
4) 메소드 헤더
5) 메소드 내부
인스펙션 결과 중 결함심각도의 분류
1) 중요 - 요구가 충족되지 않음
2) 중간 - 중요하지 않고 그렇다고 쉬운 문제도 아님
3) 쉬움 - 오퍼레이션이나 유지보수에 영향을 주지 않음
출처 : 한빛아카데미, 소프트웨어공학설계