이팩티브 자바 따라하기

 

 

 

 

요즘 여유가 생겨서 한달 전에 사놨던 이펙티브 자바를 읽기 시작했다. 책에는 아이템이 90개 정도 있는데 1번 부터 순서대로 읽어보고 내 블로그 만들기 프로젝트에 적절한 내용이면 아이템들을 적용하는 방식으로 공부하려고 한다. 하루에 아이템 3개씩 하면 괜찮지 않을까 예상해본다. 일반 자바 책보다 내용이 깊고 생각해야할 부분이 많아서 아이템 3개도 많다. 유지만 하면 30일 만에 책 한권을 끝낸다는 목표이다.

 

 

 

아이템 1. 생성자 대신 정적 팩터리 메서드를 고려하라

-> 이미 전부다 빌더 패턴을 사용하고 있어서 생성자는 사용하고 있지 않다.

-> 기본 생성자는 사용하지 않는 경우 protected로 설정해서 사람들이 해당 클래스는 생성할 수 없다는 것을 인식하도록 하자.

 

아이템 2. 생성자에 매개변수가 많다면 빌더를 고려하라

-> 이미 매개변수가 별로 없을때도 통일성을 위해 빌더 패턴을 사용하고 있다.

 

아이템 3. private 생성자나 열거 타입으로 싱글턴임을 보증하라

-> 스프링에서 @Bean과 같은 싱글턴으로 관리해주는 기능 및 어노테이션들을 사용하고 있어서 딱히 적용할 부분이 없다.

 

아이템 4. 인스턴스화를 막으려거든 private 생성자를 사용하라

-> 따로 유틸리티 클래스가 없어서 적용할 부분이 없다.

 

아이템 5. 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라

-> 무슨 뜻인지는 알겠으나 대부분 스프링이 알아서 해주기 때문에 적용할 부분이 없음.

 

아이템 6. 불필요한 객체 생성을 피해라

-> 왠만하면 new로 생성하지 말고 정적 팩터리 메소드로 가져와라는 의미로 해석했으며 이미 적용되어 있음.

 

아이템 7. 다 쓴 객체 참조를 해제하라

-> 자기 메모리를 직접 관리하는 클래스라면 항상 메모리 누수에 주의해야한다. 해당 프로젝트에서는 그런 클래스는 없어서 적용할 부분이 없다.

 

아이템 8. finalizer와 cleaner 사용을 피하라

-> 사실 지금까지 사용한 적이 없고 불필요한 부분 같아서 건너뛴다.

 

아이템 9. try-finally보다는 try-with-resources를 사용하라

->  지금까지 자원을 직접 회수하는 코드는 소홀히 했는데 자원을 회수하지 않아서 직접적으로 타격을 받은 경험이 없었다. 하지만 글을 읽으면서 조금 더 조심해야겠다는 생각이 들었다. 다행히도 해당 프로젝트는 dto로 모든 입력 데이터를 가져오기 때문에 자원 회수는 신경쓸 필요가 없는 듯 하다.

 

아이템 10. equals는 일반 규약을 지켜 재정의하라

-> 왠만하면 Object의 equals가 원하는 비교를 수행해주므로 만약에 equals를 재정의 할 일이 생기면 5가지 규약을 지켜야겠다.

 

아이템 11. equals를 재정의하려거든 hashCode도 재정의하라

-> 귀찮으니 AutoValue 어노테이션을 사용하면 편하다고 한다.

 

아이템 12. toString을 항상 재정의하라

-> 프로그램 덩치가 클 때는 유용할 것 같으나 현재 프로젝트에는 필요성이 안느껴짐.

 

아이템 13. clone 재정의는 주의해서 진행하라

-> 현재 프로젝트에서 clone은 사용할 일이 없어서 나중에 공부할 예정.

 

아이템 14. Comparable을 구현할지 고려하라

-> 프로젝트에서는 아직까지 객체끼리 compareTo로 비교할 일이 없었다.

-> 코딩 테스트에서 우선순위 큐를 사용할 때 유용하게 사용 중이다.

 

아이템 15. 클래스와 멤버의 접근 권한을 최소화하라

-> 최대한 public을 제거하자.

 

아이템 16. public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라

-> 이미 그렇게 사용 중이다.

 

아이템 17. 변경 가능성을 최소화하라

-> 이유가 없으면 무조건 private final을 사용하라는 내용이다.

 

아이템 18. 상속보다는 컴포지션을 사용하라

-> 이 부분은 중요한 것 같다. extends 처럼 상속으로 구현하면 결합도가 증가하므로 유지보수가 힘들다. 상속 보다는 하위 클래스에 상위 클래스 객체를 생성하여 내부에 포함하자.

 

아이템 19. 상속을 고려해 설계하고 문서화하라. 그러지 않았다면 상속을 금지하라

-> 상속은 왠만하면 사용하지 않는게 좋은 것 같다.

 

아이템 20. 추상 클래스보다는 인터페이스를 우선하라.

-> 뭔가 복잡해서 나중에 다시 공부하는 게 좋을 것 같다.

 

아이템 21. 인터페이스는 구현하는 쪽을 생각해 설계하라.

-> 디폴트 메서드로 기존 인터페이스에 추가적인 메서드를 넣을 수 있지만 어떤 위험이 발생할 지 모르니 지양하자.

 

아이템 22. 인터페이스는 타입을 정의하는 용도로만 사용하라

-> 상수 공개용 수단으로 사용하는 바보 같은 짓은 하지 말자.

 

아이템 23. 태그 달린 클래스보다는 클래스 계층구조를 활용하라

-> 태그 달린 클래스는 쓸 생각도 안했다.

 

아이템 24. 멤버 클래스는 되도록 static으로 만들라

-> 무슨 소린지 잘 모르겠다. 나중에 다시 공부하자.

 

아이템 25. 톱레벨 클래스는 한 파일에 하나만 담으라

-> 이미 그렇게 하고 있다.

 

아이템 26. 로 타입은 사용하지 말라

-> 사용할 생각을 해본 적이 없다.

 

아이템 27. 비검사 경고를 제거하라

-> 비검사 경고는 중요하니 무시하지 말자

-> 조금 뜨끔했지만 다행히 현재 프로젝트에는 aws 환경 문제로 인한 경고를 제외하고 비검사 경고는 없다.

-> @SuppressWarnings("unchecked") 어노테이션은 가능한 범위를 좁히자.

 

아이템 28. 배열보다는 리스트를 사용하라

-> 같이 섞어쓰면 에러가 발생할 확률이 높다는데 굳이 두 개를 섞어쓰는 사람이 있는지는 잘 모르겠다.

 

아이템 29. 이왕이면 제네릭 타입으로 만들라

-> 제네릭 타입이 안전하고 쓰기 편하니 제네릭을 즐겨 사용하자.

 

아이템 30. 이왕이면 제네릭 메서드를 만들라

-> 제네릭이 컴파일 할 때 오류도 다 나오고 좋으니 많이 쓰자.

 

아이템 31. 한정적 와일드카드를 사용해 API 유연성을 높이라

-> 이것도 나중에 공부할 예정

 

아이템 32. 재네릭과 가변인수를 함께 쓸 때는 신중하라

-> 그냥 안 쓸 예정

 

아이템 33.  타입 안전 이종 컨테이너를 고려하라

-> 잘 모르겠으니 나중에 공부

 

아이템 42. 익명 클래스보다는 람다를 사용하라

-> 코딩 테스트를 할 때 자주 람다를 사용하고 있다.

 

아이템 43. 람다보다는 메서드 참조를 사용하라

-> 사실 람다만 해도 충분하긴 하지만 극도의 간결한 코드를 위해 메서드 참조를 조금씩 공부해야겠다.

 

아이템 44. 표준 함수형 인터페이스를 사용하라

-> 나중에 공부하자.

 

아이템 45. 스트림은 주의해서 사용하라

-> 그냥 최대한 가독성 좋게 적절하게 사용하자.

 

아이템 46. 스트림에서는 부작용 없는 함수를 사용하라

-> 스트림을 조금 공부해야겠다.

 

아이템 47. 반환 타입으로는 스트림보다 컬렉션이 낫다

-> 추후에 공부해야겠다.

 

아이템 48. 스트림 병렬화는 주의해서 적용하라

-> 추후에 공부해야겠다.

 

아이템 49. 매개변수가 유효한지 검사하라

-> @throws 자바독 태그로 문서화를 할 수 있다고 한다.

 

아이템 50. 적시에 방어적 복사본을 만들라

-> 매개변수가 가변이라면 해당 값을 방어적 복사를 통해 안전하게 사용할 수 있다.

 

아이템 51. 메서드 시그니처를 신중히 설계하라

-> 메서드 이름을 신중히 짓고 편의 메서드를 너무 많이 만들지 말고 매개변수 목록은 짧게 유지하자.

 

아이템 52. 다중정의는 신중히 사용하라

-> 왠만하면 사용하지 말자

 

아이템 53. 가변인수는 신중히 사용하라

-> 성능이 중요한 경우가 아니면 그냥 사용하지 말자

 

아이템 54. null이 아닌, 빈 컬렉션이나 배열을 반환하라

-> 그렇다. null을 반환하면 프론트에서도 처리하기 힘들고 에러가 발생할 확률이 증가한다.

 

아이템 55. 옵셔널 반환은 신중히 하라

-> 반환값이 없으 가능성을 염두해야 하는 경우에는 옵셔널이 필요하지만 성능 저하가 뒤따르니 이외의 상황에서는 사용하지 말자. 옵셔널은 반환값 이외의 용도로 쓰는 경우는 거의 없다고 한다.

 

아이템 56. 공개된 API 요소에는 항상 문서화 주석을 작성하라

-> 이건 나중에 필요하면 공부하자.

 

아이템 57. 지역변수의 범위를 최소화하라.

-> 처음에 지역변수를 전부 다 선언하지 말고 사용하기 직전에 선언해야 에러 발생 가능성이 줄어든다.

 

아이템 58. 전통적인 for 문보다는 for-each 문을 사용하라.

-> 인덱스를 사용해야 하는 경우에는 일반적인 for 문을 사용하고 외에는 for-each 문을 이용하면 더 예쁘고 에러 확률도 줄어든다고 한다.

 

아이템 59. 라이브러리를 익히고 사용하라.

-> 이미 노력 중이다.

 

아이템 60. 정확한 답이 필요하다면 float와 double은 피하라.

-> 이미 알고 있다.

 

아이템 61. 박싱된 기본 타입보다는 기본 타입을 사용하라.

-> 박싱된 기본 타입은 언박싱을 하면서 예상 못한 에러가 발생할 수 있다.

-> 따라서 2개 중 하나를 선택해야 한다면 가능하면 기본 타입을 사용하자.

 

아이템 62. 다른 타입이 적절하다면 문자열 사용을 피하라.

-> 문자열을 너무 많이 사용하는 경향이 있어서 되도록이면 필요한 경우에만 사용하자.

 

아이템 63. 문자열 연결은 느리니 주의하라.

-> 문자열은 불변이라서 대신 StringBuilder의 append 메서드를 사용하자.

 

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

-> 이전에 나도 클래스를 타입으로 사용했던 것 같은데 다행히 요즘은 인터페이스를 타입으로 사용한다.

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

-> 리플렉션을 쓸 일이 없을 것 같아서 나중에 필요하면 추가로 공부해야겠다.

 

아이템 66. 네이티브 메서드는 신중히 사용하라

-> C언어느 C++ 메서드를 호출하는 기능인데 지금은 딱히 신경 안써도 될 것 같다.

 

아이템 67. 최적화는 신중히 하라

-> 최적하는 하지마라.

 

아이템 68. 일반적으로 통용되는 명명 규칙을 따르라

-> 노력 중이다.

 

아이템 69. 예외는 진짜 예외 상황에만 사용하라

-> 예외는 제어 흐름에서 사용해서는 안된다. 이 부분은 아직 프로젝트에 예외 처리가 제대로 되지 않아서 이후 적용할 예정이다.

 

아이템 70. 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라

-> 복구할 수 있는 상황에는 프론트에게 어떤 예외가 발생했는지 알리고 복구할 수 있도록 도와주고 판단하기 힘든 경우 그냥 런타임 예외를 던지고 프로그램을 종료해야 한다는 것으로 이해했다.

 

아이템 71. 필요 없는 검사 예외 사용은 피하라

-> 일단 잘 모르겠으면 비검사 예외를 던지자.

 

아이템 72. 표준 예외를 사용하라

-> 커스텀 예외를 최대한 줄이면 될 것 같다.

 

아이템 73. 추상화 수준에 맞는 예외를 던지라

-> 아직까지는 추상화 수준에 맞는 예외를 판별할 단계는 아닌 것 같아서 나중에 공부할 예정이다.

 

아이템 74. 메서드가 던지는 모든 예외를 문서화하라

-> 예외를 문서화하는 것은 처음 알게 된 사실인데 이번에 한번 적용해볼까 한다.

-> 현재 예외를 공통 상위 클래스 하나로 뭉뚱그려 선언하는 느낌인데 이것도 해결할 예정이다.

 

아이템 75. 예외의 상세 메시지에 실패 관련 정보를 담으라

-> 이미 적용 중인 부분이다.

 

아이템 76. 가능한 한 실패 원자적으로 만들라

-> 에러가 발생해도 최대한 복구 가능하더록 설계하라는 내용이다. 예를 들면 미리 유효성 검사를 한다든지 위험한 코드들은 객체의 상태를 바꾸는 코드보다 앞에 배치한다던지 복사본에 저장 후 데이터를 가져오는 등 여러 방법이 있다.

 

아이템 77. 예외를 무시하지 말라

-> 그런 프로그래머들이 종종 있는 듯 하다.

 

아이템 78. 공유 중인 가변 데이터는 동기화해 사용하라

-> 동기화 관련해서는 필요성을 잘 모르겠다. 그냥 스프링 @Transactional 어노테이션을 사용하면 될 것 같다.

 

아이템 79. 과도한 동기화는 피하라

-> 동기화는 꽤 어려우니 지양하자.

 

아이템 80. 스레드보다는 실행자, 태스크, 스트림을 애용하라

-> 교수님도 스레드는 어렵다고 했다. 실행자를 지향하자.

 

아이템 81. wait와 notify보다는 동시성 유틸리티를 애용하라

-> 웹 프로그래밍에서 딱히 본 적이 없어서 나중에 필요하면 공부하겠다.

 

아이템 82. 스레드 안정성 수준을 문서화하라

-> 스레드를 사용하는 프로그램은 앞으로도 딱히 경험하지 못할 것 같다.

 

아이템 83. 지연 초기화는 신중히 사용하라

-> 대부분의 상황에서 일반적인 초기화가 지연 초기화보다 낫다고 한다.

 

아이템 84. 프로그램의 동작을 스레드 스케줄러에 기대지 말라

-> 나중에 공부하자.

 

아이템 85. 자바 직렬화의 대안을 찾으라

-> 직렬화를 해본 경험이 없어서 중요성을 잘 모르겠다.

 

아이템 86. Serializable을 구현할지는 신중히 결정하라

-> 자바 스프링에서 jackson 라이브러리를 이용하여 json으로 직렬화하고 역직렬화도 하기 때문에 딱히 건드릴 일이 없다.

 

아이템 87. 커스텀 직렬화 형태를 고려해보라

-> 나중에 필요하면 공부하자.

 

아이템 88. readObject 메서드는 방어적으로 작성하라

->  만약 readObject 메서드를 작성할거면 신중하게 해야한다는 것인데 이것도 필요하면 공부하자. 

 

아이템 89. 인스턴스 수를 통제해야 한다면 readResolve보다는 열거 타입을 사용하라

-> 뭔 소린지 모르겠다 다음에 공부하자.

 

아이템 90. 직렬화된 인스턴스 대신 직렬화 프록세 사용을 검토하라

-> 직렬화 관련해서는 필요하면 공부하자.