22.03.11. ~ 진행중..
- 이펙티브 자바는 레벨 1 필독서 중 하나로, 효율적인 자바 코드를 짜기 위한 솔루션들을 배울 수 있는 책입니다.
- 하지만 책의 모든 아이템을 정독하면서 테스트 해보고, 책의 예제 외에 적용할 수 있는 코드를 작성해 보는 것을 레벨 1 동안 혼자서 마치기란 쉽지 않습니다. 따라서 여러 사람이 함께 스터디하여 학습 효율을 높이고 레벨 1 동안 완독하는 것을 목표로 합니다.
- 지식은 자신만의 예시로 남에게 설명할 수 있을 때 비로소 자기 것이라고 생각합니다. 자신이 맡은 아이템에 대해 발표함으로써 학습의 깊이를 늘리는 것 또한 또 다른 목적입니다.
- 또한 맡은 아이템이 아니더라도 책을 읽으면서 이해가 가지 않는 부분에 대해 의문점을 가져보고, 다른 크루들과의 토론으로 의문을 풀어나가는 과정을 통해 효율적인 학습을 추구하고자 합니다.
- 책에서 이야기했다고 맹신하지 않기 🙏🏻
- 끊임없이 의심하는 과정속에서 학습하기 📈
- 다른 크루의 발표 내용 중 궁금한 게 있다면 납득 할 때까지 물어뜯기 🐶
- 엉뚱한 질문할까봐 두려워하지 않기 👊
- 뒤쳐지는 크루가 있다면 절대로 그냥 놔두지 않기 🚶🏻🚶🏻
- 매주 월, 금 18시에 오프라인 스터디를 진행한다.
- 매 스터디마다 1인당 이펙티브 자바의 1개 아이템에 대한 10분 이내의 발표를 진행한다.
- 발표자료의 형식은 자유이다. (md파일 작성한걸로 진행해도 무방)
- 매 스터디 전날 23:59까지 발표자료를 Pull Requests로 올린다.
- 발표는 2조로 나누어 진행한다.
- 스터디원을 절반으로 나누어 월요일에는 1조가, 금요일에는 2조가 진행한다. (1주일에 아이템 1개씩 발표)
- 조원들이 모두 발표를 마치면 질문을 받고 답변한다.
- 질문 사항에 대해 발표자가 잘 모르겠다면, Q&A 기간내에 추후 답변도 가능하다.
- 스터디가 끝나면 다른 조 발표일까지 Q&A를 진행한다.
- Q&A는 GitHub에 Issues 기능을 사용한다.
- 본인이 발표하지 않는 아이템도 반드시 읽고 이해가 되지 않는 부분에 대해 질문을 남긴다.
- 1. 생성자 대신 정적 팩터리 메서드를 고려하라 (제리)
- 2. 생성자에 매개변수가 많다면 빌더를 고려하라 (카피)
- 3. private 생성자나 열거 타입으로 싱글턴임을 보증하라 (트레)
- 4. 인스턴스화를 막으려거든 private 생성자를 사용하라 (콜리)
- 5. 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라 (우주)
- 6. 불필요한 객체 생성을 피하라 (리비)
- 7. [다 쓴 객체 참조를 해제하라]
- 8. [finalizer와 cleaner 사용을 피하라]
- 9. [try-finally보다는 try-with-resources를 사용하라]
- 10. equals는 일반 규약을 지켜 재정의하라 (제리)
- 11. equals를 재정의하려거든 hashCode도 재정의하라 (트레)
- 12. toString을 항상 재정의하라 (카피)
- 13. clone 재정의는 주의해서 진행하라 (우주)
- 14. Comparable을 구현할지 고려하라 (콜리)
- 15. 클래스와 멤버의 접근 권한을 최소화하라 (리비)
- 16. public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라 (제리)
- 17. 변경 가능성을 최소화하라 (트레)
- 18. 상속보다는 컴포지션을 사용하라 (카피)
- 19. 상속을 고려해 설계하고 문서화하라. 그러지 않았다면 상속을 금지하라. (콜리)
- 20. 추상 클래스보다는 인터페이스를 우선하라 (리비)
- 21. 인터페이스는 구현하는 쪽을 생각해 설계하라 (우주)
- 22. 인터페이스는 타입을 정의하는 용도로만 사용하라 (카피)
- 23. 태그 달린 클래스보다는 클래스 계층구조를 활용하라 (제리)
- 24. 멤버 클래스는 되도록 static으로 만들라 (트레)
- 25. 톱레벨 클래스는 한 파일에 하나만 담으라 (우주)
- 26. 로 타입은 사용하지 말라 (콜리)
- 27. 비검사 경고를 제거하라 (리비)
- 28. 배열보다는 리스트를 사용하라 (제리)
- 29. 이왕이면 제네릭 타입으로 만들라 (카피)
- 30. 이왕이면 제네릭 메서드로 만들라 (트레)
- 31. 한정적 와일드카드를 사용해 API 유연성을 높이라 (콜리)
- 32. 제네릭과 가변인수를 함께 쓸 때는 신중하라 (리비)
- 33. 타입 안전 이종 컨테이너를 고려하라 (우주)
- 34. int 상수 대신 열거 타입을 사용하라 (제리)
- 35. ordinal 메서드 대신 인스턴스 필드를 사용하라 (트레)
- 36. 비트 필드 대신 EnumSet을 사용하라 (카피)
- 37. ordinal 인덱싱 대신 EnumMap을 사용하라 (우주)
- 38. 확장할 수 있는 열거 타입이 필요하면 인터페이스를 사용하라 (콜리)
- 39. 명명 패턴보다 애너테이션을 사용하라 (리비)
- 40. @Override 애너테이션을 일관되게 사용하라 (카피)
- 41. 정의하려는 것이 타입이라면 마커 인터페이스를 사용하라 (트레)
- 42. 익명 클래스보다는 람다를 사용하라 (제리)
- 43. 람다보다는 메서드 참조를 사용하라 (리비)
- 44. 표준 함수형 인터페이스를 사용하라 (우주)
- 45. 스트림은 주의해서 사용하라 (콜리)
- 46. [스트림에서는 부작용 없는 함수를 사용하라]
- 47. 반환 타입으로는 스트림보다 컬렉션이 낫다 (카피)
- 48. 스트림 병렬화는 주의해서 적용하라 (제리)
- 49. 매개변수가 유효한지 검사하라 (리비)
- 50. 적시에 방어적 복사본을 만들라 (콜리)
- 51. [메서드 시그니처를 신중히 설계하라]
- 52. 다중정의는 신중히 사용하라 (제리)
- 53. 가변인수는 신중히 사용하라 (카피)
- 54. null이 아닌, 빈 컬렉션이나 배열을 반환하라 (트레)
- 55. 옵셔널 반환은 신중히 하라 (콜리)
- 56. 공개된 API 요소에는 항상 문서화 주석을 작성하라 (리비)
- 57. 지역변수의 범위를 최소화하라 (우주)
- 58. 전통적인 for 문보다는 for-each 문을 사용하라 (트레)
- 59. 라이브러리를 익히고 사용하라 (카피)
- 60. 정확한 답이 필요하다면 float와 double은 피하라 (제리)
- 61. 박싱된 기본 타입보다는 기본 타입을 사용하라 (리비)
- 62. 다른 타입이 적절하다면 문자열 사용을 피하라 (콜리)
- 63. 문자열 연결은 느리니 주의하라 (콜리)
- 64. [객체는 인터페이스를 사용해 참조하라]
- 65. 리플렉션보다는 인터페이스를 사용하라 (카피)
- 66. 네이티브 메서드는 신중히 사용하라 (제리)
- 67. 최적화는 신중히 하라 (트레)
- 68. [일반적으로 통용되는 명명 규칙을 따르라]
- 69. [예외는 진짜 예외 상황에만 사용하라]
- 70. [복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라]
- 71. [필요 없는 검사 예외 사용은 피하라]
- 72. [표준 예외를 사용하라]
- 73. [추상화 수준에 맞는 예외를 던지라]
- 74. [메서드가 던지는 모든 예외를 문서화하라]
- 75. [예외의 상세 메시지에 실패 관련 정보를 담으라]
- 76. [가능한 한 실패 원자적으로 만들라]
- 77. [예외를 무시하지 말라]
- 78. [공유 중인 가변 데이터는 동기화해 사용하라]
- 79. [과도한 동기화는 피하라]
- 80. [스레드보다는 실행자, 태스크, 스트림을 애용하라]
- 81. [wait와 notify보다는 동시성 유틸리티를 애용하라]
- 82. [스레드 안전성 수준을 문서화하라]
- 83. [지연 초기화는 신중히 사용하라]
- 84. [프로그램의 동작을 스레드 스케줄러에 기대지 말라]
- 85. [자바 직렬화의 대안을 찾으라]
- 86. [Serializable을 구현할지는 신중히 결정하라]
- 87. [커스텀 직렬화 형태를 고려해보라]
- 88. [readObject 메서드는 방어적으로 작성하라]
- 89. [인스턴스 수를 통제해야 한다면 readResolve보다는 열거 타입을 사용하라]
- 90. [직렬화된 인스턴스 대신 직렬화 프록시 사용을 검토하라]