오성국 블로그 이것저것 끄적끄적

코드 스테이츠 6주차

17 Jan 2021

코드 스테이츠를 통해 배운 것을 정리하는 post

무엇이든 보고 듣기는 쉽지만 자기 것으로 만드는 것엔 노력이 필요하다.


  • 학습할 내용

(화요일) git 명령어 branch 에 대해서 정리하기

git 연습사이트 마지막까지 다 풀기 (원격작업 merge 까지 진행)

(화요일) 자바스크립트 info 페이지 정리 (1개) (일요일) 두개 더 하기

(목요일) git rebase 정리하기


월요일

이머시브 OT

확실히 pre 코스보다 다루는 주제의 난이도가 훨씬 높아진 것 같다. 점점 전공자로 누릴 수 있는 메리트가 없어지는 느낌이 들기 시작한다. 조금 더 열심히 할 필요가 있는 것 같다.


Git Flow 연습

동기분이 이런 사이트 알려주셔서 git 명령어를 연습하는데 많은 도움이 됬다.

나중에는 GUI 를 지원하는 sour tree 같은걸 사용하겠지만 터미널 명령어 연습하는 것도 지금으로선 좋은것 같다.

노션 에 git 명령어와 개념에 대해서 정리중이다.


이진탐색 알고리즘 구현

3일 동안 헤매는 문제 를 풀다가 도저히 이대로가다간 시간만 버릴것 같아서 여기서 효율성 알고리즘으로 사용하는 이진 탐색 알고리즘부터 구현하기로 했다.

이진 탐색 알고리즘의 시간 복잡도는 순차탐색이 N 제곱인 반면 로그2N이다.

0 < target < 2000000 중 숫자 346323를 21번의 시도만에 찾는 굉장히 효율적인 알고리즘이다. 이를 토대로 여러가지 알고리즘에 필요한 역량들을 키워나가야 겠다.


화요일

화살표 함수

키워드 this

call, apply, bind 메서드

3개를 모조리 정리하는데 꽤 오랜 시간이 걸렸다 ㅜ

전부 연관이 있는 주제라 하나의 노션 에다가 정리를 해뒀다

This 는 자신이 참조할 객체를 찾아다니는 녀석

call 과 apply 는 참조할 객체를 명시해주고 인자도 넘겨준다

bind는 어떤녀석을 참조해야하는지 알려주고 묶은걸 함수로 반환해준다

화살표 함수는 this 를 결정하지 않는데 this를 잃으면 가장 가까운 객체를 찾아서 지정해준다


Prettier, ESLint

코드 컨벤션을 관리해주는 익스텐션인데 실시간으로 검사해주고 저장시에 자동으로 적용시켜주는 아주 강력한 기능들이 담겨져 있다.


Git Branch

아직은 Master 브랜치 하나만을 이용해서 진행을 해서 다양한 브랜치들을 다루는법에 대한 필요성을 느끼지 못하고 있다. 나중에 프로젝트를 시작하기 전에 브랜치 사용 전략들을 고려해봐야겠다


Git Log

깃 로그를 보는 명령어 인데 정말 다양한 옵션들이 있어서 내가 원하는 커밋 이력들, 다양한 필터링과 포맷으로 볼 수 있었다.


TIL 작성법 변경… ㅎㅎ 내맘대로 해보기

요일마다 내일작업할 내용을 적는게 귀찮아서 맨 위에다가 전부 적고 해결하면 (요일이름)작업한내용 이런식으로 작성을 해보려고 한다.


수요일

HA 리팩토링

ES6 의 주요 문법 5가지

  • 구조 분해 할당 : 파라미터 관리나 특정 인덱스의 값을 받아올 때 편하다
  • 전개 연산자 : console.log(…[‘말’, ‘해’, ‘뭐’, ‘해’]);
  • 화살표 함수 : this 만 안쓰면 착한 친구
  • 템플릿 레터럴 : str + ‘ ‘ + str 이런거 안해도 된다!!
  • for … of loop : 더 이상 귀찮은 let i = 0 그만

문제마다 적용할 수 있는 기술들을 고려해보고 실제로 써먹어 봤다. 프로그램 언어가 이렇게 발전되어 가는구나 느꼈다.


Linting

지금까지 코드 컨벤션에 대해서 그리 크게 필요성과 중요성을 못 느끼고 있었는데 이번 스프린트를 진행하면서 많이 느꼈던것 같다.

각자의 코드 스타일이 있고 습관들이 다양하다보니 프로젝트를 진행할 때 충돌이 불가피하다고 느껴졌다. 코드 작성에 대한 팀의 규칙을 만들고 쓰는게 가장 좋겠지만 습관이라는게 그리 쉽게 바뀌지 않는다.

Linter 를 이용해서 규칙을 공유하고 적용시켜 하나의 통일된 코드를 작성할 수 있는 기술이 있다는게 다행이다.

ESLint 와 Prettier 를 사용하는데 option 들이 정말 많고 프로그램의 문법이 많은만큼 이에 대한 작성 규칙도 정비례 하다보니 그렇게 되지 않았나 싶다.

일단 기본적으로 지원하는 default formater 를 이용해 보편적으로 사용하는 코드 컨벤션을 숙지 중이다.


notice 에 올려주신 this 관련 영상

영상을 보고 조금 더 입체적으로 this 를 볼 수 있게 되었다

function test() {
  console.log(this);
}
// test() === window.test()
// 위의 두 경우가 같기 때문에
// 결국 함수 호출도 method 호출의 한 부분이다

let obj = {
  fn: function (a, b) {
    return this;
  },
};

let obj2 = {
  method: obj.fn,
};

console.log(obj.fn() === obj); // true
console.log(obj2.method() === obj); // true

// 첫번째 경우는 쉽다
// 두번째 경우가 약간 헷갈릴 수도 있는데
// 단순하게 함수가 실행됬을 때 . 의 왼쪽에 있는 객체를 this 로 지정
// 함수를 치환하고 값을 계산하고 그런거 필요없다.

class Rectangle {
  constructor(width, height) {
    this.width = width;
    this.height = height;
  }

  getArea() {
    return this.width * this.height;
  }

  printArea() {
    console.log("사각형의 넓이는 " + this.getArea() + " 입니다");
  }

  printSync() {
    // 즉시 사각형의 넓이를 콘솔에 표시합니다
    this.printArea();
  }

  printAsync() {
    // 1초 후 사각형의 넓이를 콘솔에 표시합니다
    setTimeout(this.printArea, 2000);
    // 콜백함수가 실행되면 this 의 값이 전역 객체로 설정된다.
    // 해결방법 1 : 메서드 호출시 this 는 인스턴스를 가리키므로 인스턴스와 바인딩 시켜주면 해결 가능
    setTimeout(this.printArea.bind(this), 2000);
    // 해결방법 2 : 함수실행 시 전역으로 설정된 this 를 담어뒀던 self 값으로 초기화 시켜줘서 해결 가능
    let self = this;
    setTimeout(function () {
      self.printArea();
    }, 2000);
    // 해결방법 3 : this 가 상위 context의 this 를 가리키기 때문에 상위 객체인 Rectangle의 인스턴스를 가리킨다.
    setTimeout(() => {
      this.printArea();
    }, 2000);
  }
}

let box = new Rectangle(20, 40);


목요일

OOP 정리 ( OOP 개념, 프로토타입, 상속, Object.create(), ES6 class/super )

노션 페이지

위에 적혀있는 주제를 하나의 노션으로 끝장을 봐버렸다. 참고한 게시물도 5부작으로 긴 호흡을 가지고 썼는데, 쓰다보니 한 페이지에 종합선물세트처럼 전부 들어갔다. 장정 12시간의 결과물이 눈앞에 보이니 뿌듯하다 ^^

정리를 하면서 평소 계속 헷갈렸던 ‘프로토타입’이 어느정도 머릿속에 정리가 되어 개념이 잡혔다.

객체 지향 프로그래밍이란 어느 하나의 기술에 국한된 것이 아닌, 개발자가 프로그램을 만들어 나갈 때 스며들어가는 개념이다. 객체 지향에 대해 입체적으로 알수록 코드속에서 객체 지향적 개념들이 녹아들어가는 것이다.


객체, 클래스, 인스턴스

객체는 소프트웨어의 세계에서 구현할 ‘어떤 것’, ‘무언가’ 클래스는 공통된 속성들을 묶은 추상적인 집합의 개념, 상속이 거듭 될수록 추상화는 줄어들고 구체화는 증가된다. (예를 들면 ‘사과’라는 단어를 들었을 때 머릿속에 떠오르는 포괄적이고 보통의 존재로서의 사과 <- 이 사과를 클래스라고 할 수 있겠다.) 클래스의 인스턴스 생성은 추상 => 실체 로 바꿔주는 과정이라고도 할 수 있다. 인스턴스 클래스를 통해 ‘구현된 것’


merge vs rebase

탕수육의 부먹 찍먹 만큼이나마 뜨거운 토론 주제인지 알지 못했다. 그러나 결국엔 상황에 맞게 사용하는게 중요하다는 결론이 난다!!

각각의 장단점

**merge 장점**

  • 이해하기 쉬움
  • 원래 브랜치의 컨텍스트를 유지함.
  • Fast-Forward Merge 를 하지 않는다면 브랜치 별로 커밋을 분리해 유지. 특히 이런 분리는 기능 브랜치에 유용.
  • 원래 브랜치의 커밋들은 변경되지 않고 계속 유지되어 다른 개발자들의 작업과 공유되는 것에 대해 신경쓸 필요가 없음.

**merge 단점 **

  • 단순히 모든 사람들이 같은 브랜치에서 작업하기 때문에 머지해야할 때는 merge 가 커밋 히스토리상으로 전혀 유용하지 않고 어지럽기만 하다.

**Rebase 장점 **

  • 단순한 히스토리
  • 여러 개발자들이 같은 브랜치를 공유할 때 커밋을 합치는 가장 직관적이고 깔끔한 방법.

**Rebase 단점 **

  • 충돌상황에서 다소 복잡. 커밋 순서대로 Rebase 를 하는데, 각 커밋마다 충돌해소를 순서대로 해주어야 한다. SourceTree 가 가이드하기는 하지만, 역시 복잡한 것은 사실이다.
  • 해당 커밋들을 다른 곳에 푸시한 적이 있다면 히스토리를 다시쓰는 것에 부작용이 발생한다. Mercurial 에서는 간단히 푸시를 할 수 없다. Git 에서는 Push 할 수 있으나 당신 혼자 쓰는 리모트 브랜치에만 가능하다. 만약 다른 사람이 그 브랜치를 체크아웃 받은 후 당신이 리베이스 한다면 꽤 혼란스럽게 될 것이다.

결론

  1. 여러 개발자들이 같은 브랜치를 공유할 때는 Pull & Rebase 가 히스토리를 깔끔하게 유지하는데 좋음.
  2. 완료된 기능 브랜치를 다시 합칠 때는 머지를 사용.
  3. 기능 브랜치에 부모 브랜치의 변경 내용을 반영하고 싶을 때는
    1. 아래 상황에서는 리베이스가 낫다.
      • 이 브랜치를 다른 곳에 푸시한 적 없는 경우.
      • (Mercurial 이 아닌) Git을 사용하고 다른 사람이 이 기능브랜치를 체크아웃할 일이 없을 것이라 확신하는 경우.
    2. 이 외의 상황에는 머지가 낫다.


금요일

BeesBeesBees 스프린트

전날 정리해둔 OOP 총 정리가 굉장히 도움이 되었다. 사실상 이번 과제는 어제 완성이 되었다고 할 정도로 프로토타입의 개념만 잡혀있으면 어려운 문제는 아니였다. 다만 그 개념을 잡기까지 하루종일이라는 시간이 필요했을 뿐… ㅠ

ES6 부터 도입된 class 친구가 그렇게 편할 수가 없다. Prototype, __proto__, function prototype object 의 지옥에서 벗어 날 수 있었다. 실제로 코딩을 하면서 느꼈던 편안함은 처음 전개 연산자를 만났을 때의 느낌과 비슷했다.


Subclass Dance Party

페어분의 엄청난 역량으로 꿀벌들을 무사히 설계하고 기획과 과제들을 나누어서 진행하기 시작했다.

주말

.prettierignore .eslintignore .gitignore

각각의 시스템을 적용시키고 싶지 않은 친구들을 넣는 파일들이다.

prettierignore => 저장을 하면 파일이 계속 변경되어 그렇게 하지 않아도 되는 or 해선 안되는 파일들을 변경 시켜서 꺼야하는 경우

eslintignore => 아직 설정법이 미숙해서 다루는데 서툴다. ES6 문법이나, 라이브러리의 문법들을 기존의 문법에 맞지 않다고 경고를 계속 날리는 경우가 많았다. 일단 무시하는 쪽으로 처리중인데, 한번 자세히 알아봐야겠다.

gitignore => 깃허브에 올라갈 필요없는, 올라가선 안되는 것들을 담는다. 얼마전 AI 쳇봇 ‘이루다’ 프로젝트에서 깃허브에 학습한 카톡 내용들이 public 으로 나와 있어 논란이 된적이 있었다. Key 값 token 값 유저 데이터등… 노출되선 안되는 파일들은 전부 무시 시켜줘야한다.


Subclass Dance Party

페어분과 거의 주말 내내 매달려서 만들었다. 기획한 걸 노션에 정리하고 과제들을 나누어 진행했다. 뭔가 프로젝트를 진행하는 듯한 느낌이 들었고 서로간의 커뮤니케이션도 매우 중요했다. 나중에 진짜 프로젝트를 들어간다면 이런 느낌일까? 라는 생각과 효율적인 프로젝트 진행을 위해서 서로간의 규칙이 꼭 필요하겠다는 생각이 들었다.

필요한 규칙

  • 커밋 메세지 적는 법
  • 브랜치 이름 만드는 법 & 브랜치 활용 전략
  • Git 의 전체적은 Flow 에 관하여
  • 변수 이름 및 함수 이름 작성 법
  • 프로그램 설계 방법 & 구조 짜는 법
  • 이슈가 발생했을 때, 대처방법

사전에 명확하게 협의과정을 거쳐서 문서화 하는 것도 좋은 방법일 것 같다.

댄스파티에 관한 내용은 스포의 위험이 있기 때문에 (아무도 안볼텐데?) 크흠 … 월요일 TIL 에 적도록 하겠다.

Related Posts