찰쓰 코치님, 병현님, 효선님, 윤몬님, 한솔님, 나 6명 참여
1시간 10분 토론

주제 1: 구현이 짧은 함수라도 주석을 피하기 위해 inline 방식보다 함수를 생성하는 것이 좋은가? (4장 '주석')

[책 70페이지]
코드만으로는 의도가 명확하지 않을 수 있는 경우, 의도를 표현한 함수를 생성하는 것이 좋다.

발제자 제안

• 최근에 실무에서 이와 관련한 고민을 했었다.
• inline으로 표현해도 충분할 정도로 길이가 짧은 구현이 있는데, 이 구현에 대한 의도를 명확하게 하기 위해 inline이 아닌 '함수'를 사용해야 한다는 의견이 있었다.
• 저와 다른 동료분이 보기에는 불필요하게 함수가 많아지는 것 같아서 inline으로 구현하는 것이 낫다고 생각했다.
• 이에 대한 경험과 어떻게 생각하는지 의견 나누고 싶다. (코드로 의도를 표현하는 것이 어느 정도까지인지가 중요할 것 같다)

나눈 의견

• if 분기가 많은 함수는 인라인으로 넣기보다 따로 빼두면
  • 이것만 따로 테스트가 가능해지기 때문에 편하다. (테스트 용이성 측면)
• 구현을 빨리 해야 할 때는 우선 inline으로 해 두고 나중에 리팩토링하기
  • vs. 처음부터 팀 컨벤션을 잘 짜서 inline 거의 없이 구현하기
• 결론: (inline을 하지 말고) 무조건 함수로 '분리'를 하되 (inline에서 좋았던 부분인 가독성을 위해) '함수 이름'을 잘 짓자
  • 함수의 의도를 함수명으로 드러내면 '의도'를 인식하기 쉬워짐
• 리액트의 경우 DOM 관련인 JSX 코드 중간에 inline으로 이벤트 핸들러 함수가 들어가 있으면 단 한 줄이라도 눈에 거슬리게 되고 역할 분배 측면에서도 맞지 않다. (이벤트 핸들러인 JS 함수는 JSX가 아닌 자바스크립트 영역에서!)

주제 2: 로버트 마틴의 '최고의 구현 표준' 예시 분석해보기 (5장 '형식 맞추기')

[책 114페이지]
코드 자체가 최고의 구현 표준 문서가 되는 예다.

발제자 제안

• 책에 나온 로버트 마틴의 '최고의 구현 표준' 예시 코드를 다음 기준으로 분석해보기
  • 어떤 위치에서, 어떤 형식이 적용된건지
  • 실제로 바로 이해가 되는지
  • 또는 나 같으면, 더 좋은 형식이 있을지 등

나눈 의견

• 각자 예시 코드에서 좋다고 생각한 부분에 대해 이야기를 나눔

1. '공백'으로 관련도의 정도를 표현한 부분

• 예: 함수명과 함수 인자가 들어가는 소괄호는 붙여서 작성, 함수 인수가 여러 개일 때 각각의 인수를 공백을 넣어서 작성
• 예: 연산식에서는 모두 붙여 쓰지만(totalChars/lineCount), for문 조건식 ':' 양옆은 띄워쓰는 것(for (int width : sortedWidths))

2. 복수형과 단수형으로 '파일들'에서 '파일 (1개)'를 꺼냄을 명확히 해 준 부분

• 예: for문에서 복수형 'files'에서 단수형 'file'을 꺼내는 코드

3. 타입과 반복되는 변수명을 똑같이 반복해서 그대로 쓰지 않고 (누구나 알아볼 수 있는 경우에 한해) 축약해서 사용한 부분 => 가독성 증가

• 예: (자바 코드) BufferReader bufferReader = new BufferReader(~)로 쓰지 않고 BufferReader br = new BufferReader(~)로 사용
• BufferReader를 변수에까지 넣어 3번 반복하는 것보다 가운데 있는 변수는 'br'로 줄여서 사용 (+ 누구나 BufferReader의 축약어라는 걸 알 수 있는 경우)

4. '좋은 코드는 잘 쓰인 책처럼 읽힌다'에 부합하던 코드

• 예: if (file.getName().endsWith(".java")) => "파일의 이름이 '.java.'로 끝난다면"으로 술술 읽힘

주제 3: 디미터 법칙 (6장 '객체와 자료 구조')

[책 123페이지]
디미터 법칙은 잘 알려진 휴리스틱(heuristic)으로, 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다는 법칙이다.
...
final String ouputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();
흔히 '기차 충돌'이라고 불리는 위와 같은 코드는 일반적으로 조잡하다 여겨지므로 피하는 것이 좋다.

발제자 제안

• 어떻게 하면 디미터 법칙을 위반하는 코드를 피할 수 있을까?
• 객체의 내부사정을 사용하는 쪽에서는 알 필요가 없다. 이러한 형태는 절차적인 것에서 보기에는 매우 선언적이다.
• 객체 지향적인 코드가 아니더라도 생각해볼 문제
• '기차 충돌'의 경우, 단순히 메서드 체이닝같이 dot이 많다고 문제가 아니며 같은 타입의 객체를 연속해서 사용한다면 문제없다.

나눈 의견

final String ouputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();

• 위 메서드 하나하나는 객체
  • 기차 충돌 형식으로 붙여써도 안 되지만
  • 그렇다고 책에서 답으로 제시한 것처럼 단순히 변수에 담는 식으로 나누는 것도 그리 좋은 방법은 아님
  • Why? 어떻게든 의존성이 계속 붙어있게 되므로
  • 단순히 변수로 나눠버리는 방법보다 내부 구조를 숨기는 방향으로 가야 함
• 위 코드의 문제:
  • getOptions에서 getScratchDir 내부의 File이 바뀔 거라고 예상 못함
    • 나중에 다른 사람이 'File이 왜 바뀌었지?' (x, 추적이 안 됨)
  • getOptions에서는 File을 몰라야 함
  • 대신 마지막 getAbsolutePath의 absolutePath를 getOptions가 갖고 있으면 됨
    • 그러면 getOptions는 File을 몰라도 된다.
• 그러나 가장 좋은 방법 = 애초에 객체를 만들 때 이런 문제들을 만들지 말자! (제대로 된 객체 설계의 중요성)

자바 코드 질문 - 객체(클래스) 안의 멤버 변수란?

• 객체가 '수리공'이라면 멤버 변수는 수리공이 가진 '연장(드라이버)'
• 드라이버는 '재료'는 아니고(내가 재료냐고 물음), 그냥 수리공이 항상 가지고 있는 것
• 드라이버를 가지고 '~를 한다' 라고 동작을 나타내는 게 바로 (객체가 가진) '함수'