위에서 언급한 log4j 설정과 마찬가지로, src/test/resources 가 src/main/resources 보다 선행돼서 읽히기 때문에 src/main/resources 밑의 context 에 선언된 Bean 과 동일한 이름의 Bean이 src/test/resources 밑의 context 에 선언돼 있어도 상관이 없는 듯 하다.
[방법 2 : JNDI 바인딩]
1) SpringJUnit4ClassRunner 를 상속받는 ExtSpringJUnit4ClassRunner 작성.
실제로 기존에 해왔던 프로젝트들을 돌이켜 봤을 때, 아무 의미 없는 숫자들로 따져있는 공통코드 및 클래스/함수 명이 상당히 많이 존재했다. 이런 코드들은 외워지지도 않고 프로젝트 내내 개발자들이 명세서를 찾아봐야 하는 엄청난 수고를 하게 만든다. 또한 명세서를 필요 이상으로 철저히 관리 해야하는 스트레스를 받게 한다.
분류가 애매하거나 코드값이 너무 많아 숫자로 분류하는 것은 어쩔 수 없겠으나, 그렇지 않은 경우엔 최대한 삼가해야 한다고 본다.
실제로 다음은 TV광고까지 진행됐던, 국내 최대 통신사 중 하나의, 동접자 2천명 이상의 아이돌 방송 관련 프로젝트를 수행할 때 사용한 공통코드이다. (코드값을 정의한 PM님을 설득하지 못해 어쩔 수 없이 사용했다...)
LV00 : 카메라촬영
LV11 : 앱촬영
MT00 : 멀티뷰카메라촬영
MT11 : 멀티뷰앱촬영
VR00 : VR카메라촬영
VR36 : VR앱촬영
아무 의미 없는 숫자들이 사용됐으며 규칙성 또한 존재한다고 보기 힘들다.
그렇다보니 프로젝트 내내 코드값 의미하는 바가 헷갈려 매번 명세서를 찾아보아야 했다.
위와 같은 코드 값은 아래와 같이 수정할 수 있다.
LVCAM : 카메라촬영
LVAPP : 앱촬영
MTCAM : 멀티뷰카메라촬영
MTAPP : 멀티뷰앱촬영
VRCAM : VR카메라촬영
VRAPP : VR앱촬영
위와 같이 네이밍은 작업능률을 올리고 유지보수성을 높이기 위해 가장 중요하고 따르기 쉬운 규칙이지만,
실제론 가장 지켜지지 않고 있는 악습이라고 생각한다.
2. 함수
인자값은 적을수록 좋다(단항함수가 최고)
인자값이 너무 많을 경우 객체를 인자값으로 받도록 설계한다
함수는 하나의 기능만 수행하도록 해라
위에서 아래로 읽히도록 해라
boolean 값을 인자값으로 받느니 함수를 별도로 만들어라
※ 실사례
//boolean 을 인자값으로 취하는 메소드 (부적절) public JsonObject httpUrlConnection(boolean isJson, String targetUrl, String method){}
//boolean 을 인자값으로 받는 대신 아래와 같이 메소드 두개로 분리 (적절) //isJson 이 false 일 때 사용하는 메소드 httpUrlConnection(String targetUrl, String method){} //isJson 이 true 일 때 사용하는 메소드 httpUrlConnectionJsonBody(String targetUrl, String method){} 위 함수 2개로 처리
코드결과값보단 예외를 활용하라
※ 실사례
//boolean 을 리턴하는 코드 (부적절) public boolean ftpFileUpload(...){ return ftpClient.storeFile(remoteFilePath, inputStream); } //예외를 던지는 코드 (적절) public void ftpFileUpload(...) throws Exception{ try{ ftpClient.storeFile(remoteFilePath, inputStream); } catch(Exception e) { logger.error(e.getMessage); throw e; } }
3. 주석
주석을 많이 달 시간에 소스 리팩토링을 하라
주석까지 현행화되는 경우는 드물다, 주석을 믿지 말라
정규식, 리턴타입 에 대한 설명, TODO 에 대한 주석은 유용하다(상식적으로 필요한 주석만 달라는 의미같다)
4. 형식 맞추기
논리적으로 비슷한 함수끼리 모아서 작성.
함수 1에서 함수2를 호출한다면, 함수1 바로 밑에 함수2를 작성하여 신문읽듯 코드를 읽을 수 있게 작성하라. (호출되는 함수를 호출하는 함수에 가까이 작성)
마찬가지로 변수선언은 사용하는 위치와 최대한 가까이 둔다. (예외로 멤버변수는 최상단에 놓는게 관습)
적절한 행구분은 필수(새로운 개념/논리는 행구분을 하여 끊어주자).
팀 내 형식 규칙을 따를 것
5. 객체와 자료구조
객체는 자료(멤버변수)를 숨기고(private) 함수는 공개(public)한다. (캡슐화)
자료구조는 자료는 공개하고 함수는 숨긴다.
6. 오류 처리
오류코드 정의 및 리턴보단 try catch 문을 사용하라
null을 주고받지 말라 (nullpointerexception 방지 및 불필요한 null 체크 생략이 가능)
7. 경계
학습테스트(외부라이브러리(ex: log4j, aspectj 등)의 충분한 연습과 학습)의 중요성
Adapter 패턴(캡슐화)을 사용하여 외부라이브러리가 직접적으로 사용되지 않도록 하자
8. 단위테스트
1) 실패 케이스 부터 작성
2) 실패를 통과하는 실제 코드 작성
테스트는 한번에 1개의 개념만 테스트
assert 문도 가급적 한개만 사용하도록 테스트코드 작성
9. 클래스
1) SRP : single responsibility principal/단일 책임원칙
클래스는 한 가지 기능(역할)만 해야 한다.
2) 응집도(Cohesion)가 커야 좋다
인스턴스 변수를 여러 메소드에서 사용해야 응집도가 높다 할 수 있다.
인스턴스 변수가 많다면? 클래스가 분리되어야 한다는 의미(클래스는 작을 수록 좋다)
3) OCP : open closed principle
확장에 개방적이고 수정에 폐쇄적이어야 한다
10. 동시성(멀티스레드)
[방어전략]
1) 동시성코드는 타 코드와 분리 (SRP)
2) 임계영역을 최소화(동기화 하는 부분을 최대한 작게)
3) 사본 사용(객체 복사)
4) 테스트
4-1) 단일 스레드에서 먼저 확인 후 멀티 스레드 작성
4-2) 보조코드(wait(), sleep(), yield() 등) 사용하여 테스트/AOF(aspect oriented framework), cglib 등과 같은 멀티스레드 테스트 도구 사용
4-3) 다양한 os에서 테스트
4-4) 프로세서 수보다 많은 스레드 테스트 (스와핑시 문제발생하는 경우가 존재)
* 스와핑 : 프로세스의 cpu 할당 시간이 끝나면, 메모리를 보조 기억장치(하드디스크)로 내보내고 다른 프로세스 메모리 불러 들이는 것
제네릭은 다양한 타입의 객체를 다루는 메소드 및 컬렉션 클래스를 컴파일 시, 타입 체크를 해주는 기능을 한다.
객체 타입을 컴파일 시에 체크하기 때문에 객체의 타입 안정성을 높이고 형변환의 번거로움을 줄인다.
※ ArrayList 같은 컬렉션 클래스는 다양한 종류의 객체를 담을 수 있지만, 보통 아래와 같이 한 종류의 객체를 담는 경우가 더 많다. 또한 꺼낼 때 마다 타입체크를 하고 형변환 하는 것은 아무래도 불편할 수 밖에 없는데, 제네릭이 이와 같은 불편함 들을 해소해준다.
List<Person> list = new ArrayList<>(); list.add(new Person("영심이")); list.add(new Person("홍길동")); list.get(0);
1. 제네릭 타입
타입을 파라미터(<T>)로 가지는 클래스 혹은 인터페이스
타입 파라미터(<T>) 를 클래스 혹은 인터페이스 명 뒤에 두어 선언
public class Sample<T>{} public interface Sample<T>{}
