Index
Date
의 회의록 마스터 : 윤영기
Participants
TEAM FIRE (고주형 윤영기 이하령) + WonYong Jeong
Discussion topics
프론트엔드 TODO
테마 적용 -> white noise 다운받기 : 방 입장 시 자동으로 실행
json 형태로 테마별로 잘 작동시키기
리팩토링
음성이랑 비디오 트랙 분리 혹은 sync 맞추기
로그인이 된 사람이라면 바로 /main 으로 전송
혹은 로그인이 안되어 있다면 /landing 으로 보내고 기존 회원을 /main 으로 둘까?
정원용 멘토님
협업 시 팀플
전반적인 수준 높은 사람
수준 낮은 사람에 속도에 맞춰진다
-> 결국에는 배제
이슈를 팀으로 진행하면 더 많은 시행 작업
자기 파트는 자기가 메인
-> 많이 시행 착오 = 다른 사람과 협업시 경험으로 대응
나의 퍼포먼스를 메타인지하자
이슈가 안 넘어간다
-> 이슈 현실화를 해야 한다
수면 아래의 이슈를 수면 위로 올리는 시도를 하자
작업 태스크로 들어나지 않는 많은 것이 존재한다 .
개발하다 막힘
디자인 진도가 안 받혀줌
스터디를 해야 함
15챕터 Persad - 단순한 창고
클라 -> 타깃봄
원래 코드 -> 업댑티
왜 굳이 어댑터 ?
클라이언트 입장
클라를 보자
협업
클라: request 규격으로 개발
백 : req 규격대로 개발
어댑터 입장
어댑터는 짜증: 레거시를 감싸서 편리한 유틸리티 제공
어댑터 입장:
어댑티를 다시 만들어 !!
규모 별로 안 크면 다시 만들어
과거 MS: 프로그램 코드 중에서 파일 읽기 코드 개발
파일 리드는 쉽다
레거시 코드 너무 많아
그래서 다른 사람이 다시 개발 -> 잘 돌아감
갑자기 정말 알 수없는 곳에서 에러
파일리드를 하는데 네트워크 연결이 안 되면 안 됨
-> 크래쉬
NFS를 사용하는 상황에서 원격에 대한 파일 읽을 때 파일 리드 실패!
-> 이걸 예외 처리 안 함
원본 코드를 봤더니 모든 상황에 대해 예외처리가 되어 있었다
-> 기존 코드를 다시 이용하기로 결정 / 어댑터를 만들어서 쓰기로 했다
이것이 바로 어댑티
프로그램의 완결성은 높지만 재사용성은 너무 떨어져서 활용성은 별로인. ADAPTEE
Adapter를 만든다면 2가지
수많은 기능을 인터페이스로 뺘기
타깃에서 제공해주는 메서도만 중간자 입장
클라의 입장과 어댑터의 입장은 다르다.
클라. 자기 필요 기능만
어댑티. 어댑티 수많은 기능 노출 어떻게 해..
-> 가장 빠른 방법: 편리한 메서드를 제공하고도 기존의 메서드를 재공
상속이 안 되는 경우?
생성자, 메서드 파라미터 규격이 현재 어플과 상이할 때
어댑티가 사용하는 int등의 규격이 맞지 않을 때 => 클라가 해야할 일이 너무 많다. => 어댑티의 규격을 버리자 => 위임하자
상속의 방식 vs 위임 방식 (2가지 방식)
상황을 가정
어댑티
v1
v2
재사용 많이 있음
v3
또 다른 레거시
어댑터를 만드는게 맞는데...더 유지보수하기 어려워지는 것 아니야?
제어하기 더 어렵게 만드는 것이 아닌가. (어려운 문제..)
의외로 답이 쉬움
어댑터가 유틸리티가 되는 순간 v3는 걷어낼 수 없는 레거시가 되는 것
어댑터는 어댑터의 역할만 해야돼..
어댑터의 책임 범위를 좁혀야 레거시가 되지 않는다.
가장 주의해야 할 점. 어댑터의 책임 범위를 줄인다.
어댑터 네이밍?
레거시가 있는 상황을 개선하고자 할 때 어댑터라고 부른다
원래 어댑터 의도 외에 넣으면 레거시가 된다
본인 코드면 가급적이면 어댑터를 만들고 싶지 않을꺼야...
정상적인 코드 수정했다 고장나면 돌이킬 수 없어서 쉽지 않다.
원코드가 리팩토리 코드가 안 돌아가 => 리팩토링 너무 넓으면 그 접점을 못잡아서 3개월치 리팩토링을 버린다.
써드 파트 , 레거시의 유틸리티가 되면 ? Helper가 된다.
질문. 종류가 너무 많아요. 작은 부분에서 달리지는 것 같아요.
어댑터 = wrapper면 모든 상황이 adapter가 될 수 있다
첫 페이지
이미 제공과 필요한 것 = legacy와 new feat
여러 db추상화 제공 = legacy가 아님 = 버전업의 개념이 아니다 = 구조의 추상화이다
현재 동작하고 있는 여러 형제의 개념
뭘 선택하든 같은 인터페이스로 수정
= 레거시가 아니라 헬퍼가 필요하겠거나 or 퍼사드(단순 유틸) or 더 나아가면 미디에이터
그래서 퍼사드라고 얘기한 것이다.
어댑터 = 레거시 봉인하고 필요한 것만 찾아쓰는 것을 만들자!
패턴 공부하다보니
(지난번) 완벽 똑같 다이어그램. 의도가 달라서 이름이 다르다.
똑같은 기술의 구현이더라도 의도가 다르면 다르다.
기술적 표현 방법 같지만 확장하는 방법이 다르다.
여러 맥락을 보며 풀어놓은 것이 패턴
템플릿 메서드 패턴
오리사진
LSP를 잘 보여주는 예시
OCP는 좀 아님
(여기에 필기하신거 적어주세요) 이하령
상위클래스 → 처리 흐름 만들고
하위 클래스 → 그 흐름에 대해 구체적인 내용을 결정한다.
abstract factory? 7 chapter
내용이 많음. 이 내용은 사실상 template method pattern
처리 흐름을 결정할 수 있는 방법을 이렇게도 줄수 있다고 알려주는 패턴.
abstract클래스가 template method를 통해 처리 흐름 결정
동작을 template method로 만들었으니까 무엇을 들지는 concrete class 가 알아서 해!
처리 흐름을 ㄱ정의할 수 있어야 template method pattern 을 쓴느 것.
어떤 흐름이 고정되어 있고 그 흐름을 채우는 부품이 유동적이면 template method pattern.
고정된 흐름이 없으면 template method pattern이 아님
나한텐 알고리즘을 갈아끼우면서 동작을 하게끔 만들고 싶어!
→ template method pattern은 효과적이지 않을 수 있다.
순서와 흐름을 정하면 템플릿 메소드.
난 알고리즘을 정의하고 싶으면 → str… pattern
기승전결을 무엇으로 채울지는 하위클래스가 알아서 해!
이 패턴을 쓰는 의도가 있다.
추상메소드 외에는 public으로 만들지 말아라..!
업캐스팅할 때 전혀 문제가 없어야 한다는 원칙 → LSP
solid 중 L에 해당됨. (Liskov 치환 법칙)
모양새가 같지만 의도가 다르다면 전혀 다른 클래스.
상위 클래스로 업캐스팅 할 수 있어야 올바른 추상화이다!
제약이 줄 수 있는 상황이 되어야 template method pattern 쓰는데 유용하다….
회원가입 단계를 만들 때 가입 단계에 대한 절차 → 템플릿 메소드를 만들고 방법적인 것은 알아서 구현해..!
단계에 대해 유동적으로 만들어야 겠어 → 템플릿 메소드 변화하게 될거고..
우리가 알고 있는 분명한 sequence (월화수목금토일 과 같은)가 있어 줄 때 템플렛 메소드가 역할을 발휘한다..!
템플릿 메소드가 제약을 주는 상황이 확장이 닫혀있는 구조로 만들어 줄 수 있다.
템플릿 메소드는 사실 리스크일 수도 있다.
어떤 관점에서?
solid 중에 OCP open closed principal 확장에는 열려있고 수정에는 닫혀 있다. 작성된 클래스에 대해 수정하지 말고 확장하게 해라..
but! 템플릿 메소드 같은 경우 기획이 바뀔때마다 수정된다..
LSP 관점에서는 좋지만 OCP 관점에서는 물음표가 든다..!
흐름 정의 할수 있는데 상속되지 말아야 한다. → 범위가 좁혀져야 한다.
굉장히 좁고 분명한 범위에 대해 템플릿 메소드에 대해 정의해주어야 수정할 일이 없어진다.
legacy : 새로운 동작을 정의할 때 기존에 같은 동작이 있으면 그게 legacy
코드로 자기의 생각을 잘 표현한다 → 머릿속에서는 모국어를 통해 본인의 생각이 정돈이 되었다는 이야기.
내가 이렇게 개발할거야 라고 정의가 되어 있어야..
모국어 잘 하는 사람이 코딩을잘한다..!
막힐 때는 글쓰기와 비유하면 좋을 것 같다.
지식은 있는데 어떻게 풀어야 될지 모르겠다. → 내 머릿속에 있는 것을 한국말로 하는 것이 정돈 안된걸수도.
정돈이 체계적으로 된게 디자인 패턴..!!
어댑터
순기능 => 공백 메꾸기
추상 메서드 구현하기 귗ㄴ
레거시?
새로운 동작 (예전 코드<- 레거시)
가장 레거시
v1다음 v2를 만들 때 v1
오래된 코드를 바라보는 관점
이미 동작하고 있어서 조심스럽게 다뤄야 하는 코드
레거시 나두고 하얀 백지에 작업
어댑터는 레거시를 갖고 있는 상황을 어느정도 전제
패턴 공부 어때 ?
재밌는데 좀 어려워
ㅇㅇ막연함이 있어
근데 재밌습니다.
나는 코드와 관련해서 막연 및 막힘 => 글쓰기의 추상이 코드 추상이 덜하다
[여담]
코잘
= 코드로 자기의 생각을 잘 표현 = 모국어로 본인 생각 정돈 된 것임
= 말잘함 = 코잘 = 막힐때는 글쓰기와 비교
정돈이 조금 더 체계적으로 된 것이 디자인패턴임. 그래서 글쓰기로 비교함.
다음주에 휴가 감. 멘토링 안 함.
4, 5챕 => 영기, 하령
발표 자료 18일이 마감일
이거부터 ㄲ
중간 평가
발표 시나리오 필수
자칫 단순 기능 데모 = 그 다음이 보이지 않을 수도..?
가치를 인지하는 것은 우리만임
가치에 대한 정의를 심사위원에게 전달해줘야 한다.
방법은?
제일 좋은 방법 각자 코딩.
학습 효과에 대한 데이터
지속 가능한 학습
현재에 대한 우리의 좌표를 약간의 시나리오로 고민해보자
한 시간 녹화 VS 우리 가치 제시 (수면 위로 꺼내보자)
발표 멘트 추천
남은 하반기를 그 가치를 실현하는데 쓰겠다
