패스트캠퍼스X야놀자 프론트엔드 개발 부트캠프_HTML/CSS 과제 리팩토링

작성일 In Views: Disqus:

과제를 진행하며 느낀점

지금까지 배웠던 것들을 전부 사용해서 많은 것을 해보고 싶었는데 막상 구현에 들어가니 막히는 것이 많았다.
막힐 때마다 구글링을 통해 확인하고 여러 시행착오를 거치게 되고, 계획했던 그날의 계획들이 모조리 깨지는 것을 보면서 단순 강의를 보고 배우는 것과 실제로 내가 고민하고 코드를 작성하는 것이 얼마나 차이가 큰지 새삼 느끼게 되었다.

Sass를 사용하면서 mixin을 실제로 써보니 어떤 코드까지를 중복으로 판단해야 할지 몰라서 고민하며 시간을 보내기도 했고, html의 접근성을 공부하고 적용하기 위해 코드를 짤 때 항상 생각하고 작성했지만 실제 자동 감사 도구에서는 안좋은 점수를 맞기도 했다.

또한 sprite-image의 활용이나 기획에 기반한 style 작성 등 초기에 계획했던 것들과 실제 내가 행한 5일은 많은 차이가 있었다. sprite-image는 이해가 부족하여 충분히 활용하지 못했고, Media Query 같은 경우에도 처음 기획한 코드 구성과 거리가 너무 멀었다. 시간에 쫓기고 시행착오를 반복하다 보니 마음이 급해졌고, 코드 또한 기획가 달리 점점 난잡해져갔다.

의외로 시간을 많이 소모하게 된 것이 디렉터리 구조나 한/영 font-face 구별과 같은 초기 세팅 관련한 부분이었는데, 처음엔 고생했지만, 다음 개발 시에는 훨씬 수월하게 할 수 있겠다는 자신감을 얻을 수 있었다.

결국 기획에서 중요한건 경험이고, 그것을 기반으로 좀더 현실적이고 완전하게 계획을 세워 코드 작성을 진행하는 것을 목표로 더욱 열심히 해나가야겠다.

멘토님의 코드리뷰

이번 개발에서 배웠던 기초에 더해 스스로 고민하고 찾아보면서 적용시킨 부분들이 있었다. 렌더링 성능에 대한 고민들이나 웹 접근성에서 스크린리더 사용자들을 최대한 고려한 코드를 작성한 것이 그것이다. 아직 초보자의 수박 겉핥기에 불과하겠지만, 멘토님은 그러한 고민을 한 것 자체에 대해 좋은 말씀을 해주셨다.

추가로 코드에서 개선할 점들을 짚어주셨다.

1) 유지보수성을 생각하여 모달창의 마크업 위치를 변경

페이지에 사용되는 공통 모달 배경은 추후 유지보수면에서 문서 상단에 위치시키면 추후 유지보수에 유리하다고 하셨다. 모달의 마크업을 쉽게 찾아갈 수 있을지에 대해 생각해본적이 없었는데 좋은 방향을 알게되었고, 바로 코드에 적용했다.

2) 중복되는 코드를 함수로 분리

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
// 기존 코드
$prev.addEventListener('click', e => {
  if (section2Order === 0) section2Order = 0;
  else section2Order = section2Order - 1;

  const innerWidth = window.innerWidth;
  const widthBase = innerWidth < 1200 ? window.innerWidth : 1200;
  const moveWidth = widthBase === 1200 ? `${(section2Order * widthBase) / 10}rem` : '100vw';

  // console.log(section2Order, widthBase, moveWidth);

  document.querySelector('.section2__container__flex').style.transform = `translate(-${moveWidth})`;
});

$next.addEventListener('click', e => {
  if (section2Order === 6) section2Order = 0;
  else section2Order = section2Order + 1;

  const innerWidth = window.innerWidth;
  const widthBase = innerWidth < 1200 ? window.innerWidth : 1200;
  const moveWidth = widthBase === 1200 ? `${(section2Order * widthBase) / 10}rem` : '100vw';

  // console.log(section2Order, widthBase, moveWidth);

  document.querySelector('.section2__container__flex').style.transform = `translate(-${moveWidth})`;
});

코드의 가독성이 나쁜 것도 짚어주셨는데 중복되는 코드들은 함수로 빼내어 관리하는 것을 권장하셨다. 기존 코드를 보면, 이벤트 리스너에서 코드가 반복되는 것을 볼 수 있는데, 이러한 경우 섹션이동 동작을 제어하는 함수로 분리하여 관리하고 함수가 어떻게 동작할지에 대한 값을 인수로 넘겨주게 만들었다. 실제로 반복되는 코드가 사라져 가독성이 높아졌고, 유지보수면에서 하나의 함수만을 수정하면 되기 때문에 훨씬 좋아보였다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// 리팩토링 코드
const moveSection = increment => {
  section2Order = increment ? Math.min(section2Order + 1, 6) : Math.max(section2Order - 1, 0);

  const innerWidth = window.innerWidth;
  const widthBase = innerWidth < 1200 ? innerWidth : 1200;
  const moveWidth = widthBase === 1200 ? `${(section2Order * widthBase) / 10}rem` : '100vw';

  document.querySelector('.section2__container__flex').style.transform = `translate(-${moveWidth})`;
};

$prev.addEventListener('click', e => {
  moveSection(false);
});

$next.addEventListener('click', e => {
  moveSection(false);
});

3) 웹성능을 최적화할 수 있는 코드를 작성

ascript에서 변수에 DOM요소를 할당할 때 내 코드에서는 querySelector를 사용했다. 하지만 멘토님께서는 성능상으로는 getElementById가 좋다고 하시며 페이지가 많아질 수록 성능 차이가 심해질 것이라고 하셨다. 당장 지금의 프로젝트에서는 페이지의 수가 한정되어 있기 때문에 큰 차이가 없으므로 리팩토링할 필요는 없지만 추후 프로젝트에서 웹성능을 감안한다면 querySelector보다는 id를 지정하여 getElementById를 사용하는 쪽으로 코드를 작성해야겠다.

사실 DOM요소를 불러오는 방법에 대해 처음 듣는 이야기는 아니었다. getElementById가 더 성능이 좋다는 것도 알고있었다. 그러나 querySelector가 보다 성능은 낮지만 jquery보다는 성능이 좋다는 것을 알고있었고, jquery로도 복잡한 사이트들을 현업에서 구현하는데 querySelector로 복잡하지 않게 그냥 통일해서 사용하면 안될까? 라는 마음이 있었던 것 같다.

그러나 확실히 웹성능 면에서 개선된 방식으로 코드를 작성하는 습관을 들이는 것이 좋다는 말씀에는 동의한다. 다음 프로젝트 개발시에는 id를 읽어오는 쪽으로 작성하겠다.

Lighthouse

Lighthouse를 통해 구현한 사이트를 검사해본 결과 예상 외로 웹 접근성 측면에서 기대보다 낮은 점수를 받았다. 솔직히 좀 충격이었다. 이번 과제에서 접근성을 지키기 위해 WCAG2.1을 읽고 accessibility hidden style이나 WAI-ARIA 등의 활용으로 스크린리더 환경까지 고려했기 때문이다.

그러나 예상치 못한 부분에서 접근성을 지키지 못한 경우들이 있었다. 바로 버튼이나 링크등에 이미지를 직접적으로 삽입하고 텍스트를 입력하지 않았을 때의 문제였다.

Lighthouse를 통해 알게 된 웹 접근성의 취약점들을 개선하려 노력했다. 추가로 성능 면에서도 내가 개선이 가능한 부분들을 찾아내어 수정했다.

1) 웹 접근성 취약점 개선

텍스트가 없는 버튼을 디자인적 요소로 활용하여 링크를 연결한 것에 대한 지적이 있었다. 스크린리더 사용자의 입장에서 이러한 디자인적인 요소를 파악할 수 없는데, 파악할 수 없는 요소에 중요한 링크가 걸려있으니 문제가 있었다. WCAG2.1에서 의도적으로 스크린리더 사용자에게 정보를 전달하는 기능인 aria-label 속성을 확인하고 적용하였다.

1
2
3
// aria-label 적용
<a href="/" class="content-box-arrow" aria-label="해당 페이지로 이동">
  <i class="fa-solid fa-arrow-right"></i>
1
2
3
4
5
6
// aria-label 적용
<div class="carousel-btns">
  <button type="button" class="carousel-btns-item active" data-num="1" aria-label="첫 번째 이미지로 이동"></button>
  <button type="button" class="carousel-btns-item" data-num="2" aria-label="두 번째 이미지로 이동"></button>
  <button type="button" class="carousel-btns-item" data-num="3" aria-label="세 번째 이미지로 이동"></button>
</div>

2) 웹 성능 개선

사이트에서 애니메이션과 이미지들이 많이 사용되다 보니 성능적으로 많이 낮은 점수가 나오는 것 같았다. 우선적으로 코드 등의 수정 보다는 이미지 파일 자체의 크기들을 낮추는 것에 집중하였다.

이미지 최적화 프로그램을 통해 각 이미지들의 크기를 30% ~ 50% 낮춰주었고 유의미한 검사 결과의 차이를 얻었다. 추가로 Lazy Loding과 CDN을 활용한 이미지 최적화 방법들을 알게 되었는데 추후에 웹성능 개선을 위한 이미지 최적화 방식에 대해 제대로 알아보고 활용할 수 있게 하겠다고 다짐했다.

Lighthouse 점수 변화