경험 많은 자바 개발자와 아키텍트가 조심해야할 10가지 함정

원문 : http://zeroturnaround.com/rebellabs/watch-out-for-these-10-common-pitfalls-of-experienced-java-developers-architects/

좀 오래된 글이긴 하지만 아직도 유효한 글인듯 싶어서 정리해 봅니다. 코드 예제는 원문의 링크에..

#10 Dependency Injection(이하 DI)의 잘못된 사용 혹은 잘못된 이해
DI를 이용하여 미리 정의된 객체를 삽입 하는 것 까진 좋지만 다른 객체의 초기화를 위해 의존성이 삽입 된 객체에 트레인 코드(. 연산자를 이용한 기차 처럼 길게 연결된 코드)를 사용하는 것과 같은 형태는 좋지 않다. 그냥 DI만 쓰시오..

#9 Java를 Perl을 사용하듯 쓰는경우
시스템이 커질수록 런타임 보다 컴파일 타임에 문제를 발견할 수 있는 것이 중요하다. 팩토리 형태의 코드의 매게변수로 스트링을 사용하게 되면 잘못된 스펠링의 변수가 전달되면 런타임에 문제가 발생하는 경우가 있다. 자바는 타입 언어이기 때문에 enum과 같은 타입을 이용하여 문제를 방지할 수 있다.

#8 OOP를 이해하지 못해 C를 사용하듯 자바를 쓰는경우
if-else와 instanceof를 통해 객체를 구분하여 캐스팅을 통해 이용하기 보다는 인터페이스나 추상 클래스의 상속과 메소드 오버라이딩을 이용하는 편이 코드가 간결하고 유지보수가 쉬워진다.

#7 객체의 라이프사이클을 이해하지 못해 과도하게 Lazy loading을 사용하는 경우
Lazy loading을 사용하지 전에 체크할 요소.
1. 정말 고비용의 객체인건가?(그것에 대해 어떻게 정의 할 것인가?)
2. 객체가 사용되지 않는 경우가 있어 생성되어 있을 필요가 없는가?

Lazy loading을 사용할 경우 해당 객체의 정확한 로딩 시점을 알아야 하기 때문에 디버깅을 힘들게 할 수 있어 디플로이 시점에 모두 로딩되게 하면 관련 이슈를 사전에 발견할 수 있다. 개인적으론 개발과 배포 시점의 구성을 다르게 가져가는 방법도 고민해 볼만하지 싶은.. 

#6 'Gang Of Four'(GOF) 책을 종교와 같은 수준으로 의존 하는 경우
책의 적절한 사용법은 서문에 나와있으니 참고하시오... 이미 안티패턴이 된 #5의 싱글턴과 같은 패턴도 있음..

#5 안티패턴이 된 싱글턴을 사용하는 경우
최근의 DI 프레임웍에선 더이상 사용할 필요가 없어짐.. (사실 Spring 프레임웍의 경우 빈 생성시 기본 조건이 싱글턴인..)

#4 메소드의 가시성을 무시하는 경우
public 메소드의 경우 가능한 작고 간결해야 하며 재사용 가능한 라이브러리를 작성하는 경우 이러한 점이 더 중요해진다. private 메소드로 지정 되어야 할 메소드가 단위 테스트를 위해 public으로 지정되는 케이스가 종종 있는데 이런 경우는 지양되어야 한다.

#3 NIH(Not Invented Here) 증후군이나 프로젝트에 특화된 StringUtils와 같은 것으로 고통받는 경우
충분히 테스트 된 현존 솔루션들을 활용하라. 예를 들면 Apache Commons, Guava, joda Date와 같은 것들이 있다. 특히나 익숙하지 않은 영역의 작업을 하게 될 경우 이런 점에 대한 사전 조사를 충분히 하자.

#2 환경에 의존적인 빌드
환경에 의존적인지 체크할 수 있는 시나리오..
1. 어느날 회사에 새 개발자인 톰이 왔다.
2. 톰에게 기본적인 설명을 하였고 설명을 들은 그는 자신이 좋아하는 개발 환경으로 세팅 했다
3. 톰은 소스 저장소로부터 소스를 체크아웃 한다.
4. 톰은 어떤 빌드 시스템을 이용하는지 파악 하는데 5분을 소모했다.
5. 톰은 단하나의 커맨드로 어플리케이션 빌드를 실행하고 그것은 성공했다.

조건을 만족하지 못한다면 문서화와 빌드시스템에 대해 다시 생각해볼 필요가 있다.

#1 리플렉션/인트로스펙션을 사용하는 경우
리플렉션은 이슈가 발생할 경우 이해하기 어렵게 하고 디버그가 힘들어지며 고치기 어렵게 만든다. 리플렉션을 사용하는 것은 시한 폭탄을 심는 것과 같다. 리플렉션을 사용하지 않더라도 잘 설계된 객체의 계층적 구조를 이용해 좀더 깔끔하게 해결할 수도 있다.

보너스 : 정말로 병목을 유발하는 요소가 어디인지 아는 경우에만 최적화를 시도하라
추측하지 말고 측정하라!
1. 현재 시스템을 유효한 측정 방법을 이용해서 벤치마크 하라
2. 변경을 가한다.
3. 다시 벤치마크 한다.
4. 가해진 노력과 퍼포먼스 향상 비율에 대해 평가한다