[제이펍] 자바 개발자를 위한 97가지 제안

올랜도·2022년 5월 20일
1

녹음의 풀내음이 진하게 느껴지는 4월 7일,

그것은 느닷없이 집앞에 놓여져 있었다.


제이펍/자바 개발자를 위한 97가지 제안
(빛이나는 한명은 절대 대머리라 그런게 아니다.)


  서문에서 책은 묻는다.

"모든 자바 프로그래머가 반드시 알아야 할 것은 무엇일까?"

이 하나의 문장을 보고 잠시 책을 덮고 생각을 해보았다.
질문 자체의 범위가 넓다는 느낌이 강하지만, 질문의 결이 본질을 가리키는 질문이었다.
십여분의 고민 끝에 아무래도 객체 지향 언어라는 프레임이 있으니 객체라는 키워드의 답이 나올 것 같아 다시 책을 펼쳐보았고,
나는 힘빠지는 당연한 답을 읊었다.

"그 답은 누구에게 묻는지, 왜 묻는지, 언제 묻는지에 따라 다르다."

"언어나 플랫폼, 생태계, 커뮤니티는 소프트웨어와 많은 사람의 삶에 영향을 미치며, 한 세기에서 다음 세기로, 하나의 코어에서 다중 코어로, 메가바이트에서 기가바이트로의 진화에도 영향을 미쳤던 이 질문의 답은 한 명의 저자가 하나의 책에 모두 담아내기에는 너무 벅차다. "

하지만 책의 제목부터 무수한 관점과 표현을 담아낸 책이었음을 다시 상기시키고 이내 페이지를 넘겼다.

개인적인 사견으로 이 책은 책에서 명시되어있는 바와 같이 자바와 자바를 쓰는 개발자가 성장하는 힌트를 적어놓았다. 답이 아닌 힌트인 이유는 앞서 서문에서 서술한 바와 같이 무수한 관점에 따른 차이는 필연적으로 존재한다.

따라서 97가지의 제안 중 본인의 관점에서 번뜩이는 영감을 얻었던 일부를 소개한다.



08. 문제와 업무를 더 작은 단위로 나누기

진 보야르스키(Jeanne Boyarsky)

프로그래밍을 배우는 과정에서 과제를 받았을 때, 우리는 1천줄이 안되는 코드를 작성하고 테스트한다.
이후 프린트문을 추가하거나 디버거를 사용한다.
직장에서의 업무는 이보다 훨씬 더 크고 큰 만큼 해결하는 데 더 오래 걸리게 될 것이고 우리가 기억할 것들이 많아진다.
이 문제를 해결하는 좋은 방법은 문제를 더 작은 조각으로 나누는 것이다...

  문제를 분할한다는 것은 분할한 만큼 커밋을 자주하게 되는 것, 이는 우리가 원하는 대로 동작을 수행하지 않았을 시 롤백할 수 있는 지점이 많아짐을 필자는 시사한다.이어지는 필자의 사례가 이 주장을 뒷받침한다.
필자의 팀 내에서 큰 이슈가 있었던 적이 있을 때, 한 동료의 커밋 시점이 일주일 전이었고, 그 팀원과 자신이 진행한 작업간의 차이에 의해 디버깅을 도와줄 수 없는 지경에 이르렀다는 것이었다.
동료는 자신의 코드가 특별하기 때문에 나눌 수 없다 주장했으며 필자는 그 특별하다는 키워드를 조심하라 말했고 동료의 프로세스를 직접 분할하여 분할마다 커밋을 하고 이틀동안 22개의 커밋을 수행하여 문제를 해결하였다고 한다.

요약

  • 이슈발생
  • 큰 기능 작성마다 커밋한사람과 디테일한 기능마다 작업한 사람간의 차이 발생
  • 큰 기능을 쪼개어 다시 하나씩 커밋하여 작성

43. 자바의 불분명한 타입들

벤 에번스(Ben Evans)

대체 널(null)이 무엇일까?
자바를 처음 접하는 프로그래머는 널을 이해하는 데 어려움을 겪는다. 하지만 다음 간단한 코드 예제 코드를 보면 그 내막을 알게된다.

String s = null;
Integer i = null;
Object o = null;

null이라는 심볼은 값이어야 한다. 자바는 String의 변수에 Object를 할당할 수 없다. 리스코프 치환 원칙에 따르면 이 명제는 성립할 수 없다. 이러한 null에 대해 필자는 경험이 풍부한 자바 프로그래머라면 "어떠한 참조 타입도 될 수 있는 특별한 리터럴"이라고 치부한다고 한다.

자바는 변수 타입으로 선언할 수 없는 타입의 값의 사용을 허용한다.
이런 타입을 불분명한 타입(unspeakable type)이라 부르며 표시할 수 없는 타입이라 부른다.

이러한 부류의 타입은 이후 2번 더 등장하며 자바7에서의 예외 매개변수, 멀티캐치이다.

  • 예외 매개변수의 경우 단일 클래스 타입이나 둘 혹은 그 이상의 클래스 타입을 결합한 타입
  • 멀티캐치는 매개변수의 실제 타입은 캐치할 수 있는 모든 타입을 결합한 타입이다.

이런 추가적인 불분명타입에 대해 자바는 상당히 제한되어 있으며, 필자는 자바의 타입 시스템은 명목상 존재하는 시스템으로 언어상에서 진정한 구조적 타입을 제공할 가능성은 거의 없다고 시사한다.



55. 자바 API를 디자인하는 기술

마리오 푸스코(Mario Fusco)

개발자는 API를 이용해 업무를 수핸한다. 더 정확히 말하면 API는 개발자와 소프트웨어의 서비스를 API로 노출하는 디자이너 사이의 계약을 수립하는 것이다. 그런 의미에서 우리는 모두 API 디자이너이다. 소프트웨어는 그 자체로는 아무 의미가 없다. 다른 개발자가 작성한 다른소프트웨어와 함께 동작할 때 비로소 의미를 가질 수 있다.

해당 챕터의 필자가 정의하는 API특징은 다음과 같다.

  • 좋은 API는 쉽게 이해할 수 있고 찾아 쓸 수 있어야 한다.

    필요할 때 바로 사용할 수 있어야 하며 이상적으로는 문서를 읽지 않고도 그 동작 원리를 학습할 수 있어야 한다. 이는 일관석 있는 이름과 규칙을 사용하는 것이 중요하다.

  • API를 작게 유지하라

    작게 유지하는 만큼 배워야 할 개념과 유지보수의 비용이 줄어든다. 대표적인 예시는 Optional로 매개변수에 null이 전달 될 경우 발생하는 예외가 별도의 메서드를 요구하게 되는데 이는 작게 유지하고자 하는 디자인 패턴에서 벗어난 케이스라고 볼 수있다.

  • 크기가 큰 인터페이스를 더 작은 인터페이스로 분할하라.
    • 스트림을 통해 null을 리턴하지 않으며 빈 컬렉션과 optional 객체를 사용한다. 이는 예외를 처리할 일이 없고 생략또한 가능하다.
    • 매개변수인수의 경우 메서드에 매개변수 정의를 많이 하지 말도록 하자
    • 매개변수의 타입은 타입중에서 가장 추상적인 타입을 사용하자.

전체적으로 API작성에 도움이 되는 말을 전하며 처음부터 제대로 된 API를 작성할 수 있다고 생각하지말라는 것을 당부한다. 반복작업과 테스트, 동료와의 소통을 통해 개선해 나가는 것이 필자가 생각하는 API이다.



마치며...

???: 아 코딩해야겠다.

책을 읽고 난 후에 드는 생각이었다.
잠깐의 회고를 덧붙이자면, 파이썬을 메인으로 쓰는 상황에서 자바로 넘어오기 까지 많은 생각과 계기가 있었다. 물론 넘어오고 난 이후 또한 적지않은 생각이 머릿속에서 상주하고 있는데 매번 쓰는 메서드와 클래스로 인해 프로젝트내 코드가 어느정도 획일화 되어있다는 것과 실제로 프로젝트를 진행하다 보면 순간순간 API나 형상관리, 변수명 설정과 같은 무수한 딜레마가 인간 올랜도의 가장 큰 고민이었다.
그런 인고의 시간에서 참으로 다행인 것은 자바 개발자를 위한 97가지 제안과 같은 레퍼런스를 제공받을 수 있는 환경속에 살고있다는 것이다. 독서를 거의 마쳐가는 시점에서 위의 고민들을 대부분 해결 할 수 있었다는 것이 무척이나 즐겁고 감사했다.

profile
☂️생존주의 개발자

0개의 댓글