모르는 단어
LoC :Line of Code
유지보수성 (maintainability): 어떤 시스템을 얼마나 효율적/효과적으로 고칠 수 있냐 정도.
코드베이스 : 하나의 레퍼지터리에 저장된 소스코드 뭉치 컴파일 및 배포를 독립적으로 수행하는 단위.
기본개념.
일반화한 개념과 자바언어의 명칭
일반 명칭 |
일반적인 정의 |
자바 언어의 명칭 |
단위 Unit |
독립적으로 실행 가능한 코드 라인을 묶은 최소단위 |
메서드 또는 생성자 |
모듈 module |
가장 작은 단위 묶음 |
최상위 클래스, 인터페이스, enum |
컴포넌트 component |
소프트웨어 아키텍처에 따라 정의된 시스템 최상위 구성요소 |
|
시스템 System |
대상 코드 베이스 전체 |
|
- 컴포넌트
: 시스템 소프트웨어 아키텍처 수준에서 식별 된 최솽위 수준의 빌딩 블록. 블록-화살표 시스템 다이어그램에서 블록.
아주 소규모 자바시스템이면 컴포넌트 피키지 관계가 1:1일지 몰라도 제법 규모가 있는 시스템에서는 패키지가 컴포넌트보다 훨씬 많다.
Apache Ant - target 이라는 묶음개념
메이븐 -pom.xml
1장. 들어가며
- 소프트 웨어의 품질 8가지 : 유지보수성, 기능 안정성, 성능 효율성, 호환성, 사용성, 믿음성, 보안성, 휴대성
- 소프트 웨어 유지보수 네가지
: 교정형 유지보수(corrective maintenance: 버그발견 수정),
적응형 유지보수(adaptive maintenance: 운영변화로 시스템 변경),
완료형 유지보수(perfective maintenance:시스템 사용자의 신/변경요건 반영)
예방형 유지보수(preventive maintenance: 품질을 높이고 앞으로 닥칠 버그를 방지할 방안을 모색)
- 유지보수 3대 원칙
1. 단순한 가이드 라인을 지키기만 해도 유지보수성은 나아진다.
2. 유지보수성은 개발 프로젝트 시작 단계부터 반드시 염두에 두어야 하고 하나씩 실천하는 자세가 중요하다.
: 깨진 창문효과 (깨진 창문 방치시 흉악범더 더 발생)
3. 가이드 라인을 따를 것.
- 유지 보수 가이드 라인 10개
1. 코드단위를 짧게 하라
: 코드 단위는 15라인을 넘지 않게 작성
: 작은 단위는 이해하고, 테스트하고, 재사용하기 쉬워 유지보수성이 좋아진다.
리펙터링 기법 1 : 메서드 추출 : 단위 코드가 스스로를 설명하는 상태
리펙터링 기법 2 : 메서드를 메서드 객체로 대체
2. 코드 단위를 간단하게 짜라
: 단위당 분기점은 4개로 제한한다(멕케브 복잡도, 순한 복잡도 5로 제한:4+1). 복잡한 단위는 더 잘게 나누고 서로 뭉쳐있지 않게 한다.
리펙터링 기법 3 : 중첩문을 보호절로 데체: .
3. 코드는 한번만 작성하라
: 코드는 복사하지 않는다. (6라인 이상 동일하면 클론코드)
CMD: 소스 분석 툴 PMD에 포함된 클론 감지 툴
리펙트링 기법 4 : 상위 클래스 추출
4. 단위 인터페이스를 작게 하라 ----인터페이스 > 매개변수..
: 단위당 파라미터 개수는 4개 이하로 제한한다.
리펙터링 기법 5 : 파라미터 객체 도입 : 파라미터를 객체로 추출한다.
5. 관심사를 모듈로 분리하라. ----모듈 > 클래스
: 모듈 간 결합을 느슨하게 하기 위해 큰 모듈은 삼가한다.
1)개별 모듈로 나누어 일을 시키고 구현 상세는 인터페이스 안으로 감춘다. >> 클래스를 기능별로 세분화 한다.
2) 특정 구현부는 인터페이스 안에 숨긴다.
3) 커스텀 코드를 서드파티 라이브러리/ 프레임워크로 대체
6. 아키텍처 컴포넌트를 느슨하게 결합하라
: 최상위 수준의 컴포넌트간 결합도를 낮춘다.
사용자 인터페이스 > 서브스 계층 > 비지니스 로직 계층 > 데이터 추상화 계층 > 데이터 베이스 계층
7. 아키텍처 컴포넌트 균형을 잡아라.
: 최상위 수준의 컴포넌트 개수와 상대적 크기를 균형 잡는다.
: 컴포넌트 개수가 9개정도(6~12) 되도록 소스코드를 조직화 하고 컴포넌트 크기를 대략 균등학 맞춘다.
8. 코드베이스를 작게 하라
: 시스템이 클수록 망가질 확률은 커진다. 시스템 크기를 적극적으로 줄인다.
9. 테스트를 자동화 하라
: 테스트 프레임워크로 자동화한 테스트를 작성한다. 예측 가능한 리스크 적은 개발
유형 |
테스트 대상 |
목적 |
주체 |
단위테스트 |
따로 분리한 하나의 단위기능 |
단위코드가 의도대로 작동하는지확인 |
개발자(해당단위 개발자) |
통합테스트 |
적어도 두 클래스 이상의 기능, 성능, 기타 품질 특성 |
시스템을 이루는 요소들이 함께 잘 작동하는지 확인 |
개발자 |
종단테스트 |
시스템 연동-사용자 또는 다른 시스템과의연동 |
시스템이 의도한 대로 작동하는지확인 |
개발자 |
회기 테스트 |
이전에 에러가 났던 다위 클래스 시스템연동 부분의 로직 |
버그가 다시 나타나지 않는지 확인 |
개발자 |
인수 테스트 |
시스템연동- 사용자 또는 다른 시스템과 연동 |
시스템이 의도한 대로 작동하는지 최종 승인 |
고객인수팀(개발자는 무조건 제외) |
10. 클린코드를 작성하라.
1) 단위 수준의 코드 악취를 남기지 마라
2) 나쁜 주석을 남기지마라
3) 주석 안에 코드를 남기지 마라
4) 죽은 코드를 남기지 마라
5) 긴 식별자 이름을 남기지 말라
6) 매직 상수를 남기지 마라
7) 제대로 처리 안한 예외를 남기지 말라