8. 일반적인 프로그래밍 원칙

# 지역변수의 범위를 최소화 하라.

사이드 이펙트를 최소화하라. 미리 만들지말고 처음 쓰일때 선언하라.

지역변수를 돌려쓰지마라. 스코프를 최소화해서 한가지 기능에만 집중하라.

 

# for 문보다는 for-each를 사용하라.

인덱스 접근은 위험하고, 보기도 흉하다 😀

근데 지역변수를 수정하거나, break, continue 같은 분기가 없다면 for-each 말고 스트림과 람다를 활용하자.

ArrayList<String> numbers = new ArrayList<String>();
numbers.add("one");
numbers.add("two");
numbers.add("three");

for(String number: numbers) {
    System.out.println(number);
}

 

# 직접 만들기전에 알려진 라이브러리를 배우고 사용하라.

수많은 고민을 하고 점검을 마친 라이브러리를 사용하는 게 내 코드의 품질을 높이고, 개발 효율을 향상 시킬 수 있다.

 

 

# 부동소수점 오차를 생각하라.

float과 double은 근사치를 표현한다. 소수점은 정확하게 표현할 수 없다.

즉 0.001 * 1000 = 1 임을 보장할 수 없다. 정확한 소수값이 필요하다면 BigDecimal 객체를 사용하도록 하자.

public class Test {

    @Test
    public void 부정확한_double() {
        //given
        double doubleMoney = 1.03;

        //when
        double result2 = doubleMoney - 0.42;

        //then 실패
        assertThat(result2, is(0.61));//0.6100000000000001 나온다!
    }
}

 

 

# 박싱 (래퍼)타입보다는 기본 타입을 사용하라.

박싱 타입은 객체 참조 값을 가지고, null 값을 가질 수 있다.

하지만 그 만큼 객체를 만드는데 시간과 메모리를 낭비함을 유의하자. 성능은 기본타입이 가장 빠르다.

 

 

# 문자열을 막 사용하지 마라. 다른 타입이 적절하다면, 다른 타입을 사용하라.

모든걸 String으로 때려박지마라. 당연한거지만, 사용하기 번거롭고, t성능도 나쁘고, 덜 유연하고, 오류 가능성도 크다.

// 안쓸거 같지만, 실제 시스템에서 아래와 같은 코드는 흔하다.
String compoundKey = className + "#" + i.next();
String memberRole = "admin";

문자열을 대신 enum, 값 객체, 컬렉션등을 활용하라.

 

 

# 문자열 덧셈은 매우 느리다.

• 덧셈이후 사용하지 않는 문자열을 해제하지 않는다. GC의 일거리가 늘어난다.
• String은 상수풀에서 관리된다. '추가' 하는게 아니라 '새로운 문자열'을 만드는 게 덧셈이다.
• JDK1.5 부터는 StingBuilder로 변환해주긴하지만..가능하면 문자열을 만드는데 덧셈을 사용하지 말자
• 문자열을 씹고 뜯고해야한다면 StringBuffer와 StringBuilder를 사용하자. Builder는 단일 스레드용도이다.

 

# 객체는 인터페이스를 사용해 참조하라.

유연한 코드를 만드는 습관을 길러두자. 이는 직접 만든 클래스뿐만 아니라, 컬렉션을 사용할때도 마찬가지.

물론 인터페이스를 만드는 건 추가적인 비용이 들지만, 이미 만들어진 인터페이스를 사용하지 않을 이유는 없다.

//좋은 예. 인터페이스를 타입으로 사용했다
Set<Dog> dogSet = new LinkedHashSet<>();

//나쁜 예. 클래스를 타입으로 사용했다!!
LinkedHashSet<Dog> dogSet = new LinkedHashSet<>();

 

 

# 리플렉션보다는 인터페이스를 사용하라.

리플렉션은 런타임에 추가적인 작업을 하기에, 잘못사용하면 성능에 악영향을 끼치기 쉽다.

또한 컴파일의 타입검사 혜택을 받을 수 없으며, 코드가 지저분해지고 분석하기도 어려워진다.

 

리플렉션은 마법의 도구가 아니다. 인터페이스로 가능하다면, 리플렉션 대신 인터페이스로 구현하도록 하자.

// 리플렉션은 인스턴스 생성에만 쓰고, 이렇게 만든 인스턴스는 인터페이스나 상위 클래스로 참조해 사용.
// 이렇게 꼭 필요한 부분에만 사용하고, 인터페이스로 대체가능하면 인터페이스를 사용하자.
 @Test
public void test() {
    Class<?> cl = null;

    try {
        cl = Class.forName("java.util.HashMap");
    } catch (ClassNotFoundException e) {
        e.printStackTrace();
    }

    Map<String, String> map = null;

    try {
        map = (Map<String, String>) cl.newInstance();
    } catch (InstantiationException e) {
        ...
    } catch (IllegalAccessException e) {
        ...
    }

    map.put("이름", "hashMap");

    System.out.println(map.get("이름"));
}

 

 

# 네이티브 메서드는 신중하게 사용하라.

자바에는 다른 코드로 작성된 메서드를 사용하는 네이티브 메서드와 JNI(자바 네이티브 인터페이스)가 존재한다.

JNI (Java Native Interface)를 구현한 C언어 메서드.

public class JNI {
    
    static {
        System.loadLibrary("JNI");
    }
    
    private native int getNumber();
    private native void printHelloWorld();
    
    public static void main(String[] args){
        JNI jni = new JNI();
        
    
        jni.printHelloWorld(); //JNI로 호출 한 HelloWorld!
        
        System.out.println(jni.getNumber()); //JNI로 호출 한 숫자 메서드
    }
}

하지만 성능을 개선할 목적이 아니라면, 굳이 사용할 필요가 없다. 사용하지 마라.

사실 성능이 목적이라도, 사용해도 성능이 개선되지 않는 경우가 더 많다. 어쩔 수 없이 저수준 자원이나 운영체제(C언어) API 를 사용하기위해 쓴다고 해도 네이티브 메서드는 최소한으로 사용하라. 네이티브 메서드에서 버그가 생기면 답없다. 못찾는다.

 

 

# 최적화는 신중하게 하라.

성능 때문에 견고한 구조를 희생하지마라.

빠른 프로그램보다 좋은 프로그램을 작성하라.

https://www.youtube.com/watch?v=bIeqAlmNRrA&t=3030s 

프로젝트를 리펙토링을 하다보면, 기존의 레거시코드 (객체지향이 적용되지않은 더러운 코드)가 성능이 더 좋은 경우가 많습니다. 더 유연하고 좋은 코드를 만드는게 맞는지, 아니면 그냥 레거시 코드를 남겨두는게 맞는지 고민됩니다.

실제로 리펙토링을 하다보면 성능에 이슈가 생기는 경우가 있습니다. (그만큼 객체가 더 사용되니까)
하지만 생각해보세요. 여러분들이 새로운 서비스를 만들고, 런칭했을 때 그런걸로 성능 이슈가 발생할만큼 많은 고객이 올까요?

인텔의 무어의 법칙이란 말이 있듯이, 하드웨어는 말도안되는 속도로 발전하고 저렴해지고있습니다.
하지만 개발자의 인건비는 반대로 상승하고 있죠. 그렇기 때문에 가독성이 높고 확장가능하고, 다른 개발자가 오더라도 사용할 수 있는 유연한 코드를 만드는게 더 중요합니다.

사실 운영을 하다가 성능이슈는 DB SQL이나 외부 API에서 생기는게 대부분이지, 레거시 코드를 객체로 감싸서 성능에 큰 영향을 끼치는 경우는 거의 없습니다.

물론 여러분의 서비스가 구글, 페이스북처럼 어마어마한 인스턴스가 만들어지는 대규모 서비스라면 성능에 영향을 끼치겠지만, 그건 그때가서 레거시코드로 만들면 됩니다. 그 시점에는 회사가 엄청 크고 이미 담당 팀이 있을거니까 고민할 문제도 아닙니다.

트레이드 오프를 생각하세요. 코드의 유연성, 유지보수성, 가독성을 포기할만큼의 성능 향상이 있습니까?

 

 

# 일반적으로 통용되는 이름(명명)규칙을 사용하라.

2021.06.30 - [🌱Backend/Java] - # 2. Java Naming Conventions

# 2. Java Naming Conventions