배달의 민족 미니 프로젝트 회고

지난 금요일 커넥to에서 미니 프로젝트를 시작하였다.

HTML/CSS 수업을 한달동안 배운 것을 응용하여 클론코딩을 하거나 자유주제로 웹 페이지를 만들고 발표하는 과제였다.

주제 선정

팀원들과 아이스브레이킹을 하면서 프로젝트 주제에 대해서 이야기 하였다.

각자 좋아하는 분야에 대해 자유주제를 정하기도 하였지만

우리가 그동안 배운것을 가장 잘 응용해볼 수 있는 주제를 정하기로 하였다.

그러던 중 앱 서비스만 있는 배달의 민족을 웹으로 구현해보면 어떨까라는 생각을 하였다.

배달의 민족을 선택한 이유

• 간편주문이라는 슬로건에 맞지 않게 점점 복잡해지는 UI

• 코로나 완화로 배달앱 사용자 유저 급감

• 태블릿 버전 미지원으로인한 UX 저하 …

위와 같은 문제를 개선하기 위해 배달의 민족 웹 서비스를 개발해보기로 결정하였다.

발표 방향 선정

웹 접근성을 고려하여 간편모드를 제공한다.

기존 배민에서 제공하는 앱 서비스를 이용하기 불편한 장애인, 저시력자 등을 고려했다.

이와 더불어 태블릿에서도 지원가능한 반응형 웹 사이트를 개발한다.

협업방식

1. CSS 프레임 워크 선정

기획단계에서 우리가 만들 페이지가 8페이지로 정해졌다. (일반모드 4페이지 + 간편모드 4페이지)

많은 페이지를 관리하기 위해 sass 프레임워크를 사용했다.

Sass를 선택한 이유

1. @mixin

@mixin을 사용하여 여러 페이지에서 자주 사용되는 스타일을 @iclude 하여 사용하기 편하게 했다.

2. BEM 표기법

BEM 표기법을 사용하여 naming convention을 정하면 이후 nesting 문법을 사용하여 관련 클래스를 한눈에 보기 편하다.

3. 스타일 컴포넌트화

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

src
├── css
│   ├── index.css
│   └── index.css.map
├── fast_pages
│   ├── main.html
│   ├── menu.html
│   ├── store.html
│   └── storeList.html
├── js
│   ├── jquery-1.12.3.js
│   └── scripts.js
├── nomal_pages
│   ├── main.html
│   ├── menu.html
│   ├── store.html
│   └── storeList.html
└── scss
    ├── absrtacts
    │   ├── _index.scss
    │   ├── _media-query.scss
    │   ├── _mixin.scss
    │   └── _unit.scss
    ├── base
    │   ├── _default.scss
    │   ├── _index.scss
    │   ├── _nomalize.scss
    │   └── _reset.scss
    ├── components
    │   ├── _index.scss
    │   └── _navigation.scss
    ├── index.scss
    ├── layout
    │   ├── _footer.scss
    │   ├── _header.scss
    │   └── _index.scss
    ├── pages
    │   ├── _fast-main.scss
    │   ├── _fast-menu.scss
    │   ├── _fast-store.scss
    │   ├── _fast-storeList.scss
    │   ├── _home.scss
    │   ├── _index.scss
    │   ├── _nomal-main.scss
    │   ├── _nomal-menu.scss
    │   ├── _nomal-store.scss
    │   └── _normal-storeList.scss
    └── themes
        ├── _a11y.scss
        ├── _color.scss
        ├── _font.scss
        ├── _index.scss
        └── _spacing.scss

각 페이지에 적용되는 스타일들만 따로 빼내어 사용할 수 있어 이후에 유지관리가 용이하다.

2.HTML 구조 설계

웹 접근성을 고려하여 div태그를 최소화하고 시멘틱 태그를 사용하여 논리적인 구조로 마크업을 설계해야한다.

1
2
3
4
5
6

<!-- 헤더 -->
<header class="header">...</header>
<!-- 메인 -->
<main id="skip" class="main">...</main>
<!-- 푸터 -->
<footer class="footer">...</footer>

3. figma 디자인 시안 제작

우리가 만들 페이지를 figma를 사용하여 디자인 시안을 제작한다.

margin, padding, font, color 등 통일해야할 부분을 미리 정해놓고 작업한다.

4. gitflow 전략

저번 8월 3일 TIL 작성에서 배웠던 gitflow 전략을 사용하여 버전관리와 협업을 진행하였다.

과정 중 문제점

1. 크로스 브라우징

safari, FF, Chrome 대표 브라우저에서 동일하게 동작하는지 확인하여야 한다.

safari, FF에서 탭키 issue

FF에서 탭키 포커스가 button 태그에 있을 경우 영역이 점선으로 표현되는 현상

위 설정을 체크해줘야한다.

1
2
3
4
5
6

button:-moz-focusring,
[type="button"]:-moz-focusring,
[type="reset"]:-moz-focusring,
[type="submit"]:-moz-focusring {
  outline: 1px dotted;
}

위 현상은 normalize.css에서 스타일을 지정해주었기 때문에 발생하였다.

safari에서 탭키가 input 요소이외에는 포커싱안되는 현상

위 설정을 체크해줘야 한다.

2. Lighthouse 성능

lighthouse 성능 테스트를 사용하여 성능을 측정해본 결과

성능이 매우 낮게 나왔는데, 그 이유는 적절한 이미지 포맷을 사용하지 않았기 때문이다.

이미지 포맷을 webp 형식으로 변환한 후 사용할 경우 성능이 개선되었다.

소감

프로젝트 발표 기획부터 디자인, 마크업 설계, sass 스타일링, git 협업 등으로 1주일이 순식간에 지나간 것 같다.

그만큼 힘들었지만 팀원들과 웃으면서 같이 원하는 목표를 이루기 위해 으쌰으쌰하니깐 동기부여도 되고 좋은 추억도 많이 쌓을 수 있었다.

열심히 노력은 했지만 그래도 아쉬운 점이 많이 남는다.

• 이미지 포맷 issue에 대한 작업을 더 참여해보지 않은 것에 대한 아쉬움

• 화면에 필요한 디자인 요소들을 미리미리 준비하지 못했던 아쉬움

• git을 배운대로 제대로 사용해보지 못한 아쉬움

그리고 다른 팀의 발표를 보면서 느낀점은 확실히 한달전에 처음 발표 때와 비교해서 다들 많이 성장했다는 것을 느꼈다.

나도 그 때보다는 더 나아진 모습이라고 생각하지만, 발표를 잘하는 분들을 유심히 관찰하면서 그분들 처럼 능숙하게 발표를 할 수 있도록 더 노력해봐야겠다고 다짐하는 시간을 갖게 되었다.

또한, 데레사강사님의 마지막 말씀이 기억에 남는다.

남은 5개월 과정이 짧지 않은 기간일 것이니, 과정을 중요시하며 느슨해지지 말고 동기들과 소통을 자주하여 커뮤니케이션 스킬을 향상 시키도록 하자.

댓글 공유

오늘 공부한 것

배달의 민족 프로젝트

inline 요소 layout 배치

위 사진처럼 우리집(button)이 좌측으로, cate(a), alert(button), my(a)가 우측에 배치되어 있는 레이아웃을 만들어 보자.

마크업

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

<header class="header">
  <h1 class="header__logo">
    <a class="logo__link" href="/"
      ><img class="logo__img" src="/" alt="배달의 민족"
    /></a>
  </h1>
  <div class="nav-wrapper">
    <button class="header__address-button">우리집</button>
    <a class="category" href="/">cate</a>
    <button class="header__alert-button">alert</button>
    <a class="mypage" href="/">my</a>
  </div>
  <form class="search-form" action="">
    <fieldset>
      <legend class="sr-only">검색 폼</legend>
      <label class="sr-only" for="">검색</label>
      <input
        class="search-form__input"
        placeholder="찾아라! 맛있는 음식과 맛집"
        type="search"
      />
      <button class="search-form__button-submit" type="submit"></button>
    </fieldset>
  </form>
</header>

• button, a 태그 둘다 인라인 요소이므로 한줄을 전부 차지하는 block 요소와 다르게 컨텐츠의 크기만큼 width,heigth를 가진다.

sass

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

// 헤더
.header {
  background: $mainColor;
  padding: rem(19px);
  border-radius: 0 0 20px 20px;
  & .nav-wrapper {
    display: flex;
    flex-flow: row nowrap;
  }
  &__address-button {
    @include size(rem(120px), rem(32px));
    background: transparent;
    border: 0px solid black;
    margin-top: rem(20px);
    text-align: left;
    margin-right: auto;
  }
  & .category,
  &__alert-button,
  & .mypage {
    @include size(rem(32px), rem(32px));
    background: red;
    border: 0;

    margin-top: rem(20px);
  }
  &__alert-button {
    margin-left: rem(20px);
    margin-right: rem(20px);
  }

• button,a 태그들을 좌우배치하기 위해 이들을 div로 감싸고 부모요소에게 flex를 주었다.
• button, a 태그 각각 width, heigth를 주었다.

• a,button 태그들이 flexible 속성으로 변하게 되면서 각 content만큼 width를 갖는 inline-block 요소로 변한다.
• flex 요소들이 직접 width를 가지거나, 컨텐츠 크기만큼 width를 가졌을 때, 결국 각자의 width를 가지고 있기 때문에 요소들에게 margin auto 속성을 적용하여 좌우 배치할 수 있다.

자주 쓰는 :nth-child()

1
2
3
4
5
6
7
8
9
10
11
12
13
14

<address class="address">
  <span>(주)우아한형제들</span>
  <span>대표이사 김범준</span>
  <span>사업자등록번호 120-87-65763</span>
  <span>통신판매업 서울 송파-0515</span>
  <span>호스팅서비스제공자 (주)우아한형제들</span>
  <span><a href="CS@woowahan.com">CS@woowahan.com</a></span>
  <span>서울특별시 송파구 위례성대로 2 장은빌딩</span>
  <span
    >전자금융분쟁처리 Tel <a href="tel:1600-0987">1600-0987</a>(유료),
    <a href="080-849-0987">080-849-0987</a>(무료)</span
  >
  <span>Fax <a href="fax:050-6050-0400">050-6050-0400</a></span>
</address>

• 위 마크업 처럼 address 안에 span 태그의 형제요소들이 많이 있을 때, 내가 원하는 순서의 span 태그에만 스타일링 주고 싶을 때 사용

3번째 포함 그 이후 요소

1
2

span:nth-child(n + 3) {
}

3번째 부터 5번째 요소

1
2

span:nth-child(n + 3):nth-child(-n + 5) {
}

짝수 및 홀수 요소

1
2
3
4
5

span:nth-child(odd) {
}

span:nth-child(even) {
}

함수형 요소

1
2

span:nth-child(3n + 1) {
}

• 1, 4, 7, 10 … 요소 선택

::after,before로 세로선 스타일링

각 a 태그 사이에 | 구분선 모양을 가상 요소 선택자를 사용하여 구현해보자.

1
2
3
4
5
6
7
8
9

li:nth-child(n + 2)::before {
  content: "";
  position: absolute;
  width: 1px;
  height: 90%;
  background: $gray-100;
  top: 0;
  left: -6px;
}

• 2번째 li 태그부터 끝까지 before 선택자로 선택하였다.
• position : absolute 를 주고 배치를 맞춘 뒤 배경색을 채우고 width,height를 설정하여 선처럼 보이게 하였다.

오늘 소감

내일은 1달간 HTML/CSS 수업에 대한 미니 프로젝트 발표가 있는 날이다. 수업동안 상대적으로 어려운 예제를 다루다가 일반적인 레이아웃을 다루니 쉽게 레이아웃은 쉽게 느껴졌다. 하지만, 여전히 제일 어려운 것은 마크업인 것 같다. 논리적인 순서에도 맞아야 하며 배치도 적절하게 되게끔 마크업을 설계하는 것이 매우 중요하다고 생각이 들었다.

중간중간 CSS 스타일링에 대해 막혔었던 부분도 TIL을 작성하며 정리하니 나중에 찾아보기도 편하고 기억에 오래 남을 것 같다.

댓글 공유

branch

branch란?

분기점을 생성하여 독립적으로 코드를 변경할 수 있도록 도와주는 모델

명령어

1
2
3
4
5
6
7
8
9

$git branch // 로컬 브랜치 확인

$git branch -r // 원격 브랜치 확인

$git branch -a // 둘다 확인

$git branch html-init // 브랜치명 입력하면 브랜치 생성

$git switch 브랜치명 // 브랜치 이동

로컬에서 브랜치 생성한 후 원격 저장소에 push를 해줘야만 github 저장소에 해당 브랜치가 생성된다.

주의사항

• 처음 브랜치를 push 하는 경우에는 -u 플래그를 사용해줘야한다.
  그 이유는 원격 저장소에게 새로만든 브랜치가 main 브랜치와 연관성이 있다라는 것을 의미하기 때문이다.
• 플래그는 맨 앞에 위치하는 것만 아니면 위치는 상관없다.

branch 사용 이유

개발을 할 때, main 브랜치를 두고 개발 브랜치로 소스 코드를 가져와서 원하는 개발을 시도하여도 메인 소스코드에 영향을 주지 않을 수 있어 자유로운 개발을 할 수 있다. 협업에 필수적인 모델이다.

merge

개발 브랜치를 생성한 후 main 브랜치와 합치기 위해서는 merge 작업을 해줘야한다.

1
2

// main
$git merge develop

자신의 역할을 끝낸 즉, merge가 된 브랜치는 바로바로 삭제해준다.

1

$git branch -D develop

merge conflict

만약 main 브랜치와 develop 브랜치에서 같은 파일의 같은 라인을 수정했다면, 컴퓨터는 어떤 것을 선택해야할지 알지 못하므로 그 선택을 우리에게 맡긴다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

<!DOCTYPE html>
<html>
  <<<<<<< HEAD
  <head>
    <meta charset="utf-8" />
    <title>git branch practice on branch main</title>
  </head>
  =======
  <body>
    <h1>homepage</h1>
    <p>This work on branch body-init</p>
  </body>
  >>>>>>> body-init
</html>

이럴 경우 원하는 부분을 선택하여 수정해주고 add, commit을 해주면 된다.

1
2

$git add index.html
$git commit

merge를 할 경우, merge commit이 제목과 내용으로 채워져있다.

주의사항

• commit은 항상 동작하는 단위 (최소단위)여야 한다.
• -m 플래그는 사용하지 말자
• merge conflict가 발생한 경우 commit 내용으로 어떻게 충돌을 해결했는지도 적어주자

gitflow 전략

• Master(Main): 사용자를 위한 배포용 소스코드용

• Hotfix: 갑작스러운 버그를 수정하기 위한 브랜치

• Develop: 개발용 브랜치로, feature 브랜치에서 작업한 것들을 이곳에서 모아서 확인한다.

• Feature: 개발자의 작업 브랜치, add와 commit이 작은 단위로 일어나는 곳

gitflow 전략 사용

1. github 저장소에 repository 생성한 다음 나의 로컬 폴더에 git clone 한다.

2. 저장소와 로컬을 연결했다면 저장소를 초기화해준다.

1

$git flow init

3. feature 브랜치를 생성하고 이동하여 작업을 시작한다.

1

$git flow feature start "브랜치명"

기능이나 최소단위로 작업을 진행한다.

4. 작업이 끝났다면 develop 브랜치와 merge한 뒤 feature 브랜치 삭제

1

$git flow feature finish "브랜치명"

위 명령어로 merge,delete 까지 한번에 해줄 수 있다.

5. 기능 개발 마무리되면 release 사용하여 배포 전 브랜치로 이동한다.

1

$git flow release start "버전" // ex) v0.1

위 작업을 통해 버전 태그를 달아준다.

6. release 브랜치에서 github 저장소의 main 브랜치와 develop 브랜치, tags를 push 해준다.

1
2
3
4
5

$git push origin main

$git push -u origin develop // develop브랜치는 처음 github에 올라가니 -u 플래그 사용

$git push --tags // 한번만 해주면 된다.

7. release 브랜치를 merge + delete 해준다.

1

$git flow release finish "버전"

8. github 저장소에서 tag에 가서 release 해주면 된다.

gitflow 전략을 통한 협업

1. 팀장 또는 단체의 repository에서 fork를 하여 복사본은 나의 github 저장소로 가져온다.
   

2. 앞서 사용한 feature 브랜치를 사용하여 개발을 한 후 fork한 사본 저장소에 push를 한다.

3. PR을 하기전 issue 탭에가서 내가 무슨 작업을 할 것 인지 알려주도록 한다.
   

4. 팀장 또는 단체의 repository에 가서 PR(Pull Request)를 한다.

5. 팀장은 나의 PR을 확인하고 요청에 응답하거나 문제가 있다면 코드리뷰를 하며 PR을 보류한다.
   

6. PR이 열려있는 상태에서 나는 나의 develop 브랜치에 돌아가서 코드를 수정한 뒤 commit을 해주면 다시 팀장이 확인하고 끝내 merge를 한다.

• 이 후 팀장이 develop 브랜치와 main 브랜치를 merge하면 issue가 closed 된다.

주의사항

• PR할 때, 나의 develop 브랜치에서 팀장의 develop 브랜치로 PR을 보내야한다.

소감

gitflow 수업이 끝난 후 1시간 30분 동안 4명이서 소규모 팀프로젝트를 경험해보았는데, 아직 머릿속에서 내가 어떤 상태이고 무엇을 해야하는지 헷갈려서 조금 어수선한 감이 있었다.

그래도 피보나치킨 게임(?)을 만들어서 배포까지 해보니 gitflow 전략을 통한 협업의 장점을 느낄 수 있어서 재밌었다.

튜토리얼처럼 단계별로 코드를 따라 치는 것이 아닌 내가 어떤 단계에 있고 어떤 행동을 해야하는지를 생각하며 개발을 해야한다.

댓글 공유

📌CDN

• Content Delivery Network의 약자
• 지리적으로 분산된 여러 서버가 있고 사용자와 지리적으로 가까운 서버에서 전송하여 전송속도를 높인다.
• ATM기기와 비슷하다고 생각하면 된다.

CDN은 전체 트래픽의 균형을 맞춰 인터넷 컨텐츠에 접속하는 사용자들에게 최고의 웹 경험을 제공한다.

사용이유

20여 년동안 전 세계 사용자들이 빠르고 확장성있게 온라인 콘텐츠를 전송하도록 도와주었다.

만약 CDN을 사용하지 않았더라면 Origin 서버가 data를 복제 및 저장한 후 사용자가 웹에 접속하는 곳까지 컨텐츠를 가져가야하기 때문에 인터넷 속도가 느려질 수 있다.

단점

Origin 서버와 다른 여러 서버가 연결되어 있는데, 이 서버중 한곳에라도 문제가 생길 시 CDN을 사용하는 데에 문제가 발생할 수 있다.

가령 수강생들끼리 axios를 CDN으로 적용하여 페어프로그래밍 진행중 CDN이 먹통이 되어 모두 원하는 코드가 동작하지 않았던 경험이 있다.

🏓 소감

간편하게는 사용하면 좋을 것 같지만 프로젝트를 하거나 안정성이 요구되는 상황에서는 CDN을 지양하는 것이 좋겠다.

댓글 공유

기술면접 후기

제로베이스 커넥to 스쿨에 들어온지 4주차에 접어들었다.

데레사 강사님의 HTML/CSS 수업을 들으며 정신없이 과제도 하며 나름 수업 복습도 열심히 하면서 지내왔다고 생각했다.

면접은 항상 준비가 되어있든 되어 있지 않든 긴장감이 있기 마련이다.

하지만 이번 기술면접은 다른 면접과는 다르게 더욱 긴장되었다.

그 이유는 거의 한달동안 배웠던 수업 내용에 대해 (자바스크립트 질문도 많았지만,) 면접관에게 직접 설명을 해야했고,

그 과정에서 나를 어필할 수 있는 방법을 써서 설명을 해야하는 부분 때문에 더욱 부담스럽게 느껴졌다.

면접은 20분간 진행되기로 예정되었지만 긴장을 하여 말이 빨라지니 13분만에 끝마쳤다.

나름 면접관에게 돋보이기 위해 제스쳐도 크게 하려하고 아이컨택도 많이 하려고 했다.

하지만 개념에 대해 명확하게 알고 있지 않았고 명확히 알고 있는 개념도 누군가에게 말로 설명을 해보지 않았는데,

실제로 말로 해보려하니 머릿속에서 정리되지 않아 논리적이지 않은 사람으로 보였다.

피드백

1. 면접관의 흥미를 유발하라

오늘 면접관님의 태도는 매우 좋았다. 내가 무슨 말을 하는지 귀담아 들으려 노력해주시고 아이컨택도 계속 해주셨다.

하지만 실제 면접장에서 면접관들은 지원자의 말을 귀담아 듣지 않는다.

나라는 존재를 수많은 지원자 중에 1명으로 보여지게 하고 싶지 않다면, 그들의 흥미를 유발할 수 있는 어조, 제스쳐, 스토리 등으로 나를 어필해야 한다.

예를 들어, 클로져에 대해 아는대로 설명해보세요 라는 질문을 받았다면 다음과 같이 답변해보자.

제가 클로저라는 부분을 처음 접했을 때, 왜 자바스크립트에서만 이런 개념이 생겨나는지 궁금해서 찾아보았다. 그 이유 자바스크립트에서는 public 개념과 private 개념이 없기 때문이라는 것을 알게 되었다. 하지만 현재는 클래스라는 개념이 생겨나 이런 부분을 해결할 수 있었다. 저는 이 부분을 사용하여 이런 부분을 개선해보도록 노력해본 경험이 있습니다.

위와 같이 스토리를 풀어서 설명하면 면접관의 흥미를 유발할 수 있을 것이다.

2. 말로 안되면 그려서라도 설명하라

프로그래밍 개념은 말로만 전달하기 어려운 개념들이 많이 존재한다.

내가 만약 조리있게 말하지 못할 것 같은 질문이 나왔다면, 면접관에게 양해를 구한 후 그림을 그려서라도 설명을 해보자

이 때, 주의해야할 점이 그림을 다 그린 후 머릿속에서 어떻게 설명할지 정리한 다음에 설명을 이어가자.

면접장에 가면 마음이 조급해져서 위와 같은 상황에서 그림도 이해할 수 없을 정도로 대충 그리고 그 상태에서 말을 진행하게 된다.

이렇게 되면 그림을 그릴 시간을 달라한 이유가 없다.

3. 모르는 것은 모른다라고 확실히 말하자

아는 척하여 무엇 무엇 일 것 같다.. 라는 식의 답변은 최악이다.

모르는 질문이 나왔다면 모른다고 답변하자. 다만, 여기서 태도의 차이가 분명하게 나타날 수 있다.

누군가는 그 질문에 대해 모른다고 답변하고 끝날지라도, 누군가는 그 질문과 연관된 다른 내용을 설명해도 되겠냐는 양해를 구한다.

두명의 지원자를 비교해보았을 때, 당신이라면 누구를 더 선호할 것인가?

소감

아침부터 프로젝트도 준비해야하고 기술면접도 준비해야해서 머리도 복잡해지고 힘든 하루가 지나갔다.

그래도 기술면접을 직접 경험해봄으로써 실제 면접장의 압박감과 내가 어떤 부분에서 부족하게 보였는지를 알게되어

그 부분을 고쳐나가면 면접을 즐길 수 있게 될 것 같다.

나를 죽이지 못하는 고통은 나를 더 성장하게 만든다.

댓글 공유