바닐라코딩 1, 2주차 회고

-·2021년 6월 20일
0

바닐라코딩

목록 보기
1/2

2021년 6월 7일부터 시작된 바닐라코딩 부트캠프 10기에 참여하며 작성한 글입니다.

본과정이 시작된 지 벌써 2주가 흘렀다.

프렙 때에는 매 오피스 아워마다 그날 배운 것들을 정리했었는데 본과정에서는 과제를 수행하기 바쁘고, 생활적인 측면에서도 적응하는 시간을 필요로 하게 되면서 글을 쓸 여유가 없었다. 다행히 이번주부터는 심리적으로 여유가 생겨 가능한 한 그 주에 받은 피드백과 있었던 일들을 매주 기록으로 남기고자 한다.

프로그래밍을 배우기 시작한 지 얼마 되지 않은데다 첫 독립이라 걱정이 많던 내가 빠른 시간 안에 잘 적응할 수 있었던 것은 모두 동기들과 먼저 부트캠프를 수료한 바코더분들, 그리고 자율적인 학습과 도전을 장려하는 자유로운 분위기 덕분이다. 또한 켄님을 비롯하여 동규님과 멘토 분들 모두 우리가 최대한 적합한 환경에서 학습할 수 있도록 도와주셔서, 과제 이외의 부분에서는 전혀 스트레스를 받지 않을 수 있었다. 이에 대해서는 부트캠프를 무사히 마치고 나면 따로 포스팅하고 싶다.

지난 보름을 지내면서 특히 좋았던 것은 인성도, 학습에 대한 욕구도 뛰어난 분들과 함께라는 점이었다. 질문을 주고받는 일도, 도움을 청하고 받는 일도 자연스럽게 이루어졌다. (임용을 준비할 때 생각했던 가장 이상적인 교수학습의 형태가 내 눈앞에...) 내가 써놓은 암호 같은 코드를 앞에 두고 머리를 싸매고 있으면 먼저 다가와 도움의 손길을 주신 동기분들께 너무 고마웠다. 덕분에 코드를 읽는 정석적인 예시를 배울 수 있었고, 포기하려던 과제도 끝까지 잡고 있을 수 있었다. 천사들이 아닐 수 없다.



지금까지의 코드 리뷰

0. 긍정적인 피드백

  • 코드 스타일이 통일성 있어서 읽는 데 무리가 없는 것이 인상적이었다.
  • boolean type의 변수를 사용해서 코드를 깔끔하게 작성했다.
  • Rest 파라미터의 사용

1. 가독성 📖

1. 무조건 간결하게 작성하기보다는 읽는 사람으로 하여금 작성자의 의도를 잘 알아차릴 수 있도록 작성하는 것이 좋다.

const hasNode = !!list.tail; // 1번
const hasNode = list.tail !== null; // 2번
  • 1번은 list.tail 의 불 값을 나타내고 있으므로 '그렇다면 이 변수는 값이 있으면 true, 값이 없으면 false 이겠구나' 라는 사고 과정을 거쳐야 한다.
  • 2번은 읽는 순간 'list.tail 이 null이 아니면 노드가 존재하는 것이구나' 하고 알 수 있으므로 더 명시적이고 직관적이다.

2. in 연산자나 Object.hasOwnProperty를 이용하면 객체의 프로퍼티 존재 여부를 더 명확하게 표현할 수 있다.

const isCollisionOccured = storedNode && !storedNode[k];
const isCollisionOccured = storedNode && !(k in storedNode); // good!
const isCollisionOccured = storedNode && !storedNode.hasOwnProperty(k); // good!
  • in 연산자 : 명시된 속성이 명시된 객체에 존재하면 true를 반환
  • Object.hasOwnProperty : 객체가 특정 프로퍼티를 가지고 있는지를 나타내는 불리언 값을 반환

3. 함수가 여럿 중첩된 상황에서 함수를 선언해야 할 때, 해당 함수를 따로 빼주면 훨씬 깔끔해진다.

  • 예를 들어 함수 내부에서 다시 함수를 사용하고, 그 함수의 인자로 들어오는 콜백 함수를 다시 정의하는 복잡한 상황인 경우...
  list.forEach((element) => {
    iteratee(element, function (err) {
      if (err) {
        // code...
      }

      if (count === list.length) {
        // code...
      }
    });
  });
  • 아래와 같이 콜백 함수를 따로 빼주면 좀 더 가독성 있게 작성할 수 있다.
  var callback = (err) => {
    if (err) {
      // code...
    }

    if (count === list.length) {
      // code...
    }
  };

  list.forEach((element) => {
    iteratee(element, callback);
  });

4. 코드 상단 변수 선언의 순서는 본문에 등장하는 순서대로 맞춘다.


2. 변수명과 함수명 🖊

1. 생성자 함수가 아니더라도 생성자 함수와 비슷한 용도로 사용할 함수라면 PascalCase로 네이밍한다.

  • 다음의 함수는 node를 생성하는 역할을 하는, 생성자 함수와 유사하게 동작하는 함수이다.
  • 따라서 함수명은 Node 라고 지을 수 있다.
  • new의 의미가 명확하게 드러나는 상황이 아니라면 변수 이름에 new를 붙이지 않는 것이 좋다.
const newNode = function (value) {
  const node = {};

  node.value = value;
  // code...

  return node;
}

2. 함수명은 이름과 함수가 하는 일이 어울리도록 지어야 한다.

  • 함수명은 그 함수가 하는 일을 파악할 수 있도록 지어야 한다.

  • compareValues 라는 함수가 단순히 값을 비교하는 것을 넘어 다른 객체에 노드를 할당하는 일까지 맡고 있다면 이 함수명은 어울리지 않는다.

  • runRecursion 또한 함수가 동작하는 방식을 나타내는 이름이다.
    함수의 사용 목적도, 동작 방식의 측면에서도 재귀의 뜻을 담아야 하는 상황이 아니라면 함수의 목적에 맞는 이름으로 네이밍하도록 하자.


3. 다른 함수명 또는 변수명과 통일성 있게 지으면 좋다.

  • detect 함수 내부의 지역변수인 isFoundisDetected 로 쓸 수 있다.

4. 어떤 함수의 사용 결과를 모은 집합은 다음과 같이 표현할 수도 있다.

  • filter 함수를 통과한 값들의 배열 : filtered
  • groupBy 함수를 통과한 값들의 배열 : grouped

5. 변수명 네이밍 시 데이터의 타입을 변수명에 기재하지 않도록 하자.

  • []을 통해서 collection인 것을 알 수 있기 때문에 굳이 Coll이라는 suffix는 불필요하다.
const resultColl = [];
  • 아래는 프렙 오피스아워 때 기록해둔 것. 이미 배운 것을 응용할 줄 아는 사람이 되자! 🙇‍♂️
// 권장하는 방식
const users = []; // 통상적으로 객체는 복수, 혹은 List를 붙여준다.
const userList = [];
const user = {}; // 객체는 단수로 지어준다.

// 권장하지 않는 방식
const userArray = [];
const userObject = {};
function questionFunction() {};

기타

1. 함수를 만들 때에는 함수가 꼭 필요한지 생각해보자.

  • 함수가 연산의 가독성을 높여주는가?
  • 함수가 재사용되는가?

2. 테스트 케이스 뿐만 아니라 통상적으로 잘 작동하는 함수가 될 수 있도록 작성하자.

  • 테스트 케이스에서는 arg1, arg2 두 개의 인자와 콜백 함수만을 받는 함수일 수 있다.
    그러나 유동적인 인자에도 잘 작동할 수 있도록 작성하면 학습에 더 도움이 된다!



금주 결산!

칭찬할 점

  • 과제들은 여전히 높은 산처럼 느껴졌지만, 1주차에서는 다른 사람들과 진도를 맞추려 쫓기듯이 코드를 쳤다면 2주차에서는 배우는 과정을 즐기려 노력했다. 타인과의 비교가 아닌 나 자신의 성장에 초점을 맞추니 과제의 주제에 흥미가 생겼고, 관심이 높아지니 관련한 개념들을 보다 열린 자세로 받아들일 수 있었다.

  • 프렙에서도 느꼈지만 나는 코드를 읽는 데 능숙하지 않다.
    이 부분에 대해 1주차를 마치고 퍼스널 멘토님과 이야기를 나누었는데, 그때 받은 조언대로 틈이 날 때마다 다른 사람이 작성한 코드를 읽어보고 나 자신의 코드를 다른 사람에게 어떻게 설명하면 좋을지 궁리했다.
    그러다 보니 2주차에서는 코드를 읽는 능력이 조금 좋아진 것 같다. 많이 부족하지만 내가 작성한 코드를 조금이나마 설명할 수 있게 된 건 덤.
    어휴 뿌듯해... 😉


반성할 점

  • 1주차 때 받은 코드 리뷰를 반영하지 못하여 2주차에서도 동일한 리뷰를 받은 부분이 있다.
    배우는 과정에 있는 만큼 완벽할 수는 없지만, 이미 알고 있는 것을 실행에 옮기지 못한 것은 잘못되었다.
    프렙 때에도 좀처럼 하지 않았던 실수를 본과정에 와 범한 이유를 생각해보니, advanced(본 과제는 일찍 끝냈는데 이게 유독 풀리지 않아 3일을 붙들고 있었다. OMG...! 🤦‍♀️ ) 문제에 몰두한 나머지 merge 전 리팩토링과 전주차 리뷰를 검토하는 일에 소홀했다.

  • 이 부분에 대해 다음주부터는 안 되면 일찍 포기하고 능력껏(?) 과제를 하는 것이 좋을지 퍼스널 멘토님께 조언을 구했다. 멘토님께서는 'advanced를 해결하지 못하더라도 시도하는 과정에서 많은 것을 배울 수 있으므로 advanced 도전을 포기하면서까지 본과제를 완벽하게 할 필요는 없다'고 하며 많이 격려해주셨다.
    우리 멘토님... 이 시대의 참 멘토님... 제가 많이 감사합니다...

  • 따라서 다음주부터는 도전과 마무리, 두 마리의 토끼를 다 잡을 수 있도록 과제를 할 때 큰 틀의 계획을 세우려 한다. 적어도 며칠까지 어떤 부분이 해결되지 않으면 남은 부분은 주말이나 break 주간을 이용하고, 대신 로직을 작성하며 얻은 깨달음을 정리하고 리팩토링에 힘을 쏟는다던가 하는 식으로.

  • 알고챌린지 때 다른 분들께 도움이 될 리뷰를 작성할 수 있도록 정진하자.
    새로운 개념이나 기존 개념의 응용 등 상대방이 모르는 것을 잘 알려줄 수 있는 사람이 되자.




이번주에 있었던 일

  • 켄님께서 일요일 출근자에게 스벅 커피를 쏘셨다.
    이번주 일요일은 집에서 배운 것들을 정리하려 했는데, 커피 마시려고 멀미실로 직행한 건 안 비밀.
    아아메만 사주실 줄 알았는데 취향껏 고를 수 있도록 해주셔서 무척 감동했다.

  • 수형님과 동혁님이 야간 세미나(?)를 개최하셨다. 사실 기획은 두 분이서 조촐한 스터디를 만들어 의견을 교환하는 식이었다는데 저녁까지 열정을 불태우던 10기 바코더와 오아룸에 계시던 9기 분들까지 모여 세미나가 되었다. SOLID 디자인 패턴, 2주차 공부 내용 복습, 레드 블랙 트리, 다음주에 공부할 정렬 등에 대해 다루었다.


0개의 댓글