개발일지 (2월 회고)

 

 

 

좋은 웹 개발자란 무엇인가

 

굉장히 주관적이고 추상적인 질문이지만, 이에 대해 지극히 주관적이고 추상적인 대답들을 통해서 조금씩 구체화시켜 나갈 수 있었다. 좋은 웹 개발자란 당연히 좋은 웹을 설계하고 만드는 개발자일 것이다. 좋은 웹이라는 것은 웹 페이지를 방문하는 유저(User)에게 좋은 사용자 경험(UX)를 제공하는 웹일 것이고, 그렇다면 좋은 웹 개발자는 이 UX의 중요성을 이해하고 웹 페이지를 제작하는 개발자일 것이다

 

UX를 결정하는 요인은 무엇일까?

웹 페이지가 이 페이지를 방문하는 사용자에게 좋은 경험을 제공하기 위해서는 다음과 같은 것들이 고려되어야 한다고 생각했다.

 

• 로딩이 빨라야 한다. 느린 페이지를 원하는 사람은 아무도 없다
• 페이지를 그리기 위해 데이터 리소스를 적게 사용하고 싶어한다. (특히 낮은 요금제를 쓰는 학생들의 경우 더 그렇다)
• 페이지가 직관적이어야 한다. 닫기 버튼을 눌렀는데 결제가 된다면 누가 그 페이지를 사용하려 하겠는가
• 누가 이 페이지를 사용할 수 있는가가 고려되어야 한다. (스크린리더를 통해서 홈페이지를 접근하는 이들도 있으며, 빨간색과 초록색을 구분하지 못하는 이들도 있다. 이들이 사용할 수 있는 페이지인가?)
• 어떤 환경에서 이 페이지를 사용할 수 있는가가 고려되어야 한다. (아직도 인터넷 익스플로러를 사용하는 사용자도 있고, 인터넷이 굉장히 느린 곳에서 접근하는 사용자들도 있다. 이들을 위한 배려가 마련되어 있는가?

 

이런 사항들을 고려하면서 웹 개발을 하기 위해서는 알아야 할 것들이 생각보다 많은 것 같다는 생각이 들었다. 

 

• 로딩을 빠르게 하기 위해서는 자바스크립트에 대해서 제대로 알아야 한다. 또한 자바스크립트 기반 웹 프레임워크(React, Angular, Vue 등)에 대한 지식들도 있어야 하며, 이들이 각각의 컴포넌트들을 어떤 방식으로 렌더링하는지, 렌더링을 최적화하기 위해서 어떤 방식을 선택해야 하는지를 알아야 한다.
• 또한 기본적인 자료구조와 Computer Science에 대한 지식이 있어야 한다. 프로세스는 무엇이며, 쓰레드는 무엇인지, OS는 무슨 역할을 하는지 등등에 대한 지식들 의미한다. (굉장히 추상적인 것 같긴 하다)
• 브라우저가 어떻게 동작하는지를 알아야 한다. 주소창에 URL을 입력했을 때 어떤 과정을 통해서 브라우저에 페이지가 나타나는지, 비동기 이벤트가 발생했을 때 이를 어떻게 처리하는지, 그리고 한번에 몇개의 HTTP 통신을 통해 데이터를 가져올 수 있는지등을 알고 있어야 한다.
• 로딩을 빠르게 하기 위해서는 또한 다운로드해야 하는 리소스의 용량을 줄여야 한다. 이에 대응하기 위해서는 파일 포맷, 트랜스코딩, 경량화에 대한 내용들을 알고 있어야 하며, 웹팩, babel등의 설정들을 통해 빌드 최적화를 하는 방안에 대해서도 알고 있어야 한다.
• HTML, CSS에 대한 내용들을 잘 숙지하고 있어야 한다. 특히 Semantic HTML에 대한 개념을 아는 것이 중요한데, 이는 프로그램의 유지보수 뿐 아니라 스크린리더 등의 보조기기가 이해할 수 있는 페이지를 제작해야 하기 때문이다. 또한 각각의 HTML Tag들은 무슨 역할을 하며, 무슨 의미를 지니는지, 각각의 CSS Selector들과 Property는 무슨 의미를 가지고 있는지를 알고 있어야 한다.
• DOM 모델에 대한 의미를 이해하고 있어야 한다.
• 비동기 통신 (AJAX)에 대해 이해하고 있어야 한다. 더불어 HTTP와 기본적인 웹 서버에 대한 내용들도 이해하고 있어야 한다.
• API서버와 Database에 대한 이해가 있어야 한다.
• 커져가는 프로젝트를 유지보수하기 쉽게 만들기 위해 아키텍쳐에 대한 이해가 필요하다.
• Etc...

결국 좋은 웹 개발자가 되기 위해서는 좋은 UX를 갖는 웹 페이지를 설계할 수 있어야 하는데, 이를 위해서는 수많은 요소들이 필요하며, 이들이 상호작용하고, 계속해서 발전해가는 과정들을 이해하고 있어야 한다. 수능 시험을 볼 때 마지막 한 문제를 풀기 위해서 12년동안 공부했던 모든 수학 개념들을 합쳐야 하듯이, 좋은 웹 프로그램을 만드는 과정도 이에 도달하는 과정이 아닌가 싶은 생각이 들었다.

 

Overview

 

• Safari의 경우 window 객체에서 기본적으로 제공하는 메소드인 'scrollTo'에서 scroll behavior 'smooth'가 제대로 적용되지 않는 이슈가 있다. 따라서 이는 polyfill을 추가하여 처리해주어야 한다. 
  
  다행히 npm에서 smoothscroll-polyfill을 제공하고 있어서 이를 package에 추가한 다음, import하여 처리하였다.
  
  
  
• Safari는 브라우저 자체에서 제공하는 스크롤의 독특한 특성으로 인해, 스크롤 처리가 다른 브라우저와 조금 다른데, 흔히 나타나는 현상 중의 하나가 'rubber band effect' 였다. 
  
  page의 bottom에 fixed position의 버튼을 하나 누르고 이 버튼을 누르면 화면 제일 아래로 부드럽게 스크롤되도록 구현하는 것이 목적이었다. 하지만 rubber band effect로 인해 스크롤이 되다가 다시 튕겨서 원래 자리로 돌아오는 버그같은 현상이 발생했다.
  
  이는 'webkit-overflow-scrolling' 속성을 'touch'로 변경하여 해결할 수 있었다.
  
  
• base64 인코딩
  클라이언트 사이드에서 웹뷰를 열 때, 쿼리 파라미터로 객체를 넘겨야 하는 경우가 있어서 이 부분을 매끄럽게 처리하기 위해 객체를 base64 인코딩한 형식으로 전달하게 되었다. url 주소등 제한된 Character set만을 지원하는 곳에서는 모든 문자들(공백, 특수문자 등)을 처리할 수 없기 때문에, Charcter Set을 통일하기 위해 고안된 방법이 base64인코딩이다. 따라서 객체를 인코딩함으로써 주소창을 통해 전달해도 정보의 손실이 발생하지 않는다.
  
  
• PPI: Pixel per Inch로 화질과 직접적으로 연관이 있는 수치를 의미한다. 흔히 해상도를 가지고 화질을 평가하곤 하는데, 해상도는 전체 픽셀의 개수를 의미하지만, 화면의 크기에 따라 동일한 픽셀수라도 해상도의 차이가 있을 수 있기 때문에 특정 면적 안에 들어가는 픽셀수를 가지고 해상도를 평가하게 된다.
  
  모바일은 화면의 크기가 작지만, 데스크톱에 비해 인치당 픽셀수(PPI)가 높은 편이므로 데스크탑보다 높은 품질의 png(3x)가 필요하다. 
  
  
  
• git --no-ff option: ff란 fast-forward를 의미한다. 
  fast-forward란 하나의 브랜치의 커밋 히스토리가 다른 브랜치의 커밋 히스토리를 모두 포함하는 경우를 의미한다. 이 경우 두 브랜치는 특별한 머지 커밋 없이 머지될 수 있다. 하지만 --no-ff 옵션을 사용하면 fast-forward 브랜치인 경우에도 머지 커밋을 생성한다.
• CSS
• 의사 클래스(Pseudo-Class): 요소의 특정 상태에 스타일을 적용할 때 사용한다. (e.g :hover, :checked, :visited)
• 의사 요소(Pseudo-Element): 요소의 특정 부분에만 스타일을 입힐 수 있다. (e.g ::first-element)
  
  
  useLayoutEffect: 화면이 그려지기 전에 동기적으로 실행되는 로직
•  컴포넌트 렌더링
• useLayoutEffect 실행
•  화면 update
  
  
  useEffect는 화면이 그려진 이후에 비동기적으로 실행되므로 다음과 같은 순서를 따른다
• 컴포넌트 렌더링
• 화면 update
• useEffect

 

www.npmjs.com/package/smoothscroll-polyfill

smoothscroll-polyfill