🛼 우아한 테크캠프 1주차 회고(0705~0708)

🤘 1주차 미션

1. 배민 회원가입 프론트엔드 구현(바닐라 JS 이용, 라이브러리 사용 불가)

2. 배민 회원가입 백엔드 구현(ExpressJS, pug 템플릿 이용, npm 패키지 DB 이용)

3. Heroku 이용 배포

---

배달의 민족 회원가입 기능을 구현하는 미션을 수행했습니다. ExpressJS 프레임워크를 이용해 서버를 구축하고 템플릿을 이용해 뷰를 구현합니다. 작업물은 최종적으로 Heroku를 이용해 배포하는 과정으로 마무리합니다.

주의사항으로는 비즈니스 로직을 작은 함수들로 분리하는 것과, 공통된 스타일 정리, 올바른 시맨틱 태그의 적용이 있습니다.

아쉽지만 결과적으로, 주어진 요구사항 중 회원가입 기능은 시간에 쫓겨 구현하지 못했습니다. 😢

⚒ 설계

## 메인 페이지

로그인 버튼 

- 로그인 페이지로 이동한다.

## 로그인 페이지

로그인 아이디 인풋 

- 유효성 검증(이메일 형식 또는 아이디 형식), 값 입력이 완료되지 않을 시 경고 메시지

회원가입 버튼 

- 회원가입 페이지로 이동한다.

## 가입 약관 동의

약관동의 체크박스

- 약관 항목이 모두 선택될 시 전체동의 체크됨
- 약관 항목이 하나라도 빠져있으면 전체동의 체크 해제
- 전체동의 체크 시  모든 항목이 체크됨

나이 선택 버튼

- 둘 중 하나만 선택 가능(14세 이상 또는...
.
.
.
.

프론트엔드는 다음과 같이 페이지 별로 기능을 나눴습니다. 유효성 검증 여부, 발생하는 이벤트 등을 중점으로 분석하고 이슈를 발급합니다.

백엔드는 아직 역량이 부족해 따로 설계를 진행하지 않고, Express와 에상 API를 기반으로 라우팅 설정, request body 설정 등을 진행했습니다.

HTML이 아닌 pug 템플릿을 이용했기 때문에 초기 진입장벽이 있었지만 어느정도 연습을 거치니 마크업과 스타일링은 수월하게 할 수 있었습니다.

🍎 미션 진행 중 고려한 사항

프론트엔드

• 전역적 변수 선언, 함수 호출 최소화

  addEventListner나 DOM object 참조 등 다양한 구문을 최대한 함수 안에서 하도록 만들었습니다. 함수의 스코프 안에 해당 사항들을 넣어 외부에서 참조를 막기 위함입니다. 예상치 못한 사이드이펙트를 줄일 수 있는 좋은 습관인 것 같습니다.

• 유틸 함수 분리

  미션의 요구사항 중 4자리의 무작위 숫자를 생성해 인증번호로 사용하는 부분이 있었습니다. 이때 n자리의 random number를 생성하고, 해당 로직의 연속적인 호출을 막기 위해 debouncer를 사용했는데, 두 메소드는 재사용성이 높다고 판단해 유틸 파일들로 분리했습니다.

• 네트워크 요청 분리

  login request나 register request 등 네트워크 요청을 유틸 함수처럼 분리 과정을 거쳤습니다.

• 공통 스타일을 고려한 stylesheet

:root {
  --baemin-mint: #2ac1bc;
  --baemin-gray: #d7d7d7;
  --baemin-light-gray: #f6f6f6;
  --baemin-font-gray: rgb(147, 146, 146);
  --baemin-red: #da0d0d;

  --large-img-size: 3rem;
  --middle-img-size: 2rem;
  --small-img-size: 1rem;

  --large-font-size: 1.2rem;
  --middle-font-size: 1rem;
  --small-font-size: 0.8rem;
}

.baemin-btn--primary {
  color: white;
  background-color: var(--baemin-mint);
  padding: 0.75rem;
  border: none;
  font-size: var(--middle-font-size);
  font-weight: bold;
  border-radius: 0.5rem;
  cursor: pointer;
}

스타일시트 파일에서도 공통된 부분을 추려 반복을 줄일 수 있습니다. 위와 같이 사용자 지정 변수를 활용해 공통된 속성을 한 곳에서 관리할 수 있고, 버튼의 스타일 등 자주 사용되는 양식은 공통 적용 스타일시트에 넣어 모든 곳에서 접근하게 만들 수도 있습니다.

백엔드

백엔드는 경험이 많지 않아 다양한 애로사항을 겪었습니다. Express 프레임워크 자체가 처음이기도 했고, pug라는 템플릿 엔진까지 사용했기 떄문에 이 부분을 익히는데 시간이 많이 걸렸습니다.

pug

extends layout 

mixin checkInput(id, className, text)
  if className.includes('agree--all')
    div(class=`checkbox__container ${className}`)
          input(type="checkbox" id=id)
          label(for=id)=text
  else
    div(class=`checkbox__container ${className}`)
      input(type="checkbox" id=id)
      label(for=id)= text
      img.arrow(src="/images/terms_and_conditions/right-arrow.svg", alt="right-arrow")

block stylesheet
  link(rel="stylesheet", href="/stylesheets/agree_terms.css")

block scripts 
    script(src="/javascripts/agree_terms.js" defer)

block content 
  body 
    header.header
      a.header__right-link(href="/")
      h2.header__title 회원가입
    p.guide-ment 어서오세요
    p.guide-ment 약관 동의가 필요해요.
    form.agree-terms__form
      +checkInput("agreeAll", "agree--all", "전체동의")
      +checkInput("baemin", "agree essential", "배달의 민족 이용약관 동의")
      +checkInput("fintech", "agree essential", "전자금융거래 이용약관 동의")
      +checkInput("personalInfo", "agree essential", "개인정보 수집이용 동의")
      +checkInput("personalInfoToThirdParty", "agree option", "개인정보 제3자 제공 동의(선택)")
      +checkInput("marketing", "agree option agree--last", "마케팅 정보 메일, SMS 수신동의(선택)")
      label.age-select__container
        input(type="radio" name="age" id="age" checked=true)
        p 만 14세 이상입니다.
        img.age-select__avatar(src="/images/terms_and_conditions/over.png", alt="over_person")
      label.age-select__container
        input(type="radio" name="age" id="age")
        p 만 14세 미만입니다.
        img.age-select__avatar(src="/images/terms_and_conditions/under.png", alt="under_person")
      button.baemin-btn--primary.next-btn(type="submit" disabled) 다음으로

다음과 같은 형태로 이루어진 템플릿입니다. 마크업을 스크립트 파일처럼 재사용, 분기 처리, 모듈화를 할 수 있다는 장점 때문에 유용하다고 생각합니다. 물론 다시 사용할지는 모르겠습니다. 🥵

같은 캠퍼분들도 대부분 처음 사용하시는 분들이었을 텐데 저처럼 마구잡이로 사용하는 게 아니라 도구의 장단점을 먼저 파악하고 특성에 맞게 사용하는 분들도 계셨습니다.

그런 분들을 보면서 도구 사용에 있어 올바른 접근법이 무엇인지 고민해봤습니다.

Express

미들웨어
Express 프레임워크의 핵심 기능 중 하나는 미들웨어입니다. 미들웨어를 통해 요청에 앞서 쿠키를 조회하며 다양한 기능에 분기를 만들어 낼 수 있습니다.

예를 들면 유저의 로그인 여부가 있습니다.

1. 게시글 쓰기, 게시글 삭제, 게시글 수정 API 생성
   쓰기는 유저 로그인 여부 필요, 삭제와 수정은 현재 사용자가 작성자인지 확인하는 과정이 필요합니다.
2. 게시글 쓰기의 미들웨어에 유저 로그인 여부 확인 미들웨어 추가
3. 게시글 삭제, 수정에 유저 권한 확인 미들웨어 추가

// board.js

const express = require('express');
const router = express.Router();

router.get('/', readPosts);
router.post('/write', checkUserLogin, writePost);
router.post('/edit', checkUserAuthority, editPost);
router.post('/delete', checkUserAuthority, deletePost);

module.exports.router;

다음과 같은 형태로 구현할 수 있을 것 같습니다. 이번 미션에서 비록 미들웨어의 원활한 사용은 하지 못했지만 다음 미션에서는 이러한 Express의 특성을 잘 살려봐야겠습니다! 🎯

로직 분리
프론트엔드처럼 백엔드에서도 최대한 로직을 분리하려고 했습니다. DB 접근 메소드, 쿠키 파싱 등 재사용성이 높은 로직들은 lib 폴더 안에 넣어 관리했습니다.

페이지 라우팅이 아닌 api 요청 등은 api 폴더의 하위 항목으로 각각의 카테고리에 맞게 라우팅 설정을 했습니다. 이런 방식도 Express의 미들웨어를 이용한 방법 중 하나입니다.

현재 api 구현에서는 유효성 검증하는 로직도 함께 포함되어있는데 해당 부분을 따로 빼서 구현하는 게 더 가독성 측면에서 좋았을 것 같습니다.

🧠 고민과 생각

미션 수행 후 크롱과 호눅스의 리뷰를 듣고, 다른 사람의 구현과 제 코드를 비교하면서 생각해 본 내용들입니다.

1. 코드의 품질과 완성도

이번 미션의 기한이 사실 상 이틀이었기 때문에 저에게는 굉장히 짧은 시간이었습니다. 주어진 기능의 완성과 코드 퀄리티를 모두 챙기기란 어려운 상황입니다.

기존에 가지고 있었던 생각은 무조건 완성도가 중요하다는 쪽이었습니다. 만약 업무라면 기한 내에 일단 완성을 시키고 추후 유지보수를 통해 퀄리티를 올릴 수 있기 때문입니다.

하지만 지금은 교육이 중점이 되는 기간이기 때문에 첫 번째 목표는 학습입니다. 그동안 개인적인 작업만 해왔기 때문에 다른 사람이 내 코드를 보고 어떻게 느끼는지는 중요사항이 아니었지만 지금은 협업을 경험할 수 있는 기회입니다.

동료들과 높은 품질의 코드에 대해 학습하는 것이 높은 우선순위를 가져야 할 것 같습니다.

물론 실력이 충분하다면 품질과 완성도 둘 다 챙길 수 있습니다... ☠️ 결론적으로 크롱은 완성도와 품질 모두 포기할 수 없는 것들이라고 말했습니다. ㅎㅎ

2. 커밋의 단위

커밋은 atomic 해야한다.

리뷰의 마지막에 호눅스가 commit에 대한 얘기를 해줬습니다. commit은 자신이 되돌아갈 수 있는 save point입니다. 그렇기 때문에 해당 커밋에서 무슨 작업을 했는지 한눈에 파악할 수 있어야합니다.

atomic 커밋은 위와 같은 사항을 잘 준수합니다. 최대한 작은 단위로 커밋을 쪼개면 커밋 메시지에 담기는 내용이 풍부해집니다. 호눅스는 메소드 단위로 커밋을 쪼개는 걸 추천했습니다. 그렇게까지 작게 쪼개는 게 맞는가 싶었지만, 생각해보면 맞는 것 같습니다.

하나의 PR에는 여러 개의 커밋이 담깁니다. 그리고 commit을 보고 어떤 작업을 어떻게 접근했는지 파악할 수 있게됩니다. 큰 덩어리로 커밋을 날리게 되면 커밋에 담긴 의미가 모호해져 나중에 확인할 때 힘들 수 있겠다는 생각이 들었습니다.

최대한 커밋을 쪼개면서 개발하는 습관을 들여야겠습니다.

3. 사람 중심의 코드

비록 짧은 시간이지만, 여태 공부하면서 들었던 말들, 그리고 미션의 리뷰를 통해 좋은 코드란 무엇인지 다시 한번 생각해보게 됐습니다.

한 문장으로 요약하자면 다음과 같습니다.

다른 사람이 내 코드를 볼 때 기능을 한눈에 파악할 수 있어야한다.

코드는 나타나는 바가 명확해야합니다. 그렇기 때문에 작성된 함수들은 기능이 간결해야하고 복잡한 부분들을 분리 과정을 통해 적절한 추상화 계층을 제공해야합니다.

예를 들면 조건문의 조건에서 password 유효성을 검증하는 로직을 작성하는 게 아닌, 유효성 검증을 따로 메소드로 분리해 조건 안에서 호출하는 방식, 이벤트 핸들러에 기명 함수를 사용하는 방식, 매직넘버를 상수로 관리하는 방식 등이 있습니다.

또한 크롱이 Early return과 코드의 가독성의 연관성에 대해 말해주었습니다.

if (복잡한 조건) {
	...다양한 로직들
} else {
  return;
}

위와 같은 형태로 코드를 작성할 경우 사람은 로직을 볼 때 조건을 계속 생각하면서 로직을 봐야합니다.

if (!복잡한 조건) {
	return;
} 

...다양한 로직들

하지만 return이 되는 조건을 먼저 검사한다면 로직을 볼 때 조건이 머리에서 차지하는 부분이 줄어듭니다. 명확하게 설명할 수는 없지만 실제로도 그렇게 느껴지는 것 같습니다.

코드의 동작에 집중하는 게 아닌 읽기 쉬운 코드를 작성하는 것에 중점을 두어야 할 것 같습니다.

4. 변수와 함수의 이름

변수는 명사 형태, 함수는 동사 + 명사 형태로 짓는 것이 기본적인 네이밍 규칙입니다. 너무 기능의 완성에만 초점을 맞추면 이런 부분들을 간과하고 코드를 작성할 때가 있는데 항상 명심하면서 코드를 작성해야겠습니다.

그리고 변수와 함수 이름의 길이에 대한 고민을 했습니다. 의미를 나타내기 위해 아주 긴 이름이 사용되는 것도 괜찮은지에 대한 고민입니다. 그리고 저는 괜찮다고 결론을 내렸습니다.

물론 충분한 생각을 거친 후 정말 그렇게 긴 이름이 사용되어야 할 때만 사용해야합니다. 최대한 코드가 나타내는 바가 풍부해야한다고 생각합니다.

👍 후기

미션을 처음 받았을 때는 너무 쉽다고 생각했습니다. 하지만 그것은 자만이었고, 이번 미션을 통해 역량의 부족함을 뼈저리게 느낄 수 있었습니다. 😦

단순이 작동만 하는 코드에서 더 나아가 좋은 코드에 대한 고민을 하면서 코딩을 하는 게 얼마나 힘든 작업인지, 다른 캠퍼들의 구현을 보면서 각자가 기능을 바라보는 시선의 차이가 얼마나 큰지 알았습니다.

이렇게 관점이 다른 사람들끼리 모여 협업을 진행하면 본인이 작성한 코드가 나타내는 바가 명확해야합니다. 가독성 좋은 코드, 공유 가능한 코드에 대해 항상 생각하며 다음 주 미션에 임해야겠습니다.