[TIL] 페어프로그래밍, api fetch(with Week5 Mission), DP

오늘의 나는 무엇을 잘했을까?

1. 첫 페어프로그래밍!
   Week5 미션을 페어프로그래밍으로 진행했다. 케니와 페어가 되어서 리팩토링이 완료되자마자 진행했다. (비교적 다른 팀들에 비해 매우 빨리 한 듯) 헷갈렸던 개념, 몰랐던 방식을 많이 알게 되어서 정말 유용했다! 사실 내가 케니한테 도움이 된지는 모르겠.. 죄송해요..😭

   페어프로그래밍은 애자일 개발 방법론 중 하나로, 하나의 컴퓨터에서 두 사람의 프로그래머가 작업하는 방법이다. 팀워크와 고품질 소프트웨어 개발에 도움이 많이 된다고 한다.

• 그러나 효과가 즉시 나타나지 않고, 한대의 컴퓨터에서 두병의 개발자가 함께 하는 것이 간단하지 않아서 많은 개발자들이 불편함을 느끼는 이유로 현업에서 적용하는 곳은 많지 않다고 한다.

크게 2가지 방법이 있다.
① 역할 정하기 + 뽀모도로 기법

• Driver와 Navigator로 나누어 진행한다. Driver는 훈수를 듣는 사람, Navigator은 훈수쟁이라고 보면 된다.
• Navigator는 관찰자의 입장으로 코드를 검토하고 지식을 전달하며 생각을 공유한다. 코드의 세부사항은 Driver에게 맡기고 Driver보다 더 넓은 관점으로 설계, 구조에 대한 문제와 버그를 파악하는데 집중한다. Navigator는 Driver의 흐름을 방해하지 않도록 목표가 끝난 뒤 아이디어나 잠재 요소에 대한 내용을 토론!
• 뽀모도로 기법으로 교대 시간을 정한다. 정통적으로 25분에 한번 역할을 바꾸고 3~4회 시행 후 15분 정도 충분한 휴식 가지기!

② Strong-Style Pairing
Driver는 Navigator가 지시하지 않은 어떤 작업도 수행하지 않는” 방식
따라서 Navigator가 작업에 대해 훨씬 더 많은 경험을 갖고 있고, Driver가 언어나 도구에 대한 초심자일 때 유용하다. 구현중 발생한 이유에 대한 질문은 목표 구현 후 논의되어야 하며, Driver는 Navigator를 "전적"으로 믿어야한다.

사실 우리는 두가지의 방법을 구분하지 못한 채로 시작했는데, 자연스럽게 1번을 선택해서 하고 있었다. 25분마다 훈수쟁이가 되기!! ㅋㅋㅋ

오늘의 나는 무엇을 배웠을까?

[1] 일반적인 컴포넌트 만들기

즉, 어떤 기능에 종속적이지 않은 "바보" 컴포넌트를 만드는 것이다.

이런식으로 리팩토링을 하긴 했지만,
1. cardListComponent 안에서 api fetch를 진행했다.
2. url을 attribute에서 받아왔다..(진짜 안좋은 코드😂 서버 url이 노출되는..)

기존엔 이런 문제점이 있었다. 여기서 문제는 어떻게 분리를 할지 모르겠다는 점!!
나름 컴포넌트 안에서 api fetch를 하는 것(데이터가져오기)이 이상하다는 생각을 하긴 했는데, 어떻게 분리할지 감이 안잡혔다.

하지만 페어프로그래밍을 하면서 해답을 찾았다!!
바로 shared.js에서 fetch를 해오고 그 데이터들을 prop으로 넘겨주는 것!

• shared.js
  

이런 식으로 컴포넌트 요소를 선택한 뒤 fetch를 진행해 받은 response data를 컴포넌트.prop을 해주게 되면 set prop이 호출되는 것이고, 따라서 해당 컴포넌트의 private #prop을 set해주게 된다.

사실 지금의 코드는 (필요에 의해) 새로 생성한 folder 컴포넌트이지만 로직은 동일하다.

set을 하게 되면 set안에서 showFolderInfo() 메소드가 실행되고, 이 메소드가 바로 요소들에 prop값을 넣어주는 것이다.

처음 렌더링이 되었을 때 connectedCallback에서 호출된 render() 메서드에서 this.shadow.innerHTML 속성에 템플릿 리터럴을 할당함으로써 컴포넌트의 Shadow DOM에 DOM 요소들이 동적으로 생성된다.

그 이후 set prop이 실행되면 그 안에서 호출된 showFolderInfo()메서드가 실행된다. 이 showFolderInfo() 메서드는 위의 사진처럼 this.prop에 있는 값을 가져와서 해당 값을 가진 DOM 요소의 속성이나 텍스트를 변경하는 코드다. setAttribute()와 innerText를 사용하여 DOM 요소의 속성이나 텍스트 값을 변경한다.

따라서, FolderInfo 컴포넌트의 prop 값이 변경될 때마다 showFolderInfo() 메서드를 호출하여 DOM 요소가 업데이트되는 것이다. 이렇게 함으로써, 컴포넌트는 변경된 상태를 반영할 수 있다.

참고로 fetchFolder 함수는 비동기로 작성했다.

[2] shadowRoot의 child를 삭제는 직계 자식만 가능하다

this.shadowRoot.appendChild(gnbContainer);
this.gnbContainer.appendChild(loginButton);
this.shadowRoot.removeChild(loginButton); //error

예를 들어 이런 코드는 node를 인식하지 못해 remove 할 수 없다고 에러가 뜬다(=NotFoundError). 그 이유는 loginButton의 경우 gnbContainer의 자식이고 gnbContainer가 shadowRoot의 자식이기 때문에 그렇다. 즉,removeChild()가 shadowRoot에서 직접적으로 loginButton 요소를 찾지 못하고 오류를 발생시키는 것이다. 따라서 loginButton 요소가 사용자 정의 요소의 shadowRoot의 직계 자식이 아니기 때문에 remove를 수행할 수 없다.

이를 고치기 위해선

this.shadowRoot.appendChild(gnbContainer);
this.gnbContainer.appendChild(loginButton);
this.gnbContainer.removeChild(loginButton);

이렇게 수정하면 된다!

[2] DP - Tabulation, Memoization

1. Tabulation

• Bottom-up approach
• 단순히 반복문을 이용하여 밑에서부터 값을 계산
• 단점 : 표를 하나씩 밑에서부터 채워야 하기때문에 필요없는 값을 계산해야 할 수도 있다

2. Memoization

• Top-down approach
• 큰 문제를 작은 문제로 나누어 풀다가 계산할 값을 만나면 캐시 메모리를 먼저 확인하고, 답이 없다면 계산을 한 뒤 캐시메모리에 계산결과를 기억하게 하는 것
• 이미 계산한 값은 또 재귀로 계산할 필요가 없으므로 2N의 시간복잡도, 즉 O(n) 의 시간복잡도를 가진다.
• 장점 : 재귀를 이용하기 때문에 값을 위에서부터 계산하여 필요 없는 계산은 안해도 된다.
• 단점 : 스택이 너무 많이 쌓여서 과부화가 걸려 문제가 생길 수도 있다.

오늘의 나는 어떤 어려움이 있었을까?

1. 페어프로그래밍에 굉장히 많은 시간을 쏟아서 자료구조 공부를 거의 못했다. 하루의 목표를 잘 못정해서 (분량 초과) 못지키고 있는 것 같다. 널널하게 잡아야할 것 같다. 하루 할 일을 끝마쳤을 때의 쾌감도 있는 법이니!

2. 오늘의 황당한 실수 ㅋㅋ
   
   알고리즘을 python으로 풀다가 뜬금 console.log ㅋㅋㅋㅋ

3. git rebase를 eva-week5이 아닌 main 에서 하다..
   지금까지 잘못 알고 있었던 점이, eva-week5의 베이스를 main으로 하려며 main에서 git rebase eva-week5를 해야하는 줄 알았다. 그래서 했는데.. 아니었다 ^^ 반대였던 점..ㅎㅎ
   케니랑 제리한테 도움을 청해서 reset과 revert를 했지만 꼬였고.. 혼자 새벽에 끙끙 거리다가 해결!
   

내일의 나는 무엇을 해야할까?

• 페어프로그래밍 UpdateTime 계산 부분 구현 -> 완성!
• 알고리즘 패러다임 완강, 기본 자료구조 1/2 듣기
• 알고리즘 1문제