TIL 34 day 한 달을 마무리하며

Winney·2020년 10월 18일

후기

목록 보기

5/5

Wecode에서의 한 달을 돌아보며

Wecode에 들어온지 한 달이 지났다. 그동안 HTML, CSS, JavaScript의 개념을 익히고 westagram(instagram cloning)을 하면서 각각을 한 번씩 써보는데 첫 2주를 보냈다.
그 후 react의 기초를 배우고 이전에 HTML, CSS, JavaScript를 이용해서 만든 Westagram을 react를 사용해 변경도 했다.
그 사이 사이에도 정말 많은 새로운 것들을 배웠다. web, slack, notion, git...
매일매일 새로운 걸 배우는 게 예상보다 힘든일이면서도 내가 즐거워 한다는 것도 알게되었다. 하루하루는 너무 긴데 일주일은 정말 쏜살같이 흘러갔다.
지난 한 달을 되돌아보며 나의 처음을 되돌아보고 내가 무엇을 배웠고 무엇을 느꼈으며 앞으로 무엇을 하고 싶은지 정리해보려고 한다.

왜 개발자가 되고 싶지?

나는 왜 수많은 직업중에 왜 개발자가 되고 싶을까?
많은 이유중에 꼽자면 끊임없는 배움이 매력적이라고 생각했다.

난 내가 일하는 직장, 내가 하는 일에 항상 애정을 가지고 일 했다고 자신있게 말 할 수 있다. 난 그게 내 장점이라고 생각한다. 하지만 배움없는 반복은 내 일에 대한 애정이 사그라들도록 했다.

반면에 개발자는 전혀 달라보았다. 변화가 가장 빠른 직종 중에 하나였고 끊임없이 배우면서 배운걸 바로바로 현실에 쓸 수 있다는 점이 정말 매력적으로 보였다.

내가 좋아하는 말이 있다. 배워서 남주는 거 없다.

분명히 나도 계속 배우는 것이 견딜 수 없이 힘든 순간이 올 것이다. 하지만 그 순간이 지나면 또 금방 즐거워할 순간이 올거라고 믿는다.

본격 후기😁

react와 첫 만남

말로만 듣던 react를 처음 배울 때 정말 앞이 막막했다. 사전 학습으로 1시간 30분짜리 유튜브 동영상을 6시간 가까이 봤을 때는 내가 내일 당장 할 수 있나? 싶었다.

걱정은 필요없었다
유튜브 영상을 보면서 그냥 따라 치기만 했고 하나도 이해하지 못 했었다.
그러나 정작 session을 통해 하나씩 배울 때마다 아예 낯선 느낌은 덜했다. 맨땅에 헤딩했는데 '어? 되네?'라는 생각이 신기하게 느껴졌다.

component도 분리하다 보니 대충 어떤지 알 수 있었고 왜 react가 UI를 위한 library인지도 알게되었다.
state와 props를 배우고 사용해 볼 때 state는 대충 이해했다고 생각했는데 나중에 반복되는 classname을 내가 배열 내 객체에 하나씩 복사 붙여넣기 했을 때는 아, 또 내가 이해 못한거였구나 싶었다😂😂
props는 여전히 잘 모르겠어서 항상 props 설명을 다시 보고 쓰고는 한다.

스스로의 학습 속도가 썩 만족스럽지는 않지만 포기 하지 않는이상 느리던 빠르던 실력은 늘것이라는 믿음이 있기에 새로운걸 배워서 바로 적용해보는 경험을 할 수 있어서 기뻤다.

처음으로 team과 함께

처음 팀이 발표되고 기쁘면서도 걱정이 되었던 것이 우리 팀원들이 모두 뛰어나다는 것이었다. 약간 기도 죽었다😢

난 과제 하나에 하루 이틀은 소모하고 해내면 기뻐했는데 팀 미팅을 하면 내 진도가 제일 꼴찌였다.😭 다른 팀원들은 과제는 일찌감치 다 한 상태고 다른 추가기능을 비롯해 정말 할 수 있는건 다 해낸 상태였는 것이다.

이해를 못해서 가장 질문을 많이 한 것도 나였다. 나는 민폐끼치기 싫었는데 계속 민폐를 끼치고 있다는 생각이 떠나지 않았다. 이건 순전히 내 마음의 문제라 이래서 팀과 하는게 힘든건가? 라는 생각을 많이 했다.

팀 프로젝트를 할 때 마음을 다스리는게 중요하겠구나라는 생각이 들었다.

아쉬운 점은 내가 지원해서 README를 썼는데 난 우리 팀원들이 정말 잘 한다고 생각해서 팀원 자랑을 README에 많이 적고 싶었는데 만족스럽게 못 적었다.
또 팀으로 진행하는 것에 대해서 구체적으로 우리가 뭘 했는지에 대해서 너무나 부족하게 적었다는 생각에 아쉬움이 남는다.

CRA를 이용한 사전세팅 작업은 잘 했지만 폴더 생성 등 세세한 사항을 놓친 부분이 많아서 수정을 많이 했다. 그로인해 몇몇 문제로 애먹었다.
다음번에는 더 신경써서 사전세팅을 해야겠다는 생각이 들었다.

뒤늦게 common.scss에 변수지정을 해서 수정하는 데도 시간이 꽤 걸렸기에 다음 프로젝트 진행 시에서 시간이 좀 걸리더라도 초기 세팅을 제대로 하고 가야겠다는 생각을 많이 했다.

기억하고 싶은 코드

classname의 동적사용

// JS
<button
  className={
  	this.state.idValue.includes("@") &&
  	this.state.pwValue.length >= 5
   	? "login_btn activated"
   	: "login_btn"
   	}
  type="button"
  onClick={this.goToMain}
>

// sass
.login_btn {
  width: 286px;
  height: 29px;
  margin: 8px 40px;
  padding: 5px 9px;
  border: none;
  border-radius: 4px;
  background-color: $button-color;
  color: $background-color;
  outline: none;
  opacity: 0.3;
  font-weight: 600;
  text-align: center;
  cursor: pointer;
  }

  .activated {
   opacity: 1;
  }

처음에 코드를 작성했을 때는 inline style 내에서 삼항연산자를 사용해 작성했었다.
하지만 inline style은 최대한 지양해야하므로 classname의 동적사용을 하도록 refactoring 내용에 들어가 있었다.
classname에 삼항연산자를 사용해서 true 일 때과 false 일 때의 classname을 다르게 설정해 sass에서 style 변경이 가능하도록 refactoring 하였다.

여기서 주의 할 점은 sass에서 설정 시 기존의 selector 내부에 nesting을 하지 말고 같은 line에 써주어야 한다.

계산된 속성명

  handleInput = (event) => {
    const { name, value } = event.target;
    this.setState({
      [name]: value,
    });
  };

처음 코드 작성 시에는 Id input과 Pw input 2개의 input창에서 각각의 value를 가져오는 함수를 따로 작성했다.
하지만 두 input창에서 같은 로직을 사용 하는 거라 하나의 함수로 합치는 것이 refactoring 내용에 있었다.
그 과정에서 계산된 속성명에 대해 알게 되었고 동영상을 보면서 refactoring 하였다. 그러면서 비구조화 할당도 사용 해보았다. input에 name이라는 attribute가 원래 있었는지 몰랐던걸 알게 되었다.

그리고 색도 각각 색을 지정하는 게 아니라 opacity를 이용해서 변별을 할 수 있게 많이 한다는 사실도 알게되었다.

조건이 2가지일 때 Boolean을 활용 할 것
이 부분은 마지막 session 때 들은 내용이다. 예를 들면 버튼을 클릭했을 때 버튼 색이 2가지로만 왔다 갔다 할 경우 Boolean type을 적극 활용하라는 내용이었다.

const isValid = this.state.idValue.includes('@') && this.state.pwValue.length >= 5;

this.setState({
	loginBtnOpacity: isValid,
	loginBtn: !isValid,

이 부분은 refactoring 하지 않았지만 기억했다가 반드시 사용하고 싶다.

이번에 내가 잘 한 것

기본을 기키려고 애쓴 것 : 습관들이기(training, convention)
나는 습관이 제일 무섭다고 생각한다. 문제는 이 습관이라는 것은 매우 사소한 것까지 포함하며 나중에 아무도 지적해 주는 사람이 없고 설사 알더라도 쉽게 바꾸기 힘들다는 것이다.

문득 내가 일 했을 때를 떠올렸는데 누군가의 행동이 정석이 아니지만 지적하기 애매한 것들이 많이 있었다. 지적을 하면 '이런 것가지 지적하나? 저 사람 이상한거 아니야?'라는 소리를 들을 것같고 지적을 안 하자니 좀 더 맞는 방법이 있는 상황이었다. 나를 비롯해 모두가 아무말 하지 않았다. 팀의 분위기를 위해서였다.

나는 convention과 같은 것이 그런 사소한 습관이라고 생각한다. 내가 wecode의 모든 convention을 철저하게 지켰다고 생각하지 않는다. 하지만 적어도 철저하게 지키기 위해 노력했다고는 자신있게 말할 수 있다. naming, PR, review 등에 시간을 들이는 지금이야 말로 내가 이것들에 대해 습관처럼 중요하게 여길 수 있을거라고 생각한다.

최대한 많은 사람과 이야기 하려고 한 것
wecode에 온 이유 중에 하나는 좋은 사람들, 좋은 개발자 동기들을 많이 만나고 싶어서였다.
기적처럼 우리 동기들은 단 한 사람도 빠짐없이 너무나 좋은 사람들이다. 난 정말 여기가 천국이다 싶다😭😭

한 사람 한 사람 이야기 할 때마다 내가 배울 수 있는 것들이 보인다. 아직 모든 사람과 이야기를 해본것은 아니지만 사람을 만나는데 적극적이지 않았던 내 모습을 생각하면 나름 장족의 발전이라고 생각한다.

이번에 내가 못 한 것

컨디션 조절
3주차에 react 처음 배울 때 진도를 따라 잡기위해 저녁 10시~12시 사이에 집에 가고는 했다. 그 주 내내 무리하고 있다는 느낌은 받았는데 토요일에 몸살기운이 있어서 하루 종일 자면서 쉬었다.
4주차 초반까지 좀 힘들었던 기억이 있다.
완전히 컨디션 조절에 실패했다고 생각하고 코로나인 지금 감기, 몸살에 걸렸으면 세상 민폐도 이런 민폐가 없었을 거라고 생각하니 앞으로 컨디션 조절에 더욱더 신경써야겠다는 생각도 했다.
장기적으로 운동을 해서 체력증강을 위해 노력해야겠다는 결심을 했다.
적절한 타이밍에 구글링 못 한 것
개발을 하는 것에 있어 구글링이 중요하다는 것은 안다. 하지만 어떤 타이밍에 해야할지 모르겠다.

예를 들어 replit을 풀 때 나는 최소값과 최대값 사이에서 랜덤한 수가 나오는 식을 구글링해서 찾아보라는 문제가 있었을 때 처음 구글링을 했다. 이전 문제를 풀면서 막히는 부분이 정말 많았는데 난 그런 문제들을 풀릴 때가지 잡고 있어서 시간이 엄청 걸렸다. 그래서 구글링을 하라는 문제에서 드디어 구글링을 했는데 나중에 다른 동기들에게 말하니 다른 동기들을 모르면 바로 구글링을 했다고 했다.

기능 구현을 하면서도 한 문제를 하루 이틀씩 붙잡고 있는 경우가 많았는데 구글링 할 생각을 못 했을 뿐만 아니라 어떤 때에 구글링을 해야할지 몰랐다.

codekata를 하면서도 문제가 안 풀리면 구글링 하는 동기가 있다고 하는데 난 한 번도 구글링을 안해봐서 이번에 처음으로 해보기도 했다.
스스로 너무 시간을 낭비하고 있다는 생각도 들고 현명하게 구글링을 이용하지 못 한 것같아서 여기에 대해서는 스스로의 기준을 좀 더 생각해야겠다.

1차 프로젝트를 앞두고

먼저 이번에 못 한것들을 1차프로젝트 동안 잘 해내고 싶다. 프로젝트는 팀으로 하는 것이다보니 더욱 컨디션 조절에 신경을 써야 할 것이고 혼자 하는게 아니고 시간도 엄수해야하니 무작정 붙들고 있지말고 적절한 타이밍에 구글링 및 동기들의 도움을 요청 하는 것에 더 유연해질 필요가 있다고 생각한다.

아직 배열과 객체와 친하지 않아서 map, filter를 잘 써보고 싶다. 내가 forEach, map, filter를 쓰면 이상하게 작동하지 않는다....😭😭😭😭 진짜 울고 싶다😭😭...

그리고 객체 다루는거 꼭 많이 해보고 싶다. 여전히 obj[key]=value가 바로 머리에 들어오지 않는다😭 외우고 있어서 쓸 수는 있지만 codekata 할 때 어떻게 써야하는지 단 1도 생각나지 않는다. 너무 속상하다.

마지막으로 팀원에게 좋은 팀원이 되고 싶다. 팀으로 움직이는게 너무나도 낯설기에 많은 걱정이 되지만 마지막에 다음에도 같이 하고 싶은 팀원이 되었으면 좋겠다.