Happy Hour 🍻

<aside> ℹ️

해피아워?

전통적으로 지역 바에서 한 시간(때로는 몇 시간) 동안 맥주 가격을 할인하여 지역 내 근로자들이 사무실을 떠나 술 한 잔을 마시며 친목을 도모할 수 있도록 유도하는 시간입니다.

잠시 스터디를 떠나, 각자 마실 것 한 가지를 가져와 편안하게 이야기 할 수 있는 시간을 마련해봤습니다.

</aside>

아름다운 코드에 대하여

• 어떤 상황에서 아름다운 코드라고 느끼시나요?

• 미술작품은 해석이 없으면 아름다움을 못 느끼는 경우가 많다. 코드도 똑같을까?

• 코드는 놀라운 아름다움에 속할까? 자연적 아름다움에 속할까?

• 아름다운 코드를 만들기 위해서 노력해야 하는 것?

  • 서진

    • 원래는 함수형을 좋아해서 놀라운 아름다움파여서 놀라운 아름다움파

      ⇒ 함수형을 보면 생각치도 못한 방법으로 추상화한다 (놀랍고 잘 설계되어 있음)

    • 요즘에는 자연적 아름다움에 가까워지려고 생각중 (아름다우려고 하지 않고 자연스럽게 하려고 한다)

      • 자연스럽고 아름답다기보다 코드를 봤을 때 너무 당연한 코드를 추구하고 있다.
      • 자연스러운 코드 ? 디자인 툴을 보고 요구사항을 보고 코드를 봤는데 그대로 드러나는 코드
        • 이유
          • 코드는 변경하기 수월한 코드가 좋은 코드라고 생각한다
          • 코드만 봐서 아름답게 만들어도 디자인, 기획이 변경되었을 때 결국 코드를 다 바꿔야하고 코드가 왜 이렇게 짜여져있는지 모르고 코드 수정하기 어려웠음 (실용적인 코드를 추구)
  • 충일
    • 놀라운 아름다움은 고민을 많이 하는데 자연스러움은 고민이 많이 필요없는 것일까?
      • 그 사람이 애초에 지식이 많아서 자연스러운건지 vs 고민을 많이해서 자연스러운건지?
        • 서진
          • 서비스 개발 : 머리를 잘 쓰기보다 기획, 디자인 분과 밀접하게 소통하고 기획과 디자인을 잘 이해하고 어떻게 생각하는지 뇌가 싱크된 상태에서 아키텍처를 작성하면 그대로 코드가 짜게된다고 생각 (맥락을 이해하고 개발하기)
            • 싱크 X → 요구사항과 동떨어진대로 구현
          • 오픈소스 : 다양한 맥락 속에서 쓰이기 때문에 고민을 많이 해야하는 것 같아요 (경험)
  • 현재
    • 자연스러움이라는 것을 충족하기 위한 조건들이 무엇이 있을까요?
      • 서진
        • 내부 구현을 보지 않고 함수명, 인자, 반환값을 보고 역할이 추론되는 경우
          • 함수의 여러가지 책임을 가지고 있지 않게 하기
          • 인자도 어떻게 받아야 할지 잘 설계하기
        • 위에서 아래로 읽히는 경우
          • 사용처를 보았을 때, 구현체를 보지 않아도 알 수 있게 하기
      • 민수김

        • 테스트 코드의 TC를 it으로 표현한다.

        • it~ 으로 시작하다보니 문장처럼 읽혀지는 부분이 생각났어요

          it('should return number')
          

• 민수박

  • 서진님의 이야기가 전체적으로 다 비슷한 느낌
  • 자연적 아름다움이 무엇인지에 대한 정의를 세워야한다고 생각이 들었어요
  • 공교롭게도 어제 함수랑소모임에서 ‘왜 사는가?’, ‘아름다움이 뭐지?’에 대한 이야기를 나눔
  • 저는 의미를 부여하기 때문에 아름답다고 생각하는 것 같아요
    • e.g ) 자연을 보고 의미를 부여해서 / 건물 속에 피어난 장미
  • 자연적 아름다움 : 의미를 부여한 것
  • 놀라운 아름다움 : 규칙적으로 일관성을 가지게 된 것

    • 나는 과하지 않고 적당한 놀라운 아름다움쪽인 것 같다

      ⇒ 기준들을 가지고 짜여진 코드

• 윤호

  • 직관적으로 봤을 때, 레이어를 잘 나눈 코드에서 매력을 느끼는 것 같다
    • 의문이 드는 코드 → 설명이 필요한 코드
    • 의문이 들지 않는 코드 → Approve (👍)

• 재석

  • 놀라운 아름다움 쪽을 선호 (함수형에 관심)

  • 변수명에서 기능을 알기쉽고 이름만으로 추론하지 않게 작성하는게 어렵다

  • 함수만 듣고는 무슨 일을 하는지 어려움 (scan, zip)

    ⇒ 이쁘게 코드를 작성하는 것에 매몰됨 → 이쁘기 위해 코드를 계속 쓰게 됨

    • 취미 관점: 이쁘게 작성하는 것
    • 협업 관점: 편안하게 읽기 쉽게하는 것

  • 도메인 맥락에서 주석을 작성하는 것이 좋은 것 같다

  • 민수김

    • 주석이 필요하네? 뭐가 문제일까?라는 관점으로 생각하고 있었음
    • 도메인 맥락에서는 그럴 수 있을 것 같다

  • 지예

    • 주석없이 작성하려고 하니까 좀 더 이쁘게 작성하게 되고 좀 더 고민하게 작성하게 되었다

• 상민

  • 그림을 봤을 때 직관적이라는 말이 맞는 것 같다
  • 보고서 내 경험들과 연결이 되는지?
    • 자연적 아름다움은 우리 경험들과 너무 맞닿아있음, 컴포지션은 경험해본적이 없어서 이쁜지 모르겠음
  • 어느 정도 기능단위까지 나눌것인가? → 그 함수가 해주는 것까지 해야한다?
  • 라이브러리 관점에서 사실 성능좋게 만들 수 있는 코드들이 있는데 모든 사람들이 이해하고 더 보기 쉬운 코드를 택하는 경우가 많다
  • 직관적으로 볼 수 있는 코드가 좋다 ⇒ 자연적 아름다움이 좋다

• 지예

  • 경험마다 다르게 자연적 아름다움을 받아들일 수 있지 않을까? 그럼 자연적 아름다움을 정의할 수 있을까? 코드 자체는 너무 인위적이지 않나?
    • 모르는 사람이 봤을 때, 설명을 해주어야 함 ⇒ 놀라운 아름다움
  • 프론트엔드에서 자연적 아름다움이 있을까? (모두가 봐도 이쁜)
    • 현재
      • 자연스러움은 편안함과 맥락이 닿아있다고 생각
      • 데이터의 맥락이 많지 않고 한 번에 이해할 수 있도록 맥락이 분리되어 있고 코드를 인지하는 데에 걸림돌이 없는 코드들
      • 복잡한 코드를 많이 봐온 사람 → 복잡한 코드가 자연스러움
      • 똑똑한 사람 → 많은 맥락들이 있어도 이해하기 쉬움
      • 그래도 일반적인 수준에서는 자연스러움이 있다고 생각한다

• 민수박

  • 자연을 보고 아름답다고 한 것은 학습된게 아닐까?

• 서진

  • 글쓰는 것보다 코드를 더 많이 쓰는 것 같아서 프로그래밍 언어도 언어라고 생각해요 (문법에 맞춰서 문제를 해결하는 코드를 작성하는 것)
  • 글도 잘쓴 글과 못쓴 글이 있는 것처럼 사람마다 해석이 다르다고 생각함
  • 일반적으로 잘쓴 글
    • 문법에도 맞아야 함
    • 주제에도 맞아야 함

• 민수김

  • 시를 보고 아름답다고 생각해본 적이 없다고 생각함
  • 시가 맥락이 많고 배워야 하기 때문
  • 잘쓴 글, 잘쓴 언어가 코드 작성할 때 유의미한 고민이 되지 않을까? 싶다

• 보성

  • 사회적으로 합의되어서 예측 가능한 코드 (input, focus, blur)
  • 놀라운 아름다움도 사실 자연적 아름다움의 추상화되어 있는 표현이 아닐까?

• 지예

  • 음악에서는 놀라운 아름다움과 자연적 아름다움이 둘 다 있어야 아름답다
    • 자연적 아름다움 : 이게 모야?
    • 놀라운 아름다움 : 듣기 어려움
    • 어떤 코드를 직관적으로 봤을 때 이해하기 쉬운데 설계도 잘되어 있고 이런 부분에서 두 가지 모두 있어야 아름답지 않을까?

• 희림

  • 결국은 자연스러운 것에서 출발한다고 생각
  • 디자인 패턴 : 이 구조는 훨씬 더 나은 것 같애 / 변경이 더 자연스러운 것 같애 → 법칙화
    • 자연스러운 것에서 출발되었지만 귀결된 것은 놀라운 아름다움이라고 생각