10. 구현

• 구현 
• 코딩 원리
• 코딩 표준
• 리팩토링 & 검토

 

---

구현

 

• 구현 로드맵 그리기

1. 원시코드의 스타일 통일을 위한 코딩 표준 작성

2. 아키텍처 설계를 바탕으로 프레임워크 패키지와 응용 패키지를 구분

3. 요구사항과 상세설계를 반영한 메소드 코딩

4. 인스펙션

5. 클래스 단위로 테스트

6. 릴리스

 

• 구현 준비 사항

→ 상세 설계 사항 ( 설계 문서 )

→ 소요 시간 측정을 위한 양식 

→ 결함을 기록 양식 

→ 코딩 표준과 문서화 표준에 대한 이해

→ 과거 데이터를 기반으로 한 작업 계획 및 소요 시간 예측

 

 

• 구현 단계의 작업 절차

1. 코딩 작업의 계획 & 설계서 확인을 통한 부족한 부분 보충

→ 사전 조건 / 결과 조건을 확인

→ 코딩에 걸리는 시간을 예측

 

2. 설계 및 구조 검토

→ 걸린 시간 / 결함 유형 / 위치 / 심각도 기록

 

3. 코딩하기

→ 컴파일은 나중으로 미룬다.

→ 클래스의 메소드를 중심으로 코딩하고, 코딩 표준을 지킨다.

→ 검증하기 쉬운 ( 테스트가 쉬운 ) 방법으로 코딩하며, 정형화된 틀이 있다면 적용한다.

 

4. 코드를 스스로 검토한다 ( 컴파일 X )

→ 작성한 코드가 요구된 작업을 하는지 확인 ( 구문 확인 )

→ 걸린 시간 / 결함 유형 / 위치 / 심각도 기록

→ 체크리스트를 이용해 코드를 인스펙션한다.

 

5. 컴파일하기

→ 구문 오류를 수정한다.

→ 걸린 시간 / 결함 유형 / 위치 / 심각도 기록

 

6. 코드를 테스트 한다.

→ 테스트 방법 ( 다음 글 ) 에 따라 단위 테스트를 실행한다.

 

---

 코딩 원리

 

• 재사용

→ 이미 존재하는 (신뢰성있는) 코드의 재사용

 

• 의도 확립

→ 특정 방법으로만 사용하려는 의도가 있다면 다른 방법이 불가능하게 해야함

→ private / protect / public / final / const / constract 의 적절한 사용

※ final 함수는 재정의 X, final 변수는 변경X

 

• 프로그램 로컬화

→  멤버의 로컬화 ( 지역화 )

→  멤버의 은닉

→  외부에서 필요하다면 public 멤버 함수를 이용

→  클래스가 오직 하나의 인스턴스만 갖는다면 싱글턴 패턴 적용

 

• 포인터 & 레퍼런스

→  매개변수를 래퍼런스 타입으로 사용할 것

→  new 사용을 피하고, 팩토리 멤버함수를 사용한다

→  위 2가지 방법으로 메모리 관리 가능

 

• 함수

→  프렌드 함수 사용 자제

→  오버로딩 시 혼돈 방지를 확실히 할 것

 

• 예외처리

→  어떻게 예외처리 할 지 정확히 알 때만 예외처리를 할 것

→  알지 못한다면 더 넓은 범위에서 처리할 것

→  호출자가 예외처리를 다룰 수 있을 것

→  테스트를 통해 예외사항을 검증할 것

→  예외처리와 계속 실행 중 선택해야 한다면 계속 실행을 선택할 것

 

• 오류처리

→  합의된 개발 프로세스를 따른다 ( 인스펙션 )

→  매개변수 값을 캡슐화 할 것

→  오류처리 할 곳을 요구에 명시하고, 요구한 대로 구현할 것

→  패러미터 확인은 일관성있게

 

• 객체지향 코딩 규칙

→  단일 책임 / 개방 폐쇄 / 리스코프 대체 / 인터페이스 분리 / 의존관계 역전

 

1. 단일 책임

→  클래스는 오직 한 가지 이유로만 변경되어야 한다.

→  로직과 표현을 분리해야 한다.

 

2. 개방 폐쇄

→  모듈은 확장에는 개방되고 변경에는 폐쇄되어야 한다

 

3. 리스코프 대체

→  서브타입은 자신의 베이스 클래스로 대체 가능해야 한다.

→  서브 클래스를 만들 때 베이스 클래스를 변경하지 말고 확장해야한다.

 

4. 인터페이스 분리

→  여러 클래스로 구성된 모듈은 추상화된 인터페이스를 제공해야 한다

→  사용자의 관심이 되는 인터페이스만을 분리하여 제공해야 한다.

 

5. 의존 관계 역전

→ 자주 변경되는 클래스에 의존하면 안된다.

→ 추상 클래스와 인터페이스에 의존해야 한다.

 

 

---

코딩 표준

 

 

• 코딩 표준의 장점

→ 가독성 , 호환성 향상

 

• 명명 규칙

→ 패키지 이름은 소문자 시작

→ 클래스 이름은 대문자 시작 & 명사

→ 변수 이름은 소문자 시작

→ 상수 이름은 모두 대문자

→ 데이터 이름은 언더바 시작

→ 메소드 이름은 소문자 시작

 

• 파일 구성 규칙

→ 파일 당 하나의 외부 클래스 or 인터페이스를 담고 있다면 클래스 이름과 파일 이름을 같게 할 것

→ 한 줄은 80칸을 넘지 말 것

→ 줄이 길면 다음 줄로 넘기고 알 수 있게 할 것

→ 쉼표 이후 분할 / 오퍼레이터 이전 분할할 것

→ 수식이 나누어지는 경우 다음 줄을 수식의 시작 부분과 일치 시킬 것

 

• 문장 규칙

→ 변수는 선언된 곳에서 초기화 , 좁은 범위에서 선언할 것

→ 관련된 변수는 같은 문장에서 선언하고 아니면 분리할 것

→ 클래스의 인스턴스 변수는 public 선언 X

→ 반복 구조의 제어 문장은 루프 안에서만 사용할 것

→ 문장은 한 줄에 하나씩 쓸 것

→ 값 리턴이 없는 문장은 괄호 사용 X

→ 복잡한 조건식 X

→ 조건에서 실행 문장 X

 

• 헤더 주석

→ 모듈 단위로 달린 주석

→ 컴파일 & 테스트 & 검증 & 수정에 유용

→ 헤더 주석에 포함되는 항목 : 모듈의 기능과 목적 / 외부 공개 인터페이스 / 인터페이스의 매개변수 / 매개변수에 대한 가정 / 제약 / 오류 메시지 / 변경 이력

 

• 내부 주석

→ 코드를 되풀이하는 주석은 쓰지 말 것

 

 

---

리팩토링 & 검토

 

• 리팩토링

→ 기능의 변경 없이 코드 디자인을 개선하는 것

→ 문제를 찾고 수정 및 재구조화

→ 코드 이해와 재사용성을 높임

→ 결합을 낮추고 응집을 높여야 함

→ 버그 찾기 & 프로그램 작성을 쉽게함

→ 소프트웨어의 디자인 개선 / 이해 용이

 

• 코드 스멜 ( 안좋은 코드 ) 

→ 설계를 수정하기 어렵게 만드는 코드

→ 중복 토드 / 긴 메소드 / 큰 클래스 / 많은 case / 긴 메소드 호출 (내비게이션) / 지나친 널 객체 확인 / 유사 데이터 중복 / 데이터 클래스 / 캡슐화되지 않은 필드

 

• 리팩토링 과정

1. 소규모의 변경 – 단일 리팩토링

2. 코드 작동 테스트

3. 작동이 잘되면 다음 것 리팩토링

4. 작동되지 않으면 문제 해결 및 리팩토링 undo를 통해 시스템 작동 유지

 

• 클래스 추출

→ 단일 클래스를 위한 리팩토링

 

• 인터페이스 추출

→ 외부에서 객체를 XML 직렬화하고 싶을 때 인터페이스로 분리

 

• 메소드 추출

→ 중복 없고 이해 쉽도록 메소드 리팩토링

 

• 검토

→ 인스펙션 : 수행 전 코드의 결함 / 비효율성 / 표준 불일치를 찾는 리뷰

→ 검토할 것 : 클래스 전체 / 속성 / 생성자 / 메소드 헤더 / 메소드 내부