Index

 Date

2022. 10. 13. 의 회의록 마스터 : 이하령

Participants

TEAM FIRE (고주형 윤영기 이하령) + WonYong Jeong

 Discussion topics

정원용 멘토님 멘토링

이벤트

헥토버페스트

• 사람들이 참여하려면 동기여부가 필요할 것 같다.

• 모도코를 이용해서 이벤트 참여하는건 가치 있을 것 같은데 단순히 모도코에 기여하는것은 소마 관점에서 도움이 안될 것 같다.

• 아이디어는 수면 위에 올려두고 여기에서 파생해서 좀 더 고민 필요할 듯

• 주형님이 강의 열고 사용자들 이용 유도 → 그리고 같이 헥토버페스트 참여 ?

사람들이 공부한것을 자동으로 캡쳐해서 자신의 피드에 올릴 수 있게

코드리뷰 이벤트

• 몇개의 코드리뷰 이벤트를 만들고 사람들이 참여하게 한다.

• 이벤트를 만들 수 있는 신청을 받는다.

• A가 코드리뷰 이벤트에 참여하겠다고 신청하고 A의 지인 혹은 모르는 사람들에게 코드리뷰를 받는다면?

• 코드리뷰 받는 사람과 하는 사람 매칭?

→ 목적: 사용자들에게 사용기를 받는다

디자인패턴

chain of responsibility

handler는 자기 자신을 위임

: 다음의 핸들러를 위임한다!

문제 상황을 추상화 하는게 먼저.

그런 문제들은 단순 하드코딩 되어있지 않을 것.

(실제에서 사용할 땐 외부에서 조건들이 주입될 것.)

그래서 단순 조건문으로 (if) 표현될 수 없을 것.

Facade 단순한 창구

이거 왜써?

• main이 쉽게 프로그래밍 하기 위해

퍼사드에서 이야기하는 subsystem은 서트파티 모듈이나 다른 패키지

퍼사드는 써드파티에서 제공하는 무언가를 사용하기 쉽게 만들어주는 역할.

오픈소스 버전업할때마다 반영해야 된다… 오픈소스 버전업할때 다 수정하는건 넘 힘들고….. facade만 수정하면 되낟.

퍼사드는 써드파티에 대해 단순화 시키면서 써드파티의 운영 책임을 갖게 된다. 그럼 클라는 써드파티의 복잡도를 아예 모르고 운영해도 된다.

서브 시스템을 넓은 단위로 바라봐야 한다! (패키지 이상의 모듈)

브릿지 패턴은 기능과 구현을 분리시켜 브릿지화 (클라는 기능에 대해서만 파악하면 됨.)

브릿지의 범위는 내 코드에 대한 리팩토링.

퍼사드가 지향하는 것은 외부 코드를 단순화 시킬 수있는 창구

→ 누구를 단순화 시키는지가 다름

어댑터는 소프트웨어가 릴리즈 되어서 이미 동작하는 상태의 버전을 새로운 코드로 전환할수 없을때!

피쳐가 바뀌었고 버전이 바뀌었는데 과거 레거시를 바꾸는 행위가 리스크가 있을때 어댑터로 감싸주고 새로운 피처로 전환!

즉, 어댑터는 우리 프로젝트의 버전업! (어댑터는 레거시가 있음)

어댑터는 같은 플젝 레거시를 감싼다.

퍼사드는 최대한 써드파티를 보존하면서 가줘야 한다.

퍼사드, 어떤 관점으로 봐야해?

• 서브시스템. 규모가 있고 스스로 버전업 하는 것

  • ‘내’가 하지 않는 버전업

주형 버전

알든 모르든 사람들이 모여서 할 수 있다.

공감대를 얻을 수 있는
모도코드

헥토버 페스트 = 수단

modocode -> 매일마다 코드 조각, 알고리즘 공부, 모도코드를 통해서 하자

• 자기들끼리 이용하드라! = 통계로 잡힘

영상 공유함 -> 피드로 남아야 해!
[피드로 남아야 해!]
1분에 한번 10분에 한번 서버로 간다
= 그 방에서 활동한 기록

남은 방
= 게시판에 남은 글 한개
= 피드가 하나

이벤트 남은 기간 이슈에 대한 의사결정

모집

• 디스코드

• 우리 서비스를 이용해서 코드 리뷰
  = 장면들이 남아있다
  = 실시간 서너명 코드리뷰
  = 우리끼리하는 모도코 코드 리뷰하는 것을 남기자 !

코드리뷰해보자!

• 자기가 이벤트를 신청하도록 해보자!

• 19일 코드리뷰 이벤트 해보자!

• 자기 친구들하고 코드리뷰

• 코드리뷰 피드백

• 개선사항을 짚어내자!

• 코드를 알려주고 싶은 내코드를 피드백 받고 싶은 사람

유튜브로 우리가 하는 걸을 해주자

• 코드 리뷰어 및 커미터를 연결해보자!

• 실제 가치를 느낄 수 있는지 시뮬레이션해보자!

1. 모의 코드 리뷰

• 모도코를 유튜브로 찍고

1. PR 데이

이럴 수 있다.
코드리뷰 = 자기 코드 소개

한명

1. 코드 리뷰 하는 사람

2. 코드 리뷰를 받는 사람

비포 애프터를 명확하게 한다.

모도코를 통해 서로를 피드백해보자!

메인 bootstrap
-> 좋은 코드 -> 스파게티 점진적

리액트 당근 개발자

• 과거의 좋은 코드리뷰 경험 우리의 시나리오

유튜브에 올려
-> 우리의 홈페이지에 다가도 올리자!

회사 홈피 = 사람들의 사용기

• 사람들의 사용기

• 유튜브, 댓글, 링크, 등

이번 이벤트는 사용기를 받을 수 있는 이벤트

• 어차피 소규모

• 이벤트 스샷

  • 보내 주는 사람들에게 보내줄 수 있으면 좋겠다.

결국 피드백을 산 것이다.

일단 일주일

모도코를 통해 코드리뷰 시도해보자

• 처음 매칭

• 커미터와 리뷰어의 매칭 데이

• 요런 이벤트 참여해줘

  • 모도코 공부하면서 이런거 만들었고

  • 우리가 예산이 있어. 너희들한테 줄게 이밴트 참여해줘!

  • 공부하는 학생이야.
    "회사가 아니니깐 오히려 오픈하자!"

디코에 공부하면서 사람들에게 어떤 역할할지 손들어!

Chain of Responsibility

Handler가 자기를 가리킴
next가 본인의 타입

• 스스로를 위임하는 꼴 = 다음의 핸들러를 위임한다

클라는 핸들러를 알면 돼

• 실제로 핸들러만 알면 돼?

  • ㄴㄴ

• 메인은 concreteHandler를 안다.

• 메인 입장에서는 체인이 만들어졌다면 주입된 핸들러를 이용한다.

다이어그램 상으로는 쉬움

버튼에서 이벤트 발생

• 다음 다음으로 책임 넘어감

내 질문

• 체인은 클라가 만듦?

• 우리가 만들어제공

중요한 것

• 이벤트 같은 것

  • 이벤트 처리자가 각각 있는 것

• 이벤트는 무엇인가?

  • Trouble()임

• 역할을 하는 support가 자기 역할을 하려면 문제의 상황을 정의해 줘야 해

  • 그래서 이벤트를 먼저 추상화해줘야 한다

클래스를 이용한 형상을 만드는 것은 쉬움
근데 문제의 상황을 만는 것 자체가 선행 되지 않으면 안 된다.

핸들러 처리 조건문으로 처리하면 되지 않아? 복잡하게 만드는 것 아니야?

• 첫번째. 트러블을 만들고 숫자 하나 넘겨주고 끝냄
  - 실제로는 단순 숫자가 아닌 컨택스트일 거임.
  - 컨텍스트? 화면의 좌표, 어떤 버튼, 스냅샷
  - 문제의 상황을 알려주고 처리할 수 있도록
  - 실제론 이 예제처럼 하드 코딩할 정도로 간단하진 않을 것

[멘토님의 예제] 라우팅을 한다 해보자
/route/a/d/e/f (O)
/route/a

• 보통 코드 짤 때 특정 Path 하나를 매칭하지 않음
  /route/a/d/e/f (X): 위의 프리픽스에 대해서 처리되어버려서 호출 안 됨. 이 핸들러로 넘어오지 않는다.
  /route/b
  /route/c

위와 같은 조건들이 밖에 정의되어서 주입될 것이다.
라우트 핸들러라는 것으로 개별적으로 객체화되어서 패스 조건에 맞는 것들이 연쇄적으로 next가 될 것이다. ex) 조건이 안 맞아. next()

1, 그래서 문제의 상황을 만드는 것이 먼저
2. 실제 문제는 외부에서 주입될 것이다.
그렇기 때문에 단순 조건문으로는 안 된다.

조건이 많더라도 추상화가 안 되면 이것을 못 쓴다.

만약 이 패턴으로 조건문을 줄일 수 있다면 코딩에 조건문이 없을 것. 근데 실제로는 조건문을 못 없애.
왜냐면 비교하는 것들이 단순 하나가 아니므로
if (isFirstRan && route == 'route/e')
각각의 종속 변수 isFirstRan같은 것은 다 추상화하긴 불가능

[정리]
외부에서 넘어온 것으로 핸들러를 만들 것이다,.
예제처럼 처리할 수 있는 핸들러는 보통 이렇게 new로 만들어 쓰진 못할 것

실제로 가장 많이 사용하는 경우

• 라우팅

• URL 전처리

Facade
퍼사드는 왜 쓴느 걸까?

• 클라이언트 관점에서 굉장히 쉬워진다.

• 레이어를 분리해서 PageMaker에

  • 메인의 책임의 범위가 줄어든다
    = 프로그래밍이 전체적으로 쉬워진다

• 메인과 퍼사드는 같은 조직. 그래서 숨긴다는 의미는 별로 없을 수 있다.

• 추상화는 아니다.

  • 추상화 안 함. 추상화를 했으면 공통점이 나와서 뽑아와야 함.

퍼사드는 왜 써?
어떨 때 퍼사드를 만들까?

유틸 헬퍼 퍼사드야?

주형이 피피티 첫 장

• 서브 시스템을 퍼사드를 통해 단순화한다

메일 발송은 서브 시스템인가?

• 퍼사드에서 얘기하는 서브 시스템은 3rd party 혹은 다른 패키지이다.

우리가 사용하는 Websocket이 써드 파티라면?

• 웹소켓의 많은 기능이 있지만 우리가 다 쓰진 않아

• Send Mail 유틸 메서드를 메일 발송 가능

• 써드 파티 모듈을 가져와서 걔네들을 가지고 와서 퍼사드로 만든 것

퍼사드

• 걍 코드 단순화 아님

• 서브시스템의 단순한 사용법임

퍼사드에서 다른 패키들에 있는 것 가져와서 쓴다

[중요] 퍼사드는 써드 파티에 있는 무언가를 사용하기 쉽게 만들어 준다

메일 발송 모듈같은 경우

• AWS code를 단순화시킴
  => 퍼사드로 가능
  => 오픈 소스니 패키지를 변경하자
  - 여기에 Send Mail만들어서 쓰면 돼

굳이 퍼사드 없이 클라가 메일 발송해도 돼.

• 이러면 안 돼

• 왜?

  • 오픈소스가 수정될 때마다 우리가 수정해줘야 되기 떄문

우리가 써드 파티를 이용해주는 퍼사드만 갈아끼우면 돼

• 클라까지 써드 파티 갈아끼우는 것에 대한 책임을 가지지 않아

• 퍼사드만 수정해주면 돼

퍼사드는 같은 플젝의 복잡도 높은 조각을 단순화시키는 것이 아니다.

• 퍼사드가 관리(운영) 책임을 가지며 단순화시키는 것

• 클라는 써드 파티 복잡도 모르고 운영 가능

만약 주형이 코드?

• 메일 발송 기능

• 한단계 단순화하면 퍼사드긴 해

  • 하나의 퍼사드 하나의 API 가능

내가 만든 모듈을 내가 복잡도를 낮추려면?

• 퍼사드를 만들어야 돼? 아니야!

  • 이건 굳이 우리가 바꿀 수 있는 코드를 스펙화하는 행위

• 당연히 클래스를 리팩터링하면 돼.

  • 스펙 버전 업하면 돼 (규격 바꿈)

  • 외부 공개용이 아니게 때문에 스펙이 없잖아.

같은 플젝인데 옆에 팀에서 쓰는 것정도는 퍼사드로 만들 수 있어

• 독자적으로 Versioning이 되고 있으니까 퍼사드로 만들 수 있어

브릿지

• 내 코드에 대한 리팩터링
  클라: 구현을 굳이 몰라도 기능만 알면돼
  기능이 구현을 씀

어댑터랑 다른 점?

• 어댑터는 소프트웨어가 릴리즈되어서 이미 동작 버전을 새로운 코드를 전환할 수 없을 때 쓴다.

• 우리 플젝의 버저닝에 관한 방법 중 하나.

• 레거시가 있다는 것
  피처가 바뀌고 버전이 바뀌었는데 과거의 코드를 바꿀 수 없을 때 쓰는것.

어댑터의 대상은?

• 같은 플젝 내의 과거 코드

• 규격이 다른 유형을 다른 (말그대로 어댑터 사용법)

구조가 왜 달라?
퍼사드는 최대한 써드파트를 보존하면서 가야돼
브릿지 구현 맘대로 <- 클라 관점에서 보는 것

http://docs.oracle.com
jdbc driver?
쓰려면? 커넥션 어캐해?

• 드라이버 매니저에서 커넥션 가져와.
  커넥션을 통해 Stmt가져오고 쿼리 날리는 것로 끝!

• 그 사이는? Class.forName("oracle.jbdc.driver.OracleDriver")
  Class.forName("oracle.jbdc.driver.MySqlDriver") // Mysql이면

Driver 매니저 뭐야?
어떻게 클래스.forName로만 MySql로 연결되지?

자바 개발자: jdbc 규격만 알면 아무 디비 사용 가능

• 자바 개발자 입장: 드라이버는 써드 파티

  • 어떻게 가져와야 할까?
    "com.mysql.driver"라는 클래스를 직접 보자
    NonRegisterDriver

  • static이넹?

    • 프로그램 시작될 때임.

    • 그럼 언제 시작? 이걸 참조할 때이다.

      • Class.forName("com.mysql.jdbc.Driver")를 참조할 때 com.mysql.jdbc.Drive의 클래스를 만듦

      • 바이트코드를 로딩하는 시점이 객체를 생성해? 아니다.
        - 코드만 로딩하는 것

      • static은 bytecode가 로딩 될 때 불어와진다.

=> 자바에서는 jdbc의 경우. DriverManager가 퍼사드다.
외부 드라이버는 그 솔루션 제공자만 안다.
개발자가 편하게 이용하려면?

• 써드파티하고 클라를 연결하기 위해 퍼사드를 만들자

• = DriverManager
  - 복잡도가 높다 = 네트워크 코넥, 코넥션으로 send recv하는 것이 다 여기에 있다
  - 퍼사드를 이용한 것이다!

퍼사드는 어떤 기준

• 서브시스템인가?
  = 규모가 있고 스스로 버저닝인가?
  = 옆 사람 모듈

http://www.yes24.com/Product/Goods/2745358

• 편집자 임성춘 대표. 정원용멘토님이 소개해줌

util, helper, common
조각 함수되면 똑같아
Util?

Helper?

• 헬퍼와 관련된 녀석은 그 폴더마다 있음.

• 폴더? 중간 그룹마다도 헬퍼를 따로 만든다.
  (예시)
  펑션 만들 때 이 단위의 기능을 만들기 위해 커먼이 있을 수 있어.
  구현이 같이 쓰는 커먼이 있고

펑션이 같이 쓰는 커먼 가능

env management가 쓸 만한 커먼이 있고

사용하는 범위에 따라 따로 따로 구현.
아니면 최상위에 헬퍼가 다 모이게 돼.

기능이 따라 공통 분모
각각의 폴더 및 기능 별로 분리

m2live.co.kr

• 회사 스펙

• 함수 하나하나가 다 솔루션급

내일 동영상 가능하면 공유
코드 리뷰 상황 추기적 회의 필요하면 말해줘!