FIRE WIKI : 2022-11-17 정원용 멘토님과의 마지막 멘토링ㅠㅠ

Index

 Date

2022. 11. 17. 의 회의록 마스터 : 고주형

Participants

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

 Discussion topics

화면 공유 중에 어떤 것을 할 것인가?

기능 소개보다 시나리오

이 서비스를 지속할 동기를 셀프 스터디를 하며 보여주자

[하책]

지금 시나리오상 무언가를 보여주며 이렇게 쓰면 좋다

[바람직 - 플랜 B]

현재 구현을 데모로 보여주고 거기에 대한 피드백 받을 것을 본 과정 이후에 이렇게 마무리 될 수 있다

[플랜B - appeal point]

1. 아무리 못해도 데모에서 심사위원들께 이 기능이 정상 동작한다는 것이 검증됐고 서비스했다

2. 사람들께 피드백 받아서 투두리스트 있다.

[플랜A] - 입장하고 난 뒤에 데모 내용이 중요

(!) 떠오른 것: 초반 기획 중; 현재 구현과의 diff = 통계

• 통계가 없다 (증거 인멸 완료)

리텐션 가능!

우리 제품이 리텐션이 일어날만 한 것임을 알려주자!

• 모도코가 실제로 트렌디하고 관련 서비스가 우후죽순 나타나고 있다는 것을 보여주자

• 심사위원이 공감할 수 있는 데모를 만들자!

다른 방안: 이벤트를 하자

• 발표 시각에 이미 사람이 있다.

  • 아침: 모으기 어렵

근데 사람들이 참여중이더라도 어필이 힘들것이다.

• 쓰고 있더라도 스틸샷 뿐

대본을 짜보자!

• 발표자의 상황이 아니라
  각자 개발을 쭉함

• 켜져 있는 상황에서 개발 쭉 함.

시나리오 : [cowork하는 입장]

내꺼 한번 봐줘
나도 다함 내께어 붙여봐

시나리오 : [모각공]

서로 음악을 틀어놓고 공부함

결국은 이렇게 접근하자!

• 발표 자료가 많으므로 데모는 길어도 2분이다.

맥락 소개 먼저하자

[먼저 심사위원들에게 맥락을 얘기하고 기능 소개를 하자 ]

2분 동안 데모는 상황 설정하고 보여주자.
= 빠듯할 듯

이미 기능 상으로 이미 베타 테스트
준상용 - 심사위원들도 참여 ㄱㄴ

[하령님] PPT

모든 기능 데모 VS 시나리오 기반

우린 준상용화 했기 때문에 우리가 의도한 시나리오 가는 것이 더 좋다!

• 제품 != 기능

• 제품의 의도, 메시지, 컨택스트를 설명할 수 있는 데모를 하자!

• 기능 위주 팀과의 차별화가 될 것이다.

심사위원의 평가 방식

심사위원은 줄 세우고 상대평가를 한다
=> 기왕이면 더 높은 성적을 받을 수 있는 데모를 하자

while(여러 컨텍스트){
   어떤 컨텍스트 사용해 ! 
     -> 데모해볼겡
}

=> 심사위원들에게 공감을 DI

대모 준비 팁

데모를 준비하자!

어? 이거 짧은데 정도가 적당하다.

너무 많이 보여주려 하지말자
-> 궁금하면 물어볼거임

TODO

• context 2개 정도 준비

시나리오 아이디어 2개

팀 시나리오

-> 비번

모르는 사람 시나리오

-> 공개방

하령님 발표 초안

1. 도입부

이미 모각코인지 많음
-> 실행해보니 게시물 엄청 반응

현재의 모각코의 니즈다
-> 단순 온라인이 아님 사람들이 적극 참여하더라

데이터 던지고 맞더라! 틀리지 않더라!
맥락 잘 주입 가능!

2. 진행상황

기능만 추가 됨
사진만 추가 수정

3. 베타 출시

추가적 이벤트 : 코드리뷰

통계 자료

설문조사 피드백

비지니스 모델 (?)

• 광고만으로도 유지 된다

부하테스트

• P2P media 10만

• 사람들

BM

BM 슬라이드 만드려면?

어차피 BM에 대해서는
-> 가장 먼저 떠올릴 것은 해당 과금형태에 익숙할만 것이 있느냐

우리 역시 익숙한 형태로 과금한다
-> 굉장히 타당하다

우리가 어필할 수 있는 것은 이것이다.
-> 우리 서비스와 같은 이용 서비스

우리도 어디에 과금이 먹힐지 모르고 심사위원도 모르기 때문에
-> 레퍼렌스상 여기서 결제가 비번하게 이루어졌으니 우리도 거기에 따라가겠습니다.
-> "다른 레퍼런스 기준으로 우리 재품에 투영해봤구나"만 되면 OK

BM 정리

일단 결제가 낯설지 않다는 것을 보여주자!

• 그러면 ㄱㅊ

지표상 불리한 것만 빼

자신감있게 가!

향후 계획

데이터기반으로 가자

피드백 받은것 중
-> 우리 팀 내에서 의미있게 분류한 피드백

이 장표의 결말

우리가 생각한 것 = 사람들의 준 피드백

이런 인식을 주자

이 팀은 데이터를 기반으로 가구나

그림을 생각 없이 가냐.. 데이터를 기반으로 가냐..의 차이!

MVP와 베타 테스트 구분이 됨?

어필 포인트 1. 빠른 개발

심사위원들이 많이 점수를 줄만한 포인트

우리는 완성도 높이기 위해 계속 버전올리고 실제 사람까지 사용을 했다

이런 인식을 주자

다른 팀은 MVP가 이제 나왔는데 우리는 여름?!

그럼 나머지 기간은 기능 보강이 이만큼 됐다구?! 버그도 많이 잡았겠군!!

이런 인식을 가지면
= 우리한테 좋은 질문 던지기 시작할 것

어필 포인트 2. 기능 업데이트, 성실

• 소마 기간 놀지 않고 의미있게 시간을 잘 썼다는 것을 보여주자

• 우리 캘린더를 보여주자!

  • 고생한 것을 유머있게 잘 풀어낸 애들이 점수 잘 받더라!

열심히 한 애들이 높은 grade 받도록 줄을 세운다.
=> 놀지않고 고생했다는 것을 보여주자

디자인 패턴

Command Pattern

예제

누가 invoker야?

main이 invoker?

Command는 분명한데 주변에 Invoker, Receiver가 누구인지 구분하기 어려워

[중요]

커맨드 패턴은 Invoker, Receiver를 구분해야 된다

커맨드를 가진 녀석 누구야?
Invoker이다.

커맨드가 가진 것은?
Receiver이다.

다이어그램으로만 보면?
=> invoker에 의해 Command가 호출 될 수 있고 Command에 대한 것이 Receiver로 호출될 수 있다.

예제 다이어그램을 보자

커맨드를 가진 녀석 = invoker
누구야?

Drawable이 Receiver다.
이것의 구현체니깐 DrawCanvas는 Receiver.

Invoker는 누구야?
= 커멘드를 가진 녀석
하나가 아니다.
후보가 3개다.

• Main

• MacroCommand

• DrawCanvas

근데 MacroCommand는 이미 역할이 있다.
= Concrete Command

Main이 history를 만들고 DrawCanvas의 생성자로 갔다.
= DrawCanvas로 주입했넹

DrawCanvas에서도 보니 생성자로 history받아서 멤버 변수에도 주입하넹.

[해석]
history에 대해서 역할을 하는 것은 누구야?

역할한다는 것은 무슨 말이야?

• Command가 역할한다 = execute() 호출

Command에 있는 execute를 실행해주는 녀석이 invoker이다.

DrawCanvas든 Main이든 execute하면 Invoker다.

DrawCanvas 보니 history.execute()함
Main보니 drawcommand.execute()함

• 따라가 보니 canvas가 결국 execute()

따라서 DrawCanvas가 Invoker가 되겠구나!

DrawCanvas가 Invoker이면서 Receiver이다.

정리

커맨드 가진 녀석 = Invoker
커맨드가 가진 역할을 하는 것이 = Receiver

한 가지 더 이야기

DrawCanvas의 draw는 누가 호출?
= ConcreteCommand

그럼 콘크리트 컨맨드가 누구?

• DrawCommand

MacroCommand는 아니야?

• ㅇㅇ. draw메서드 없어.

• execute 반복문은 전부 DrawCommand야
  = 실제로 호출해주는 것은 DrawCommand야

paint 메서드는?

Draw Method드는 Drawable override했어.

paint메서드는 누가 호출할까?

• 매크로컨맨드는 아님

  • 매크로 커맨드에서 보면 execute외에는 걍 자구 관리 코드임

• DrawCanvas도 paint 호출 안해. 아니야.

• Main도 paint 호출 안해

우리 코드만으로는 paint 호출 시점이 안 나와!!

paint 호출 정답

sequence 다이어그램 보면?

• 매크로커맨드의 excute시점이 있음.

정답: 자바 그래픽스 메서드이다.
자바 awt 프레임워크에서 호출하고 있다.

Main은 awt에 다시 그려줘 => awt가 알았어 내가 그릴 수 있을 때 그릴겡

paint는 awt에 의해 콜백이 됨.

GoF 다이어그램. 똑같애.
그냥 간소화해서 그림.

실제 비지니스 로직
= Receiver

Command는 뭘해?

• 추상화야!!

  • 적당한 것을 호출하는 것이 아니야!!

우리 예제는 뭐를 추상화했니?

• position이야

우리가 Command의 Concrete를 보려면?

• Position을 찾아야 해

Command 패턴을 만들려면 실제로 추상화할 것이 있다.

• 어떤 데이터를 추상화할 것인가가 가장 중요하다.

• 그것을 클래스화한 것이다.

영기님 예제는

• 키정보이다

[정리]

Main은 클라임.
실제 비지니스 로직은 Receiver가 가짐.
Receiver는 Command를 호출.
그 Command는 Client가 만듦.

[생각할 것]

• 추상화 대상

• 관리 주체

• 처리하는 주체

커맨드만 잘 추상화하면 되지 X

Interpreter Pattern

그냥 하령님이 설명하면 끝남.
첨언할 것이 없다.

질문 1. TerminalExpression은 왜 끝이야? (기능적으로)

포함 관계를 가지지 않은 녀석이 한놈. 그래서 다이어그램상 TerminalExpression

해당 동작 자체를 의미한다.

잘문 2. NonterminalExpression

해당 기능을 수행하는 명령어.
파라미터를 필요로하는 문법 같은 것이다.

ex. let 같은것.
let은 필수적으로 변수명 수반 = nonTerminal

질문 3. 패턴보여?

Composite Pattern이 보인다
-> Tree의 형상을 만든다

이 모습이 트리를 만드는 형태
= 이런 모습보면 재귀가 가능하구나!

공부 순서 추천

객체지향설계(SOLID 등) 원칙, 클린 코드, 클린 아키텍처

다음에 보자

다음주 발표하고 잠깐 있다 오면 딱돼
성수 12:30에 보자