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

주제 1: 함수의 인자 개수 0개 - 정말 이상적인가? (3장 '함수')

[책 50페이지]
함수에서 이상적인 인수 개수는 0개다. 다음은 1개고, 다음은 2개다. 3개는 가능한 피하는 편이 좋다. 4개 이상은 특별한 이유가 필요하다.

발제자 제안

• 함수의 인자가 무조건 0개인게 이상적이라고 생각하지 않음
• 함수 인자를 안 넘겨도 되는 경우는 부수 효과를 일으키지 않는다는 조건이 충족되었을 때만
• 인자 갯수를 줄이기 위해 함수 내부에서 전역함수, 전역상태, Store 등등을 마음대로 바꾼다면 오히려 이건 더 안 좋은 함수라고 생각
• 언제 인자를 넘겨주고, 언제 인자를 넘겨주지 않아도 될지?

나눈 의견

• 함수의 인수가 0개이면 어떻게 가공하는지 외부에서 전혀 알 수 없음 (=> 지나친 폐쇄성)
• 인자를 줄여야 한다면 테스트 시 문제를 일으키는 인자를 줄이기
• 인자를 5-6개 등 너무 많이 쓰면 작성자의 의도를 알기가 쉽지 않음
• 객체 지향은 객체 간의 협력을 통해 프로그램을 만드는 패러다임
  • 객체 간의 협력(= 의존성) 필수
• 인수가 적으면 적을수록 좋긴 하지만 무작정 개별로 나열하지 말고 의미 있는 객체로 묶어서 전달
• 함수형의 커링 기법: 하나의 다항 함수를 여러 개의 단항 함수로 쪼개서 다음 함수로 반환 값을 넘기는 기법
  • 인자를 줄여서 복잡도를 줄일 수 있다고 생각
• 만약 부모 함수가 어쩔 수 없이 인자를 5개 받았다면?
  • 자식에서 최대한 나눠받을 수 있게
• 커스텀 훅의 경우 내부적으로 쓰라고 만들어진 것
  • 되도록 인자를 전달하지 않는 것이 좋음
  • 내부 함수만으로 완결성을 갖도록

주제 2: 함수에서 중복을 피하는 방법에는 무엇이 있을까? (3장 '함수')

[책 60페이지]
목록 3-7은 include 방법으로 중복을 없앤다.
…
객체지향 프로그래밍은 코드를 부모 클래스로 몰아 중복을 없앤다. 구조적 프로그래밍, AOP, COP 모두 어떤 면에서 중복제거 전략이다.

발제자 제안

• 책에서는 include 로 중복되는 코드를 넣고 FLAG 상수를 넣어 중복을 제거
• 객체 지향은 중복되는 코드를 부모에 작성함으로서 상속을 통해 중복을 제거
  • 책에서 소개된 include도 결국은 객체 지향을 활용한 사례
• 함수형에서 함수만으로 중복을 없애야 한다면, 어떤 기법들이 있을까?

나눈 의견

• 함수 지향의 프론트의 경우 고차 함수, 커스텀 훅 등을 사용
  • 공통성을 뽑아내서 재사용성을 높임
• 고차 함수란?
  • 함수를 인자로 받는 함수
  • 함수를 값으로 사용 가능한 자바스크립트의 특성으로 가능
• 공통된 부분을 부모에게서 상속 받아서 자식에서 오버라이드해서 사용할 수도 있음
• 상속의 문제점
  • 객체 메서드가 컴파일 중에 실행되는데 실행 중에는 바꿀 수가 없음
  • 이를 극복하기 위한 것이 (자바의) 위임 개념
• 위임
  • 공통된, 중복된 부분을 따로 분리된 클래스에서 받아서 쓰는 것
  • 주입(injection)이라고 하며 부모에서 내려주는 상속과 차이가 있음
  • 위임 예시: 부모(비행기) - 자식(전투기, 폭격기)
    • 부모에 있는 스텔스 기능을 자식 중에 안 쓰는 자식이 있을 수 있음
    • 이때 스텔스 기능을 부모에 두고 자식이 가져다 쓰면 '상속' 개념
    • '위임'은 스텔스 기능을 따로 추상화된 클래스로 분리해뒀다가 이후 부모가 필요해질 때 이 클래스를 '위임'해서 사용
      => 결합도를 낮추고 응집도를 상승시킴
• 프론트에서는 대부분 함수형이어서 백엔드에서와 같은 디자인 패턴 적용이 어려움
  • 그러니 SOLID 정도만 적용해도 좋지 않을까?
  • Dart의 경우는 완벽한 객체 지향
• 클래스형 리액트에서는 객체 지향 가능한데 함수형에서도 객체 지향 개념을 쓰는 방법을 고민해보자
  • 또 함수형을 지향해도 함수에 넘겨지는 데이터만 필요에 따라 클래스형으로 만들 수도 있음

주제 3: 추상화는 독인가 약인가 (3장 '함수')

[책 44-45페이지]
함수를 작게 만든다 = 추상화

발제자 제안

• 추상화로 인해 함수의 가독성이 떨어지는 경우 있음
  • 예: 1 ~ 10 까지 실행이 필요한 로직에서 각각의 함수가 떨어져 있는 경우 (모듈으로 쪼개져 있거나)
• 하나의 로직이 위에서 아래로 읽히는 과정에서의 불편함
• 추상화로 로직 모듈화 vs 추상화로 인해 여러 파일의 함수를 봐야 함
• 둘 중 어떤 쪽이 더 나을지 !?

나눈 의견

• 가장 먼저 실행되는 함수 모음
  • (추상화로 인한) 함수명만 있더라도 흐름 파악 가능
  • 복잡한 코드는 최대한 저수준으로 미룸 (아래로 갈수록 약한 추상화 - 맨 아래에는 정규식과 같은 가장 low한 코드)
• 추상화된 코드를 간혹 이해할 수 없는 경우
  • 실제로 다른 파일에서 가져와서 쓰려고 하면 '차라리 원래 파일 내부에 있는 게 낫지 않을까' 싶을 때
• 중복이 꼭 나쁜 것만은 아님
  • 사람이 읽었을 때의 가독성이 가장 중요
• 결국 추상화의 정도는 상황에 맞게 개발자가 고려해야 할 문제
  • 무조건 추상화가 답이 아니다.
  • 너무 추상화하면 재사용성이 오히려 떨어질 수 있음
• 권장 방법: 처음에는 추상화를 너무 신경쓰지 말고 일단 개발하기
  • 개발자는 기한 내에 기능을 구현해내는 것이 가장 급선무
  • 이후 공통화(추상화)를 조금씩 고려
  • 김영한 개발자님 인용: '실제 구현은 로직에 들어가봐야 아는 것, 추상화에 너무 신경쓰지 말기'

주제 4: 불용어 사용 여부 (2장 '의미 있는 이름')

[책 26페이지]
불용어를 추가한 이름 역시 아무런 정보도 제공하지 못한다.
Product라는 클래스가 있다고 가정하자. 다른 클래스를 ProductInfo 혹은 ProductData라고 부른다면 개념을 구분하지 않은 채 이름만 달리한 경우다. Info나 Data는 a, an, the와 마찬가지로 의미가 불분명한 불용어다.

발제자 제안

• GNB(헤더)를 만들 때 헤더 오른쪽의 아이콘 그룹 컴포넌트의 이름 짓기를 고민
  • 예: 인스타그램 카드에서 카드의 하단 오른쪽에 좋아요(하트), 공유 등의 버튼을 가로 배치하고자 할 때 부모 스타일 컴포넌트의 이름 고민
• 이때 책에서 쓰지 말라고 한 불용어 ‘~Info’로 작성한 적이 많았음
• 실무에서는 이런 경우 어떤 이름을 쓰는지? (Info, Data 등의 불용어에 대한 대체재?)

나눈 의견

• 제시된 이름들
  • 상단 GNB의 경우
    • HeaderIconGroup
  • 인스타그램 카드의 경우
    • CardHeaderGroup
    • CardBottomGroup
• Wrapper는 되도록 사용 안 하는 등
  • 프론트엔드에서 협업할 때 코딩 컨벤션에 대한 합의 꼭 필요
  • 아니면 나중에 프로젝트 내 변수명, 함수명이 중구난방이 됨
• 책에서 Info가 불용어라고 한 이유
  • Info 라는 단어 안에 이미 너무 많은 관심사가 들어가있음
• GNB에서 왼쪽, 오른쪽 그룹 이름 지정 시 'Left~', 'Right~'
  • 어떻게 해서든 'Info', 'Data'가 이름에 포함되는 건 배제할 수 있도록