바닐라코딩 부트캠프 3주차 후기

2020년 1월 6일(월)에 시작한 바닐라코딩 부트캠프 7이 벌써 3주나 지났다. 지난 3주간을 돌아보며 느낀 점, 배운 점을 정리하고자 한다.

---

2주차에 자료구조를 배운 것에 이어 3주차에는 정렬 알고리즘에 대해서 배웠다. 가장 기본적인 bubble sort, insertion sort 뿐 아니라 merge sort, quick sort 등에 대해서 배웠고 이 정렬 로직들을 시각적으로 구현하는 간단한(?) 과제가 주어졌다. 이 정렬 로직들도 학원 들어오기 전에 udemy에서 이것저것 들으면서 공부를 하긴 했었는데 시각화를 하는 것은 역시 어렵더라..ㅠㅠ

 

강의를 듣고 이해를 하긴 했었는데 완전 내 것이 되도록 충분하게 연습하지 못했던 것이 원인인 듯 하다. 그 당시에는 학원 들어오기 전에 최대한 많이 배워놓고 가고 싶어서 얼른 자바스크립트 강의도 듣고, 리액트도 듣고, css도 공부하고,, 이런 욕심이 있어서 열심히 진도를 나가느라 배운 것을 다지기에 소홀했던 것 같다.

 

우선 3주차 과제에 대한 피드백부터 정리해본다.

---

# 3주차 피드백 정리

[ 개선점 피드백 ]

 

• 에러 메세지에 대한 상수처리 => 에러메세지는 변할 필요가 없고, 화면 전반에서 사용되기 때문에 간단하게 객체 하나에 3가지 에러 메세지를 상수로 담아서 에러가 발생할 시 객체에 담긴 value를 return하도록 하면 훨씬 깔끔하고 실수를 방지할 수 있다.
• chaining call의 경우 끊어주는 것이 가독성에 좋다. => 나는 개인적으로 chaining이 한 번 밖에 없어서(ex. foo(a, b).then(bar)) 한 줄에 이어 쓰는게 깔끔하다 생각했는데, 어쨌든 chaining call이면 따로 끊어서 써 주는 것이 일반적으로는 가독성이 더 높은 방식인 것 같다.
• 변수명은 동사로 시작하지 않도록 => 함수는 동사형으로, 변수는 명사형으로 짓는 것을 신경쓰고 지었었는데 실수로 변수 하나를 동사형으로 시작하도록 지었다. 다음 번엔 실수하지 않아야 할 것이야...!!!
• validate* 변수명 => 유효한 값이라는 의미로 validInput이라고 변수명을 지었었는데, 보통 validate*로 많이 사용한다 피드백 주셨다. 몰랐던 부분이라 바로 다음부터 반영해야겠다!(ex. validateInput, validateData ...)
• 더 직관적인 return값 => 모든 피드백이 다 좋았지만, 요 피드백이 내 가려운 부분을 가장 많이 긁어준 피드백이었다. 아래에 좀 적어보자면..

내가 helper function으로 구현한 것 중, 사용자 input의 유효성을 체크하는 로직의 함수가 하나 있었다.
유효하지 않은 input(ex. 문자열이 들어오거나, input 데이터가 10개가 넘어가는 등...)의 경우 string 형태의 에러 메세지를 return하고, 유효한 값만 들어왔을 경우 해당 값들을 배열에 담아서 return시키는 함수였다.

 

나도 사실 이 함수를 만들면서 찜찜한 구석이 있었다. 왜냐하면 에러일 땐 string을 return하는데 에러가 아닐 땐 array가 return되니까 return 값에 통일성이 없었기 때문이다. 그러다보니 다음 로직에서 이 함수 return 값의 type이 string이면 error가 난 것으로 간주해서 error 메세지를 나타내는 함수를 호출하고, 그렇지 않으면 애니메이션을 시작하도록 했는데 이 또한 맘에 들지 않았었다. 에러 발생 여부를 return값의 data type으로 판별하는게 싫었는데 대안을 생각 못해서 그냥 넘어갔었다.

 

const checkInputValidity = (input) => {
  const arr = input.slice();
  const validInput = [];

  if (arr.length > 10) {
    return 'ERR: MORE THAN 10 NUMBERS.';
  } else if (arr.length === 1 && arr[0] === '') {
    return 'ERR: NO INPUTS.';
  }

  for (const num of arr) {
    if (Number.isNaN(parseInt(num))) return 'ERR: INPUT INCLUDES VALUES NOT A NUMBER.';
    else validInput.push(parseInt(num));
  }

  return validInput;
}

 

이해를 돕기 위해 대충 쓰자면 대략 위와 같은 코드이다. 위 코드를 보면 error가 발생하면 string을, 그렇지 않으면 배열을 return함을 알 수 있다. 그런데 멘토님이 return값으로 {isValid: false, errMessage: 'some error message...', validInput: []} 이런식으로 객체를 return시키면 더 직관적이다는 피드백을 주셨다. 딱 이 코멘트를 보는 순간 가려운 부분이 싹 해소되는 느낌이었다! 개비스콘 같은 느낌! 이렇게 하나 하나 배워가는 것 같아서 기분이 좋다.

 

# 실수도 실력이다.

회사를 2년 다니면서 '실수'와 관련해서 나름대로 느끼고 생각한 것이 있다.

 

사람은 누구나 실수를 한다. 하지만 소위 말하는 '일잘러'와 '일못러'의 차이는 아주 사소한 습관에서 온다.

• '일잘러'는 실수를 인정하고 실수하게 된 원인을 생각하지만, '일못러'는 실수를 인정하는 대신 변명을 늘어놓기 급급하다.
• '일잘러'는 같은 실수를 세 번 이상 반복하지 않고, '일못러'는 같은 실수를 수 차례 반복한다.

 

코딩을 배우는 코린이로서 현재 나는 '일못러'이다. 매주 과제를 제출하고 피드백을 받아보면 '왜 이런 기초적인 실수들을 했을까?' 같은 생각에 혼자 있어도 괜히 부끄러워진다. 그리고는 매주 이렇게 후기를 작성하면서 피드백들을 정리하는 시간을 가지고, 왜 내가 저런 실수들을 저질렀는지 가만히 생각해보게 된다.

 

받은 피드백을 보면 물론 내가 몰랐던 내용들도 무척 많지만, 내가 알고 있음에도 코드로 보여주지 못해 지적받은 피드백들의 비중도 상당히 많다. 여기서 피드백에 어떻게 대처하는지가 정말 중요하다고 생각한다. '저도 아는 내용인데 막 급하게 바쁘게 하다보니까 그렇게 됐어요.'와 같은 생각이 꿈틀거린다 싶으면 바로 집어 넣어야 한다.

 

모두에게 주어진 시간은 동일했는데 누군가는 실수를 저질렀고, 누군가는 실수를 하지 않았다. 결국 내가 아는 내용에서 실수를 저지른 것은 1) 안다고 생각했지만 사실은 제대로 알지 못했거나, 2) 아는 내용을 실수하지 않도록 충분한 노력을 들여 습관화하지 못했거나 둘 중 하나이다.(결국 둘 다 같은 말인 것 같기도 하고..) 그리고 결국 그게 현재의 내 실력이다.

 

실수했다는 사실을, 그리고 현재 내 실력을 인정하지 않으면 발전할 수 없다. 변명하는 순간 그 피드백은 내가 수용하지 않는 태도로 갈 수 밖에 없다. 그래서 나는 그 어떤 일이 있어도 실수에 변명하는 일은 학원에서도, 회사에서도 죽을 때까지 하지 않으려고 노력한다. 실수는 '변명(excuse)'이 아니라 '인정(acceptance)'으로 대처해야 한다. 실수를 인정하는 것에도 용기가 필요하다.

 

# 가독성이란 무엇일까

3주차까지 과제를 제출하면서 5개의 평가 지표 중에 3가지 지표에서는 종종 'excellent' 평가를 받았고, 요번 과제에서도 그랬는데 유독 'code style'과 'readability' 지표에서는 항상 'excellent' 대신 'good job' 평가만 받고 있다. 이번 과제에서는 정말 가독성을 좋게 하고 싶어서 최대한 변수명도 descriptive하게 작성하려고 노력했고, 로직도 내 두뇌 능력 내에서 최대한 깔끔하게 작성하려고 노력했다. 그런데 요번에도 'good job'을 받으니 도대체 가독성이 무엇일까 생각을 많이하게 된다.

 

도대체 좋은 가독성이란 어디에서 오는 것일까?

이 질문을 3주째 스스로 던지고 있는데, 어떤 것 하나로 콕 집어서 말할 수 없지만 가장 큰 요인은 'logic 자체의 깔끔함'이라고 잠정적으로 결론지었다. 결국 책 읽듯이 코드가 읽힌다는 것은 어떤 로직으로 코드가 흘러가고 있는 것인지가 명확한 것이 제일이라고 생각한다. 그리고 로직의 깔끔함이 전제될 때, 그 이후에 구체적이고 설명적인 변수명/함수명을 사용하고, 적절한 띄어쓰기로 chunk를 구분지어주는 등의 행동이 수반되어야 한다고 생각한다.

 

그런데 매번 내 코드가 readability 측면에서 'excellent'하지 못했다면, 나는 어떤 부분이 부족했던 걸까? 자꾸 고민하게 된다.. 이번 과제에서는 'chaining call'에서 끊어주지 않아서 그랬을까? 아니면 if else 문에서 block으로 처리하지 않고 짧으면 한 줄로 처리하는 습관 때문에 그랬을까? 아니면 논리 자체가 더 깔끔했어야 할까?🤔 3주 동안 이 부분에 대해서 고민해봤는데 혼자서는 잘 모르겠어서, ken님께 한 번 여쭤볼 계획이다..!

 

그래도 긍정적으로 생각하자면, 어찌됐든 매번 excellent 대신 good job을 받은 덕에 매주 '가독성'에 대해 이렇게 고민하고 있는 것 같다. 만약 좋은 평가만 받았다면 지금만큼 깊게 고민하는 기회를 가지진 못했을 것이다. 그리고 이 고민은 배우는 지금 해야지, 회사 가서는 이게 고민이 아니라 내 코드에서 드러나는 사람이 되어야하니, 어찌보면 다행이라고 생각한다!😂

---

이번 한 주는 바삐 과제하느라 밀린 블로그 정리, 깊게 탐구하지 못했던 pub-sub이나 자바스크립트 디자인패턴 등에 대해서 정리하고 비동기 자체에 대해서 조금 더 면밀히 공부하고 싶다. You Don't Know JS 열심히 읽고 정리해야지...!