추가 적립 안내

더 나은 자바 개발자로 성장하기 위한 새로운 시각!
다른 언어 개발자가 보기에도 충분한 범용적인 프로그래밍 노하우!

『자바 개발자를 위한 97가지 제안』은 자바 개발 역량을 키우고 싶은 독자에게 자바 리더및 전문가의 알토란 같은 노하우를 제공한다. 책에서 소개하는 97가지의 제안은 문제를 새로운 시각에서 바라보고, 자신이 맡은 일에 더 넓은 책임을 가지며, 새로운 기술을 익힘으로써 스스로의 역량을 확대하여 개발 전반에 대한 능력을 끌어올려 줄 것이다.

케블린 헤니와 트리샤 지가 함께 편집한 이 책은 자바 소프트웨어를 작성하고 소프트웨어 개발 프로세스와 함께 살아온 전문가 73인의 축적된 경험을 반영하고 있다. 훌륭한 개발자가 자신이 학습한 지혜를 공유함으로써 레거시 코드를 다루는 독자는 물론, Java 8 이후의 변경 사항을 적용하는 독자에게도 자바 개발에 대해 다시 한번 생각해 볼 기회를 마련해 줄 것이다.

이 책의 대상 독자
자바 전문가들의 다양한 시각을 보고 싶은 자바 개발자
한 단계 도약하고자 하는 일반 개발자
자바를 좀 더 알고자 하는 코틀린 개발자

PROPOSAL 01 자바만으로도 충분하다 1
PROPOSAL 02 확인 테스트 3
PROPOSAL 03 AsciiDoc으로 자바독 확장하기 5
PROPOSAL 04 컨테이너를 제대로 이해하자 7
PROPOSAL 05 행위를 구현하는 것은 쉽지만 상태를 관리하는 것은 어렵다 9
PROPOSAL 06 JMH로 조금 더 쉽게 벤치마킹해 보자 11
PROPOSAL 07 아키텍처의 품질을 체계화하고 검증하는 방법의 장점 14
PROPOSAL 08 문제와 업무를 더 작은 단위로 나누기 17
PROPOSAL 09 다양성을 인정하는 팀 만들기 19
PROPOSAL 10 빌드는 느려서도 안 되고 불안정해서도 안 된다 22
PROPOSAL 11 아니, 내 머신에서는 잘 실행됐다니까! 24
PROPOSAL 12 비대한 JAR은 이제 그만 27
PROPOSAL 13 코드 복원전문가 29
PROPOSAL 14 JVM의 동시성 31
PROPOSAL 15 CountDownLatch, 친구인가 적인가? 34
PROPOSAL 16 선언적 표현식은 병렬성으로 가는 지름길이다 37
PROPOSAL 17 더 나은 소프트웨어를 더 빨리 전달하기 39
PROPOSAL 18 지금 몇 시예요? 41
PROPOSAL 19 기본 도구의 사용에 충실하자 44
PROPOSAL 20 변수를 바꾸지 말자 46
PROPOSAL 21 SQL식 사고 도입하기 50
PROPOSAL 22 자바 컴포넌트 간의 이벤트 52
PROPOSAL 23 피드백 루프 55
PROPOSAL 24 불꽃 그래프를 이용한 성능 확인 57
PROPOSAL 25 지루하더라도 표준을 따르자 59
PROPOSAL 26 자주 릴리스하면 위험을 줄일 수 있다 61
PROPOSAL 27 퍼즐에서 제품까지 63
PROPOSAL 28 ‘풀스택 엔지니어’는 마음가짐이다 66
PROPOSAL 29 가비지 컬렉션은 나의 친구 68
PROPOSAL 30 이름 짓기를 잘 하자 70
PROPOSAL 31 이봐 프레드, 해시맵 좀 전해 주겠는가? 72
PROPOSAL 32 널을 피하는 방법 74
PROPOSAL 33 JVM의 크래시를 유발하는 방법 77
PROPOSAL 34 지속적 전달로 반복가능성과 감사가능성 향상하기 79
PROPOSAL 35 자바는 자바만의 강점이 있다 81
PROPOSAL 36 인라인식 사고 83
PROPOSAL 37 코틀린과의 상호운용 85
PROPOSAL 38 일은 끝났어요. 그런데... 87
PROPOSAL 39 자바 자격증: 기술 업계의 터치스톤 89
PROPOSAL 40 자바는 90년대생 91
PROPOSAL 41 JVM 성능 관점에서의 자바 프로그래밍 93
PROPOSAL 42 자바는 재미있어야 한다 95
PROPOSAL 43 자바의 불분명한 타입들 98
PROPOSAL 44 JVM은 멀티패러다임 플랫폼이다 101
PROPOSAL 45 최신 동향을 파악하자 103
PROPOSAL 46 주석의 종류 105
PROPOSAL 47 은혜로운 flatMap 108
PROPOSAL 48 컬렉션을 제대로 이해하자 111
PROPOSAL 49 코틀린은 정말 물건이다 113
PROPOSAL 50 관용적인 자바 코드를 학습하고 머릿속에 캐시하자 117
PROPOSAL 51 카타를 하기 위해 학습하고 카타를 이용해 학습하자 120
PROPOSAL 52 레거시 코드를 사랑하는 방법 123
PROPOSAL 53 새로운 자바 기능을 학습하자 126
PROPOSAL 54 IDE를 활용해 인지 부하를 줄이는 방법 129
PROPOSAL 55 자바 API를 디자인하는 기술 131
PROPOSAL 56 간결하고 가독성이 좋은 코드 133
PROPOSAL 57 자바를 그루비스럽게 136
PROPOSAL 58 생성자에서는 최소한의 작업만 140
PROPOSAL 59 Date라는 이름은 조금 더 명확해야 했다 143
PROPOSAL 60 업계의 발전에 기여하는 기술의 필요성 145
PROPOSAL 61 바뀐 부분만 빌드하고 나머지는 재사용하기 147
PROPOSAL 62 오픈소스 프로젝트는 마법이 아니다 149
PROPOSAL 63 Optional은 규칙을 위반하는 모나드지만 좋은 타입이다 151
PROPOSAL 64 기본 접근 한정자를 가진 기능 단위 패키지 154
PROPOSAL 65 프로덕션 환경은 지구상에서 가장 행복한 곳이다 157
PROPOSAL 66 좋은 단위 테스트에 기반한 프로그래밍 160
PROPOSAL 67 OpenJDK 소스 코드를 매일 읽는 이유 163
PROPOSAL 68 내부를 제대로 들여다보기 165
PROPOSAL 69 자바의 재탄생 168
PROPOSAL 70 클로저에 의한 JVM의 재발견 170
PROPOSAL 71 불리언 값은 열거자로 리팩토링하자 173
PROPOSAL 72 속독을 위한 리팩토링 176
PROPOSAL 73 단순한 값 객체 179
PROPOSAL 74 모듈 선언에 주의해야 하는 이유 182
PROPOSAL 75 의존성을 잘 관리하자 185
PROPOSAL 76 ‘관심사 분리’가 중요한 이유 187
PROPOSAL 77 기술 면접은 학습할 가치가 있는 기술이다 190
PROPOSAL 78 테스트 주도 개발 192
PROPOSAL 79 bin 디렉터리에는 좋은 도구가 너무나 많다 195
PROPOSAL 80 자바 샌드박스를 벗어나자 198
PROPOSAL 81 코루틴에 대한 고찰 201
PROPOSAL 82 스레드는 인프라스트럭처로 취급해야 한다 204
PROPOSAL 83 정말 좋은 개발자의 세 가지 특징 206
PROPOSAL 84 마이크로서비스 아키텍처의 트레이드오프 208
PROPOSAL 85 예외를 확인하지 말자 210
PROPOSAL 86 컨테이너로 통합 테스트의 숨겨진 가능성을 끌어내자 213
PROPOSAL 87 퍼즈 테스트의 어마무시한 효과 215
PROPOSAL 88 커버리지를 이용해 단위 테스트 개선하기 218
PROPOSAL 89 사용자 정의 아이덴티티 애노테이션을 자유롭게 사용하자 220
PROPOSAL 90 테스트를 이용해 더 나은 소프트웨어를 더 빨리 개발하자 223
PROPOSAL 91 테스트 코드에 객체지향 원리 적용하기 225
PROPOSAL 92 커뮤니티의 힘을 빌려 경력을 개발하자 228
PROPOSAL 93 JCP 프로그램에 대한 이해와 참여 방법 230
PROPOSAL 94 자격증에 가치를 두지 않는 이유 232
PROPOSAL 95 주석은 한 문장으로 작성하라 234
PROPOSAL 96 ‘읽기 좋은 코드’를 작성하자 237
PROPOSAL 97 젊은 객체, 늙은 객체, 그리고 가비지 240

기고자 소개 243
찾아보기 275

애플리케이션이 하나의 함수를 배포 단위로 사용하는 서버리스(serverless) 아키텍처로 이동하면서 애플리케이션 프레임워크의 장점들은 희석되고 있다. 그 이유는 기술 및 아키텍처 관점의 문제들을 처리하는 시간은 줄어들고 프로그램의 비즈니스적 기능에 프로그래밍 노력을 더 많이 들일 수 있게 되었기 때문이다. _2쪽

자바는 태생적으로 명령형이자 객체 기반 프로그래밍 언어다. 사실 지금도 그렇다. 하지만 지난 몇 년간 자바는 발전을 거듭해 왔으며 단계마다 더 많은 선언적 표현식(declarative expression)을 도입해 왔다. 명령형(imperative) 프로그래밍은 명시적으로 컴퓨터가 해야 할 일을 코드로 서술하는 것이다. 반면 선언적(declarative) 프로그래밍은 목적을 달성하기 위한 방법에 대한 목표 추상화를 표현하는 코드를 작성하는 것이다. 추상화는 프로그래밍의 핵심이므로 명령형 코드에서 선언형 코드로의 이전은 자연스러운 결과다. _37쪽

자바는 int나 char 같은 소위 ‘기본 자료 타입(primitive type)’을 다룰 때 캐시 친화적으로 동작한다. 기본 자료 타입은 인라인 타입이며 그로 인한 장점이 있다. 인라인 타입은 처음에는 다소 생소해 보이겠지만 여러분은 이미 이 타입을 다뤄 본 적이 있다. 그저 이 타입을 객체로 생각하지 않았을 뿐이다. 그러므로 ‘인라인 클래스’가 잘 이해되지 않는다면 ‘int 타입이라면 어떻게 동작할지’ 생각해 보길 바란다. _84쪽

필자는 모듈라-3(Modula-3, https://oreil.ly/t2t4G) 경험에서 영감을 받은 방법을 선호한다. 즉, 생성자는 필드에 값을 대입하는 역할만 하는 것이다. 생성자가 해야 할 일은 올바른 인스턴스를 생성하는 것뿐이다. 객체 생성 시점에 수행해야 할 작업이 더 많다면 팩토리 메서드를 사용한다. _141쪽

값 객체를 단순화하는 것은 타입의 역할을 명확히 하는 데 유용한 규칙이며 코드를 읽는 데 방해가 되는 요소도 줄일 방법이다. 게다가 리팩토링도 쉬우며 코드의 도메인을 더 잘 표현하는 메서드를 어떤 타입에 추가해야 하는지를 더 확실히 알 수 있다. 간혹 값 객체의 행위적인 기능이 더 중요한 경우에도 필드는 비공개로 유지하고 메서드로 필요한 것을 표현할 수 있게 되었다. _181쪽

다른 개발자가 자신의 애플리케이션에 여러분이 작성한 코드를 사용한다고 생각해 보자. 이 개발자는 자신이 어떤 예외를 던질지 알 수도 있지만 여러분은 그 개발자가 어떤 예외를 던질지 알지도 못하고 알 필요도 없다. 여러분의 코드는 그저 예외가 다른 개발자의 코드로 전달되어 그 애플리케이션 코드 예외 핸들러까지 도착하도록 하기만 하면 된다. 제어의 역전(Inversion of Control)을 제대로 지원하려면 예외 투명성(exception transparency)이 필요하다. _212쪽