Effective Java 제 9장 - 일반적인 프로그래밍 원칙

해당 게시물은 책 'Effective Java'를 참고하고 작성했습니다.

정확한 답이 필요하다면 float와 double과 같은 타입은 사용하지 마라!
해당 타입은 부동소수점 연산에 사용되며, 근사값으로 계산할 수 있게 설계된 타입이다.
금융 관련 계산에서는 절대 사용하면 안된다.

다수의 문자열을 잇는 연산을 할 때, 무조건 StringBuilder를 사용해라!
그냥 String 객체를 잇는 연산은 O(n^2) 복잡도를 가지고 있다.
String 객체는 내부 데이터를 불변의 형태로 지니고 있기 때문에 그러하다.
때문에 StringBuilder를 이용해서 성능을 높일 수 있다.

리플렉션 사용을 지양하라!
리플렉션을 이용하면 컴파일러에 의해 생성된 바이너리 파일를 사용하는 것이 아닌
JVM에 의해 생성된 바이트코드를 메모리 위에 올려서 사용하게 된다.
당연히 바이너리 파일을 사용하는 것이 아니기에 리플렉션은 기본적으로 성능이 떨어진다.
뿐만 아니라 '코드 가독성을 많이 저해'하고 '컴파일 타임 타입 검사의 이점'을 하나도 누릴 수 없다.
보안적으로도 캡슐화를 깨부수는 일이 많아지기에 사용하지 않는 것이 좋다.

네이티브 메서드의 사용에 유의하라!
Java의 구 버전들은 확실히 C언어에 비해 속도가 느렸다. 때문에 플랫폼 특화 기능을 사용하기 위해
네이티브 메서드를 사용해야 했다. 하지만, 최근 Java의 성능이 많이 개선되어 속도도 빨라지고
각종 네이티브 메서드들을 대체하는 기능을 내놓았다. 때문에 굳이 네이티브 메서드를 사용하지 않아도
된다.
뿐만 아니라 네이티브 메서드는 플랫폼 이식성이 많이 낮고 GC가 메모리 회수에 난항을 겪는다.
되도록 사용하지 않는 것이 좋다.

최적화를 성급하기 하지 마라!
최적화를 수행해도 어마무시하게 효율이 좋아지는 경우는 많지 않다.
조금의 성능 향상을 위해 코드 가독성을 해치거나 유지보수성을 희생시키지 마라!
왜냐면, 해당 API가 영구적으로 사용될지도 만무하고 말그대로 성능 대비 유지보수성 가성비가 나오지 않기 때문이다.
아키텍처 구조를 우선시하고 그 다음에 효율을 따져도 늦지 않다.

되도록 표준 명명 규칙을 지키자!
개발자의 소통을 위해 코드 컨벤션을 되도록 지키자.
패키지 모듈: Lower Snake Case
클래스, 인터페이스: Upper Camel Case
메서드와 필드, 지역변수: Lower Camel Case
상수 필드: Upper Snake Case
제네릭 타입 매개변수: T, U, E, K, V, X, R, T1, T2...