[ TWIL 2주차 ]

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

• 여러 가지 배열 메소드를 배우고 문제를 풀 때 적용해봤다.

  ​ 이전에 웹페이지를 만들 때 주로 Array.map, Array.forEach, Array.filter, Array.pop, Array.push을 주로 사용했다. 가령, 투두리스트를 구현한다고 하면 아래와 같이 활용할 수 있다.

속성으로 고유번호와 텍스트를 지닌 투두아이템 객체와 투두리스트 배열이 있을 때,

Array.push : 투두리스트에 투두 아이템 추가

Array.pop : 투두리스트에 있는 전체 투두 아이템 삭제할 때, for문이나 Array.forEach문을 써서 제거 .

Array.forEach: 서버나 localStorage에 저장해뒀던 투두리스트를 불러와 html 태그를 생성하여 브라우저 상에 띄워줄 때 사용.

Array.filter : 투두리스트 위치가 중간 어디에 위치한 투두아이템은 끝만 삭제하는 pop이나 맨 앞만 삭제하는 shift로는 불가능하기 때문에 삭제하려는 투두의 고유 번호와 일치하지 않은 새 배열을 생성하여 투두아이템 삭제 상태를 브라우저에 반영

Array.map : 투두아이템들의 표시방법(테마)를 변경하기위해 기존> 에 감싼 테그를 변경할 때 사용

이번 기회로 다양한 배열메소드를 한 번씩 훝어볼 수 있었다. 그동안 직접 구현했던 번거로움을 해소할 배열메소드가 있다는 걸 발견했다. 모든 배열요소가 한 타입으로만 이뤄졌는지 Array.every를 사용해 확인한다는 지 말이다.

• office hour 시간

  강의도 다 듣지 못한 채 이 시간을 마주하니 참 껄끄러웠다. 마무리를 제대로 못한 느낌이 들었다. 아직 이해가 덜 된 reduce를 질문할까 노심초사했다(문제 풀면서 이제는 이해되었다!).

  아뿔사. 함수형 메소드들을 가볍게 쓱 넘겼는데 그걸 질문할 줄이야. 수많은 메소드를 다 암기할 수 없다고 mdn문서 보면 되지 그렇게 가볍게 넘겼는데 허허.다행히 내가 걸리진 않았다만 질문에 대답을 척척하는 수강생을 보니 분발해야겠다고 생각이 든다! 좋은 자극이야

  어느 수강생분이 substring과 slice의 차이를 물었다. 코치님께서는 같은 기능이지만 String 타입은 substring을 사용할 것을 권장했다.

  " 이해하기 쉬운 코드 작성을 위해 상황에 맞는 메소드 쓰길 권장한다. "

• 함수형프로그래밍에 대해서 그리 깊게 생각하지 않았는데 코스과정에서 언급한 덕분에 구글링으로 찾아보게 됐다.

  큰 특징은 인자로 받은 값을 바탕으로 연산을 한다는 것과 원본에 수정을 가하지 않는다는 것이다. 이 특징 덕분에 에러잡기가 용이해진다. 인자가 잘못 되었거나 함수 내 로직이 문제가 있거나 둘 중 하나로 좁힐 수 있기 때문에!

• 사실 c언어계열과 java를 먼저 접했을 땐 무조건 객체지향프로그래밍(OOP)이 짱이라고 뭣도 모르면서 함수형 프로그래밍을 무시했다.(와우.. 초짜가 감히 이런 생각을 했나 싶겠지만 당시엔 그랬다.) 지금은 함수형 프로그래밍에 홀릭되었다! 객체를 쓰는 것보다 더 깔끔한 코드를 작성할 수 있고 가독성도 좋다. 앞으로도 계속 사랑하게 될 것이다 ㅎㅎ

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

• 알고리즘 작성법에 맞춰 프로그래밍 문제 풀기

  ​ 알고리즘 작성법을 배우기 전에 페어프로그래밍을 하면서 나름대로 문제를 분석하고 코드를 짰다. 문제에서 최종적으로 요구하는 값(주로 반환값)과 예외처리 같은 조건들을 간략하게 정리해봤고 어떤 자바스크립트 개념들이 이 문제를 풀 때 필요할 지 적어봤다.

  ​ 알고리즘 작성법을 보고 난 후 든 생각은 이거 노랑책이랑 비슷한데? 였다. 노랑책이라 함은 프로그래밍을 제대로 하고 싶어 네이버 지식인을 뒤져보다가 알게 된 <이렇게 하면 나도 프로그래밍 잘 할 수 있다> (줄여서 나프잘) 이다. 한 분이 엄청 정성스럽게 남긴 강력 추천 글을 읽고 홀려서 구매했다. 프로그래밍을 배운다고 하면 주로 곧장 언어부터 배우는데 이런 과정은 마치 영어를 공부한답시고 문법부터 배우는 식이란다. 그래서 알고리즘을 먼저 적어보고 이후에 c언어나 java와 같은 언어를 적용해본다. 알고리즘은 단순하게 세 가지로 표현된다.

알고리즘은 특정 데이터들을 순서대로(절차) 혹은 적절한 분기점을 통과하거나(조건) 해당 절차를 몇 번 되풀이(반복)할 건지 결정하여 최종적인 결과값을 도출하는 과정을 짜는 것이다.

절차, 조건(분기), 반복을 적절히 섞어서 데이터를 처리하는 것이 바로 알고리즘! 문제는 이렇게까지 세세하게 적어야해? 할 정도로 작성해서 귀찮음이 느껴졌다. 조금 따라했다가 손을 놓았다.

​ 다시 이 귀찮은 과정을 하기로 다짐한다. 귀찮더라도 미리 머릿속에서 구상하고 코드를 짜니 코드를 바로 치는 것보다 훨씬 논리적으로 짤 수 있게 된다. 코드 짜는 데 열중해서 중간에 문제가 어떤 걸 원하는 지를 깜빡하여 엉뚱한 값을 반환할 때가 있는데 그런 실수도 금방 찾을 수 있다. 맞아! 내가 이런 식으로 코드를 짤려고 했지? 하면서.

• 재귀함수 도대체 언제 쓸까?

  ​ 재귀함수를 배울 때 주로 예시를 드는 게 펙토리얼이다. 하지만 어떨 때 유용한지 잘 몰라서 배워도 써먹어 본 적이 없다. 어디서 들은 바로는 재귀함수가 수천번 호출된다면 stack overflow가 발생하기 때문에 권장하지 않는다고 했다. 그럼 안 써도 상관없겠네? 싶지만 잘 사용한다면 복잡한 알고리즘도 단순하게 표현할 수 있다는 문구 때문에 잘 사용해보고 싶다. for문 등으로 구현했던 것들을 재귀함수를 써서 구해보는 연습을 하면서 나중에 다른 곳에 응용할 때까지 익숙해져야지.

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

• 슬랙 서버가 터져버렸다.

  ​ 처음에 나만 슬랙이 고장 난 줄 알고 정규 수업 시간이 시작 되기 전 급하게 컴퓨터 껐다 켰다하다 페어분께 메일로 연락을 취했다. 알고보니 다들 같은 문제를 겪었다. 슬랙에 오류가 났으니 메일로 상대 페어에게 연락을 취해달라는 공지도 뒤늦게 봤다. 점심을 먹고 나니 문제가 해결되었다!

• 수학적 사고

  ​ 크읍... 제일 약한 수학문제가 나왔다. 페어분께서는 수학적 사고가 빠른 듯 했다. 내가 주로 방향을 잡는 역할을 하다 페어분이 이제 나를 이해시키려 애쓰는 모습을 보니 흐뭇했다. 처음엔 설명이 이해가 가지 않았지만 구글링을 활용해 해당 공식 개념이 잘 드러나는 그림을 찾아주기도 하고 화이트보드를 활용하여 설명해주기도 했다. 드디어 이해가 가지 않았던 백분율, 퍼센트가 머릿속에 들어왔다.

  ​ 악마의 문제...바빌로니아법...도저히 생각해 낼 수 없는 해결방법이다. 솔루션을 보고 이해는 했다만 또 이런 문제들이 나오면 어떻게 풀어야할 지 막막했다. 게임회사에서도 지적당했던 부분인데.. 수학적으로 서술한 기획문서를 어떻게 코드로 짜야할지 몰라서 헤맸다. 일단 금융권으로 취직은 포기했다. 하하. 그래도 수학이 싫었던 건 아닌데 어려워서 그렇지 수학으로 세상을 바라보는 게 흥미로웠다. 예전에 인기있었던 <비정상회담> 방송에서 타일러씨가 20대의 타일러씨에게 하고 싶은 말이 무엇인지 얘기할 때 올림피아드 문제를 술술 푸는 사람과 비교해서 자신이 수학을 못한다고 완전히 포기해버렸던 게 후회된다고 했다. 그때 수학을 놓치 않고 계속 공부했더라면 알았을 재미, 흥미를 발견할 수 있다고. 포기하지말라고 했다. 그러니 잘 이해 안 돼도 계속 도저언!!

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

• CLI (Command Line Interface)

  ​ 터미널에서 명령어로 프로그램을 설치하거나 구동하는 방식이다. 아직 프로그래밍이 낯설 당시엔 터미널은 무서운 존재였다. 어느 글에서 터미널에 프로그램 설치 명령어를 쳤을 때 이상한 글들이 마구마구 쏟아져 나와도 무서워하지 말라고 달래는 글이 있었다 ㅋㅋㅋ 정말 공감되는 말이다. 이제는 하나도 무섭지 않고 GUI보다 CLI로 컨트롤 하는 게 재미들렸다.

  ​ 터미널에서 텍스트를 입력할 수 있게 도와주는 vim도 들어는 봤지만 딱히 쓸일이 없어 사용을 안 했는데 나중에 서버를 다룰 때 필요하다고 해서 사용법을 익혀봤다. 수많은 명령어를 외우기 싫어 구글링을 통해 vim 설정을 변경했다. 이제 마우스랑 방향키로 텍스트 줄을 쉽게 이동할 수 있다. 게다가 코드를 작성하면 자동으로 코드를 인식해서 맨 앞에 숫자를 매겨주고 가로표시를 하이라이트 해준다. 신기하다!

• office hour 시간

  ​ cli로 git 명령어 치기 싫어서 그동안 git desktop을 많이 썼다. 하지만 cli에 익숙하기 위해선 설치하지 말아야지ㅜㅜ 단순히 테스트용으로 코드작성할 때는 remote와 연결하지 않았다. 불필요하게 github에 기록하고 싶지 않아서. 그래서 remote와 연결되지 않은 상태에서 local(내 컴퓨터)에서만 변경사항을 추적하도록 했다. local의 변경사항을 커밋후 항상 push 버튼을 클릭했다. 당연히 커밋 후 push를 해야 완벽하게 local storage에 저장되는 줄 알았다. office hour 시간에 당당히 push를 하면 local에 저장된다고 했다가 커밋만 해도 된다고 답변을 들었다 ㅋㅋㅋㅋ;; 그렇구만...커밋만 해도 상관없었군!

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

• 처음으로 새롭게 접한 개념 : scope, closure

  ​ scope 개념은 처음 들었지만 해당 내용은 익숙했다. 하지만 이전에 var를 없는 키워드라 치부했기 때문에 중괄호({})를 기준으로 local과 global 이 나눠진다고만 생각했다. 이번에 제대로 local과 global의 영역 즉 scope에 대해서 깊게 배웠다.

  scope는 한마디로 변수를 접근 혹은 참조할 수 있는 범위이자 생존기간을 표시한다. global는 모든 scope에서 접근/참조가 가능하고 선언 이후 프로그램이 종료되기 전까지 변수가 존재한다. 반면 local은 자기자신의 scope와 그 하위 scope에서만 접근 /참조가 가능하고 해당 scope를 벗어나면 메모리에서 해제되어 프로그램 상에서 존재하지 않은 값으로 인식된다.

  ​ closure는 다른 언어에서 쓰이는 private 문법을 구현하고 global변수의 장점과 local변수의 장점을 살린 기법이라고 생각한다.

  ​ 앞서 global변수는 어디서나 해당 변수 값을 취할 수 있다. 프로그램이 종료할 때까지 쭉 존재한다고 했다. 하지만 누구나 쉽게 접근이 가능해 의도치 않게 값이 변경되고 오염될 수 있다. 가령 팀작업을 했을 때 글로벌 변수는 1씩 증가하길 원했으나 다른 누군가가 2씩 증가시켜버려 예상치 못한 결과를 도출할 수 있다.

  ​ 반면 local변수는 자기 자신의 scope나 하위 scope만 접근할 수 있기 때문에 global변수 보다는 오염이 생길 가능성이 적어진다. 그리고 좁은 범위에 있어 변수값 변경이 일어나도 눈에 잘 들어난다. 에러를 쉽게 찾을 수 있다. 수천 줄의 코드 속에 단 몇 줄 안에 있는 local변수의 값 변화와 global 변수의 값 변화 중 어떤 것이 더 잘 보이겠는가?(local변수가 당연히 잘 보인다.)

  ​ 하지만 로컬변수는 수명이 짧다. 자신이 선언된 스코프의 범위를 벗어나면 프로그램은 로컬변수에 할당된 메모리를 해제시켜버린다. 즉 더이상 없는 값으로 나온다. 그리고 여전히 중간에 값을 임의로 변경할 가능성이 존재한다. 함부로 값이 변경이 안 되면서 오랫동안 값을 사용하고 싶어서 생각해 낸게 closure다.

  ​ 원래라면 local scope 내에 선언한 local변수는 scope가 끝나면 사라져야지만 해당 scope의 local변수를 참조하는 하위 scope를 반환함으로써 지속적으로 해당 scope의 local변수에 접근할 수 있다. 이것이 가능한 까닭은 scop는 function이 호출되는 시점이 아니라 선언될 때 생성되기 때문이다. 선언 당시의 자신의 스코프의 상위 스코프가 무엇인지 기억해뒀다가 나중에 호출될 때 그 때 기억을 바탕으로 변수값을 가져온다. (마치 내 몸은 현재 그곳에 없지만 난 여전히 내가 자란 고향을 기억해!!!와 같다...ㅎ)

클로저는 이너함수가 선언된, 생성된 시점의 scope를 기억한다. 외부로 꺼낸(반환시킨) 이너함수를 실행시키면 선언된 시점의 scope를 기준으로 작동한다. 그래서 자신의 상위 scope의 local변수값을 취할 수 있다.

• 객체지향프로그래밍(OOP)

  ​ 대망의 OOP!! class 키워드로만 객체를 생성했던 다른 언어들을 배운 뒤 javascript를 볼 때 난감했다. function으로 객체를 생성한다고?? {} 만 있으면 객체로 인식된다고?? 그래서 ES6 문법을 찬양했다. 확실히 ES6가 더 명확하고 깔끔하다. class 중괄호 안에 변수들(속성)과 메소드들이 함께 있기 때문이다. function을 아직도 사용하는 걸 보면 내가 모르는 유용함이 있는 듯 한데 좀 더 알아봐야겠다.

  ​ 객체 생성시 변수값을 초기화 할 때 this의 의미를 드디어 알게 되었다. this는 바로 인스턴스였던 것이다! 좀 더 구체적으로 말하면 new 키워드로 생성한 빈 객체를 가리키고 빈 객체에 key와 value값을 지정(속성 추가)하는 과정이었다. bind 메소드가 왜 this를 인자로 넣어줬던 건지도 덕분에 이해가 되었다. 수많은 인스턴스를 구분할 고유한 값을 가진 this.