[ TWIL 3주차 ]

- 코드스테이츠 11일차 (5월 18일)

• git 명령어에 익숙할 겸 git으로 init한 다음에 clone을 했더니 이미 파일이 있어 안 된다는 에러가 나왔다. 예전에도 이것 때문에 고생했다ㅜㅜ 다시 폴더를 삭제하고 곧장 clone을 했더니 잘 된다. 구글링해보니 clone이 local의 init과 같은 기능이더라~ clone을 하면 init을 하지 않아도 자동으로 .git이 설치된다. bare repository도 함께 봤는데 아직은 잘 이해가 안 된다. 좀 더 살펴봐야지

• 유사 배열((arguments, DOM에서 가져온 html element들)을 배열메소드로 모든 배열요소에 접근하고 싶을 때가 있다. 그럴 때 3가지 방법이 있다.

  유사배열을 배열처럼 사용하는 방법

  1. for ... of  구문

  2. [ spread 연산자 ]
  3. Array.from

• 즉시실행함수(IIFE) 는 언제 쓰는 걸까?

  ​ 즉시실행함수는 이름 그대로 생성과 동시에 실행하는 함수다. 인터프리터가 해당 코드가 적힌 라인에 도달해야 해석되고 실행되는 함수표현식과 똑같이 작동한다. 다만 함수 표현식은 해당 스코프 안에서 재사용이 가능하지만 즉시실행함수는 단 한 번만 사용할 수 있다는 점에서 차이가 있다.

  ​ 너무 사소한 기능이라 (예를 들면, 나이에 따라 닉네임에 '님'을 붙이거나 안 붙이는 등) 이름을 붙이고 어느 변수에 할당하는 과정이 불필요하게 느낄 때 좋은 것 같다. 혹은 클로저의 모듈패턴을 익명함수로 활용하고 싶을 때 써야겠다.

  ​ 함수 선언식처럼 글로벌 스코프에 저장되어 성능 저하를 일으킬 가능성을 줄인다는 점에서 많이 사용되면 좋겠는 걸?하고 생각했다. 하지만 어느 글에서 즉시실행함수가 실행 후 메모리에서 삭제되는 걸로 보이지만 그 잔재가 개발자에서 접근할 수 없는 영역에 기록된다고 한다. 쓸거면 let, const,var와 같은 키워드를 쓰지 않고 변수에 저장한 후 그 다음 라인에서 delete 키워드로 삭제하라고 권한다. 키워드 쓰면 delete로 삭제가 불가능하기 때문이다.

• TDD(Test Driven Development) 연습 시작!

  ​ 오늘과 내일 걸쳐서 TDD 방법을 익히기 위해 Mocha, chai를 다룬다. 아직 익숙하지 않아서 대체 내가 뭘 작성하고 있는가 머리가 혼란스럽다.

- 코드스테이츠 12일차 (5월 19일 )

• solo check에서 rest parameter 문제를 틀렸다.

  ​ 어제 잠깐 봤던 문서가 떠올라 틀린 닶을 골라버렸다ㅜㅜ 뭐 다시 정확한 쓰임새를 알게 되었다. arguments처럼 rest parameter가 유사 배열인 줄 알았더만 배열이 맞다는 걸 알았다. 크롬 디버깅으로 테스트해보니 정말 곧장 배열 매소드를 사용할 수 있었다. 항상 Array.from으로 배열 변환후 실행시켰는데 앞으론 안해도 되겠군. rest parameter 형식을 취하면 자동으로 배열 인스턴스로 만든다고 한다!

• TDD | pair programming

  ​ 항상 하던 for문으로 풀기 싫어서 재귀함수를 활용해서 문제를 풀었다. 이중 for문이나 if문 중첩을 피하니 한결 깔끔해졌다. 좀 더 코드가 간결해질 수 있을까 고민해봤지만 주어진 데이터가 워낙 규칙성이 없어서 힘들었다. 나중에 sprint review시간에서도 이건 노가다를 해야하는 문제라고 했다.ㅋㅋ;;

  논리적으로 문제가 없어보이는데, 앞선 문제들은 잘 통과되었는데 에러가 떴다. 대체 무슨 문제인것인가???? 재귀함수가 무한루프를 도나 싶어서 구글개발자도구로 디버깅했는데 잘만 돌아간다.ㅜㅜ 아무래도 stack overflow 문제인가 싶어 for문을 나눠서 실행시켰더니 무사히 통과! 재귀함수가 코드를 간결하게 해주는 장점이 있지만 데이터가 많을 경우 stack overflow 위험이 있어 조심스럽게 사용해야 한다는 말을 들은 적있는데, 여기서 마주칠 줄 몰랐다! 어휴... 일단 재귀함수는 사고를 확장하는 데 의의를 두고 잘 쓰면 안 될 것 같다.

  ​ 저번 주말에 MDN에서 배열 메소드와 문자열 메소드를 하나하나 읽어봤다. 처음 본 메소드들의 기능을 보면서 이런 것도 있었구나? 나중에 써먹으면 좋겠다 생각했다. 오늘 빛을 발했다. 특정 문자열 길이를 만들어 예시를 여러개 만들어야 하는데 일일이 예시를 만들긴 노가다성이 다분해서 자동적으로 만들 수 없을까 고민하다 특정 문자를 반복시켜주는 String.repeat 메소드를 떠올렸다! 새로운 아이디어로 문제를 풀어서 신선했다. ㅎㅎ 뿌듯하다!

• sprint review 시간

  ​ 알고리즘을 잘 짜고 예외처리를 잘 하고 디버깅으로 버그를 잘 찾는 것만 생각했다. 그런데 코치님께서 이 과정 전에 미리 경우의 수를 따져 예상되는 결과와 실제로 실행시켰을 때 결과를 비교하는 테스트를 작성하는 것이 좋다고 말했다. 새로운 시각이다. 시간이 오래 걸리겠지만 앞으로 틈틈히 연습해봐야겠다.

- 코드스테이츠 13일차 (5월 20일)

• closure의 의미를 프로그래밍적으로 이해하기

  ​ 클로저 즉, 함수 안에 이너함수가 선언당시의 자신이 있었던 scope를 기억한다는 말은 마치 코드가 살아있는 것처럼 묘사되어있어서 좀 더 깊숙히 , 근본적인 과정을 알고 싶어졌다. 그래서 정규 시간 전에 짬을 내서 js 변수 할당을 구글링해봤다. scope를 기억한다는 게 내부적으로 어떻게 동작하는 지 알 수 있었다.

  function이 생성될 때 function 객체는 scope chain이라는 프로퍼티 안 에 파라미터 포함한 local 변수들을 저장한 객체 참조값을 0번째로 저장한다. 그 다음 상위 함수의 local변수들이 저장된 객체를 저장하는 과정을 반복 후 최종적으로 global객체 참조값을 저장한다. 그래서 하나의 함수를 실행시켰을 때 먼저 자신의 scope 영역에서 참조할 변수를 찾고 못 찾으면 상위의 참조할 변수를 찾는 과정(chain scope에 저장된 순서)을 거치는 것이다.

  ​ 더 깊게 공부하면 머리가 아플 것 같아 여기까지하고 나중에 다시 더 깊게 공부해봐야지.

• solo | html 과 css를 활용해 프로필 만들기

  ​ 노마드코더라는 사이트에서 진행하는 코드 챌린지가 있는데, 특정 강좌를 주어진 기간 내에 완주하고 매일 내주는 과제를 수행한다. 그 중 html과 css 챌린지를 해본 적이 있어 오늘 html과 css로 pofile 페이지를 만드는 건 금방하겠다고 생각했다. 하하...한 페이지만 구성하는 데 3시간 걸렸다. BEM이라고 체계적으로 요소마다 class 명을 붙여주는 게 아직도 힘들고(네이밍 센스가 부족하다) 어떤 식으로 영역을 나누는 게 편한지 감이 안 잡혀서다. 매일 css 만진 것도 아닌데 엄청난 능력을 발휘한다는 것 자체가 말이 안 된다! 하다보면 는다. 걱정말고 계속 키보드를 붙잡자ㅎㅎ

• office hour

  ​ 와...처음으로 수강생들 전원이 있는 자리에서 마이크를 켜봤다. 떨려 죽는 줄 알았다.ㅜㅜ 1대1로 했을 땐 편했는데.. 즉석에서 내가 만든 페이지를 설명하기가 힘들었다. 매번 office hour시간에 지목받은 사람이 떨리지 않고 대답을 하는 건 정말 어려운 거였구나 싶다. 그래도 내가 만든 걸 보여주고 싶었다구!! ㅋㅋㅋㅋ

• css selector

  ​ 항상 first-child, last-child, nth-child를 사용해 이름 붙이는 수고를 덜었다. 그런데 같은 태그 중 몇 번째를 선택하고 싶은데 다른 태그를 불러오는 경우가 있어 난감했다. 알고보니 쓰임새를 착각했다. 내가 원하는 기능은 first-of-type, last-of-type, nth-of-type 이었다. 유용하게 쓰일 것이니 이정도는 외워둬야지.

- 코드스테이츠 14일차 (5월 21일)

• 디자인 툴 Figma, 코딩 툴 Live share 사용후기

  ​ 오늘 새로운 툴 두 개를 썼다. 목업 작업을 위해 Figma를 사용했고 html과 css 작업은 vscode의 확장프로그램 중 하나인 live share를 활용했다. 둘 다 작업을 실시간으로 공유할 수 있다는 장점이 있다. live share의 불편한 점은 초대 받은 사람의 경우 html을 실시간으로 볼 수 없다는 것. 중간중간 직접 에러를 확인하고 싶을 때가 있는데 페어분만 html 화면을 확인할 수 있어 불편하다. 앞으로는 html 확인할 경우 페어분의 git repository에서 pull 하여 확인하자. live share와 git 사용을 동시에 하면 협업이 훨씬 효율적으로 진행하리라!

• office hour

  ​ 이번 office hour시간은 좋았다. 코치님이 설명도 잘하시고 준비도 철저히 해왔다. 어떤 식으로 진행하면서 개념을 설명할 지 미리 짜왔다. 코드 사이사이 주석처리한 것을 보면 꼼꼼하게 해야 할 일들을 적어놓았다. 그리고 실제 웹사이트를 활용해서 배운 내용이 어떤 식으로 활용되는지도 보여줘서 좋았다. 그래! 그냥 개념만 배우는 것보다 어떤 식으로 나중에 써 먹을 수 있을 지 보여주는 게 이해가 잘 된다!

  ​ 목업은 최종 완성본이 이러해야 한다는 걸 보여주는 가이드라인이다. 일단 비주얼로 어떤 식으로 화면에 보여질 지만 고려했는데 추가적으로 어떤 컴포넌트가 고유한 id가 필요한지도 생각하고 정해놓아야 했었다. 앞으로는 목업은 곧 완성본이라 생각하고 작성해야겠다.

• pair programming | twittler

  ​ 이전에 내 방식이 옳다고 고집부렸던 내 모습이 불쑥불쑥 티어나온다. 으으.. 상대방의 스타일을 존중해야하는데 어쩐지 아닌 것 같다고 판단되는 걸 어떻게 얘기해야할까?
  ​ 특히 header가 주로 타이틀 혹은 맨 위에 로고를 표시할 때 주로 쓰이는데 프로필을 header로 써서 당황했다. 그리고 리스트로 자주 쓰는 ul 대신 dl을 언급한 것도 음... 새로운 시도는 좋지만 좀 더 잘 쓰이고 이미 리스트로 쓰라고 만든 태그를 쓰는 게 좋지 않냐고 말했다. 흠... 찜찜하다. 내가 강요해서 끄덕인 것 같다. 아아아악. 어찌하면 좋을꼬...

  ​ 곰곰히 생각해봤는데 일단 이렇게 해주세요하고 페어분이 말하면 고대로 쓴다. 내면에 반발심이 떠올라도 무조건적인 수용을 하자고. 마치 상담사처럼. 그리고 차분히 내 의견을 전달한다. 강요가 아니라 그저 단순한 의문? 질문? 가령 문제의 header 태그를 사용하는 방식이 사람들이 일반적으로 생각하는 방향과 다르다면, header는 주로 홈페이지 제목이나 맨 위에 어떤 것을 가리키는 데 혼란을 끼치지 않을까요? 아니면 만약 cover 전에 로고와 메뉴 바가 있다면 어떤 이름으로 작명하실 생각이세요?하고 간접적으로 얘기한다. 만약 설명이 납득가능하다면 긍정의 고개짓(끄덕임)을 보인다. 중요한건 내 감정이 앞서가지 않도록 하는 것이다. 차분하게 의견을 전달한다. 목소리의 고저가 같아야 한다.

- 코드스테이츠 15일차 (5월 22일)

• frontend workflow

  ​ 이번 frontendworkflow2 강좌가 매우 유익했다. 살짝 감으로 했던 코딩방식을 명료하게 절차를 나누어 표현해주셨다. 그렇구나! 이런 식의 사고과정으로 구현해야할 기능들을 구분한다는 것, 데이터객체(JSON)와 html 사이의 징검다리를 이제껏 사용했던 js를 이용해 함수로 만든다는 것. 간단해보이지만 실제로 내가 하려고 하면 퍼뜩 떠올리지 못한다. 앞으로 귀찮더라도 저런 과정을 거쳐서 작업을 해야지. 세분화하고 도식화하고 그 이후에 코드를 짜기! 틈틈히 하자.

• 아아 중간에 페어분께 말실수를 했다. 이후 나도, 페어분도 날이 조금 섰다. 진행하면서 다시 줄어들었다만 이대로 어물쩍 넘어가면 안된다고 생각했다. 이제껏 나는 내 잘못을 인정하지 못했다. 지금은 다르다. 나는 내 잘못을 솔직하게 인정하고 용서를 구할 줄 아는 사람이다. 마음을 가다듬고 하고 싶었던 말을 찬찬히 했다. 중간에 울음을 터뜨릴까 걱정했지만 다행히 눈시울만 살짝 붉어졌다. 페어분은 오히려 나를 토닥여줬다. 아아 마음이 참 넓은 사람이다. 말할 때 항상 긍정적으로 답하자! 일단은 입이 근질근질해도 엄청 잘못된 방향으로 가는 건 아니라면 노터치! 개선해야 할 것 같으면 우회해서! 예시를 들어서 묻자!

• 여전히 풀리지 않는 미스테리

  ​ local변수로 계속 document.querySelector를 받아 쓰면 성능이 떨어질까? 아니면 global변수로 쓰는 게 좋을까? twittler의 경우 한 페이지만 구현하기 때문에 global로 선언해도 무방하다고 봄. 하지만 만약 여러 페이지인 경우엔?

• template 태그를 알기 전과 후로 나눠진다

  ​ 앞으로 template 태그를 많이 써야겠다. 라고 생각했지만 vanillaJS인 경우에는 그렇고 React의 경우 컴포넌트 개념이 template와 유사하니 이미 쓰고 있었던 것..하하 하지만 vanilla로만 했을 때 항상 createElement를 썼는데 template가 훨씬 편하다. 그리고 좀 더 html과 js의 역할 분담을 철저히 할 수 있어서 좋고!