TDD

Test 중요성

단위테스트, 통합테스트, 회귀테스트, 시스템 테스트, 

**테스트 코드는 소스코드처럼 형상관리가 중요하다.

 

TDD, Extream Programming. 

테스트 코드가 없다면, 소스 코드에는 버그가 있다.

 

깨끗한 테스트 코드

- fast 빨라야한다.

- indenpendent 다른 테스트 케이스와 독립적이어야 한다

- repeatable 반복가능해야한다. (test data, test code, 수행환경)

- self-validating 테스트 결과를 제공해야한다.

- timely 테스트는 구현 직전에 작성해야한다.

http://junit.sourceforge.net/javadoc/

JUnit API

 

 

성능 향상

환경적 문제

- ㅇㄴ프라

- 디스트 IO 처리 속도

- 네트워크 응답 지연

- 매모리 부족

- JVM 힙 메모리 부족

 

설계상의 문제

- 지나친 DB join 발생

- DB table Lock

- 배치 작업 경합

- 구간별 잦은 통신, 중복 호출

 

구현상의 문제

- 메모리 누수 현상

- heap 메모리 과다 사용

- 불필요한 동기화

- 대용량 데이터 일괄처리

 

레이어 간의 통신,, 

로컬에서 보다는 느릴 수 밖에 없다..

 

아키텍쳐 관점 성능향상 고려한 개발 원칙

-> 레이어 간의 통신 횟수, 량을 줄여야 한다.

    UI 에서 서버에 접근을 한다고 하면 ,,  정말 필요한 경우에만 가져오고, 가능하면 한거번에..

    자주 필요한 애들은 캐쉬, 사용자 정보(application 단)은 세션에

    SELECT *  사용 금지.. 정말 필요한 항목만 가져와 호출 최소화 (레이어간의 호출 횟수, 사이즈 최소화)

-> 비동기 처리 

    비동기 처리: 요청을 큐에 담아두고, 순서에 따라 처리

    분할처리: 대용향 데이터를 일정 크기의 버퍼단위로 버퍼링 처리

    페이징처리: 먼저 조회된 정보를 우선 제공

 

프로그램 관점 성능향상 고려한 개발 원칙

-> 메모리 사용 최소화

    미사용 변수, 메소드 정리, 루프 내 객체 생성, 메서드 호출 최소화,

    객체 생성 후 자원 래제 처리, 파일객체, 디비 커낵션 객체

-> 비동기 처리

    대용량 파일, 데이터 등 버퍼링으로 분할 처리하거나 페이징 

 

 

대용량 비치 관점에서 성능향상 고려한 개발 원칙

-> 일괄처리, 병렬처리(배치 프로그램)

    나누어 동시에 처리. (동시성 제어)

    배치 작업 시간 : 온라인 서비스 시간 제외, 야간 배치    

    배치기동기서버 분리

    버퍼 단위 DB Commit .. 5천건에서 만건 사이가 적절..

 

소나소나

# WEB SERVER

sonar.web.host=127.0.0.1
# Web context. When set, it must start with forward slash (for example /sonarqube).
# The default value is root context (empty value).
sonar.web.context=/sonarqube
# TCP port for incoming HTTP connections. Default value is 9000.
sonar.web.port=900

 

StartSonar.exe 실행

http://localhost:9000/sonarqube/  로 접속