서론
이번 일자 서론은 생략이다...! 분량이 많은 관계로 어서 써야하기 때문이다.
이번 일자의 프로그래머스 데브코스는 Tech Spec 및 프로젝트 세팅이다.
기술 설명서 (Tech Spec)
Tech Flow
기술적인 Flow는 다음과 같은 다섯 가지 단계로 나눌 수 있다.
- 서비스에 접근한다.
- 유저가 액션을 하면, 서비스는 액션을 입력받는다.
- 입력받은 데이터를 서버에 저장한다.
- 현재 자산을 서버로부터 받아온다.
- 서버로부터 받은 자산 데이터를 화면에 보여준다.
이러한 내용을 상세하게 설명하도록 하겠다.
(1) 서비스에 접근
서비스에 접근한다.
- 구현 목표: 유저가 브라우저에서 화면을 확인할 수 있도록 한다.
- 필요
- 유저가 브라우저에 접근한다.
- 유저가 확인할 수 있는 화면이 그려진다.
- Tech Flow
- 1. 브라우저를 사용하여 서비스 URL에 접속한다.
- 2. 서비스에 필요한 파일을 load한다.
- 3. load한 파일들을 활용하여 화면을 그린다.
(2) 서비스가 유저 액션을 입력
유저가 액션을 하면, 서비스는 액션을 입력받는다.
- 구현 목표: 유저의 액션을 서비스에서 입력받는다.
- 필요
- 유저가 액션할 수 있는 UI
- 유저의 액션을 입력받을 수 있도록 준비
- Tech Flow
- 1. input UI에 키보드로 숫자를 입력한다.
- 2. input에 등록된 이벤트가 실행된다.
- 3. 입력 데이터를 브라우저에서 확인할 수 있다.
(3) 입력 데이터를 서버에 저장
입력받은 데이터를 서버에 저장한다.
- 구현 목표: 유저에게 입력받은 데이터를 서버에 저장한다.
- 필요
- 서버
- 서버-브라우저간 통신 (API)
- Tech Flow
- 1. 유저가 버튼을 클릭한다.
- 2. 버튼에 등록된 서버 전송 이벤트가 발생한다.
- 3. API를 통해 서버에 데이터 저장을 요청한다.
- 4. 서버는 요청사항이 완료되면, 브라우저에게 알려준다.
(4) 현 자산을 서버로부터 받기
현재 자산을 서버로부터 받아온다.
- 구현 목표: 현재 자산 데이터를 서버로부터 받아온다.
- 필요
- 서버
- 서버-브라우저간 통신 (API)
- Tech Flow
- 1. API를 통해 서버에 데이터 조회를 요청한다.
- 2. 서버에서 데이터를 응답해준다.
(5) 받은 데이터를 화면에 출력
서버로부터 받은 자산 데이터를 화면에 보여준다.
- 구현 목표: 서버로부터 응답받은 데이터를 화면에 보여준다.
- 필요
- 서버로부터 응답받은 데이터
- 응답 데이터를 유저가 보기 쉽게 처리하는 로직
- 유저가 확인할 수 있는 화면을 그리기
- Tech Flow
- 1. 응답 데이터를 유저가 보기 쉽게 처리한다.
- 2. 처리된 데이터를 화면에 다시 보여준다.
3가지 레이어
위의 5가지 과정을 통해 웹 / 유저 / 서버. 즉, 3곳의 개체 간의 상호작용이 이뤄진다는 걸 알 수 있다.
- 1. 웹 ▶ 유저: 화면을 보여준다. (렌더링 담당 레이어)
- 2. 웹 ◀ 유저: 액션 입력 받을 수 있도록 한다. (이벤트 등록 및 처리 레이어)
- 3. 웹 ▶ 서버: 데이터 조회 / 저장 / 수정을 요청한다. (서버 요청 수행 및 응답 담당 레이어)
- 3. (추가) 웹 ◀ 서버: 요청사항에 대한 응답을 받는다.
이러한 상호작용을 '인터렉션'이라고 한다.
렌더링
렌더링은 크게 2가지로 나뉜다.
- 기본 렌더링
- HTML 파일에 문서를 작성
- 최초 파일이 로드될 때, 브라우저에 의해 HTML을 읽어, 화면이 그리게 됨
- 런타임 때 렌더링
- 런타임 때 자바스크립트로 렌더링을 조작
- 액션이 있을 때 UI를 변경해야하는 케이스
(1) HTML을 통한 렌더링
아래에서는 HTML 파일, CSS 파일, DOM의 개념에 대해서 다룬다.
- HTML
- Hyper Text Markup Language의 약자
- 웹페이지와 웹사이트의 구조를 구성하는 코드 (마크업)
- 웹을 로드할 때 처음에 로드하는 파일
- <div>어쩌구저쩌구</div>
- CSS
- Cascading Style Sheet의 약자
- 마크업 언어가 실제로 표시되는 방법을 기술하는 스타일 언어
- 선택자 { ... }
- DOM
- Document Object Model의 약자
- HTML 문서와 상호 작용할 수 있는 인터페이스
- Node와 Object로 문서를 표현
- 트리 구조: 부모-자식의 관계가 형성됨
- 렌더링 과정
- 1. HTML 마크업 파싱 - DOM 트리 구축 (Document Object Model)
- 2. CSS 마크업 파싱 - CSSOM 트리 빌드 (CSS Object Model)
- 3. DOM과 CSSOM을 결합하여 렌더링 트리 형성
- 4. 렌더트리 배치
- 5) 렌더트리 페인팅
참고로 파싱은 읽어들이는 과정을 뜻한다.
2) 런타임때 렌더링 조작
- triggering이 있을 때 UI를 변경해야하는 케이스
- 런타임때 자바스크립트로 DOM을 조작하여 렌더링
- 리렌더링 - 리페인팅, 재배치 발생
- 런타임 때 화면 조작
- 1. 자바스크립트로 DOM 노드 선택
- 2. 노드 조작
- 선택한 노드에 새로운 노드 추가
- 선택한 노드 수정/삭제
- Document 인터페이스를 통해 접근
- DOM 노드를 선택하기 위한 방법
- document.querySelector(선택자)
- document.querySelector(".classNAME")
- document.querySelector("#idNAME")
- querySelector, querySelectorAll, getElementById...
- 노드 생성
- document.createElement(태그명)
- 노드 추가
- Node.appendChild(Node)
이벤트
- 유저가 클릭을 했을 때, 함수를 실행시키고 싶다면?
- 목표: 유저가 클릭을 했다는 사실을 자바스크립트에서 catch해야 한다.
따라서 이벤트 catch가 필요하다. - 유저가 행동하기 전에, 미리 요소에 이벤트를 받을 수 있도록 수신기 등록 필요.
e.g. 클릭 이벤트를 받을 준비
- 목표: 유저가 클릭을 했다는 사실을 자바스크립트에서 catch해야 한다.
- EventTarget 객체
- 이벤트의 대상이 되는 객체가 EventTarget 객체를 구현
- document, window...
- 이벤트를 수신할 수 있는 수신기를 가질 수 있음 (listener)
- 이벤트의 대상이 되는 객체가 EventTarget 객체를 구현
- 이벤트 유형
- 유저와의 상호 작용, 기본환경 상태의 변화...
- click, focus(input), blur(input)...
- addEventListener
- Node.addEventListener(이벤트 유형, 콜백 함수)
- 요소를 생성할 때, 이벤트 리스너도 함께 등록
- 요소에 수신기를 등록하는 역할을 함. 즉, 이벤트를 받을 수 있도록 하는 것.
서버간 통신
- 서버와의 통신
- 데이터 조작을 위해 클라이언트-서버와의 통신이 필요함
- 서버 통신에는 물리적인 시간 지연이 발생
- 요청과 동시에 바로 처리하는 것은 불가능
- 요청 이후 응답이 오기까지 기다렸다가, 응답 신호를 받아야함
- 자바스크립트는 이러한 상황에 필요한 처리기가 존재
- 콜백 패턴
- Promise 객체
- async - await
- Promise
- 미래의 어떤 시점에 결과를 제공하겠다는 약속을 의미하는 이름의 Promise 객체를 제공
- Promise 객체의 3가지 상태
- 대기 pending: 수행 중...
- 이행 fulfilled: 수행이 성공적으로 완료
- 거부 rejected: 수행이 실패
- 메서드:
- then: fulfilled 일 경우
- catch: rejected 일 경우
- 동기와 비동기
- 동기: Synchronous
- 직렬적으로 작업을 수행하는 방식
- 요청 이후, 응답을 받아야지 다음 동작이 이루어지는 방식
- 비동기: Asynchronous
- 병렬적으로 작업을 수행하는 방식
- 요청 이후, 응답 수락 여부와 상관없이 다음 작업이 동작하는 방식
- 동기: Synchronous
- async - await
- 비동기 처리 패턴 중 하나
- Promise 단점을 보완. 가독성을 높임
- 함수에 async 키워드를 붙여, Promise 인스턴스를 반환하도록 함
- await를 Promise 인스턴스 앞에 추가하여, 성공 처리 이후에 다음 함수 명령문이 실행되도록 함
프론트엔드 개발자의 책임
- 구현) 빠르고 생산적으로 기능을 구현
- 자동화) 개발 속도를 낮춘다면 빠르게 개발할 수 있도록 자동화 및 개편
- 책임 분담) 다른 개발 소스의 활용
- 적용) 빠르게 서비스에 적용
- 지속적 통합 배포: 개발 단계 -> 배포 단계
- 개발 단계: 개발을 생산적으로 빠르게 진행해야 함
- 배포 단계: 파일을 서버에 업로드
- 사이클이 반복적, 최적화된 상태로 이뤄질 수 있도록 세팅이 필요
- 지속적 통합 배포: 개발 단계 -> 배포 단계
- 협업) 작업 생산성 올리기
- git 등을 이용
- 코드를 빠르게 이해하여 정확히 수정할 수 있도록 하기
- 코드의 가독성 올리기
읽기 좋은 코드
기본적으로 개발은 함께 협업하는 것이고, 함께 코드를 작성하기 때문에 읽기 좋은 문서의 형태로 유지해야 한다. 그렇기에 다른 사람이 구현한 코드여도 빠르게 이해할 수 있도록 한다.
- 1. 코드의 구조를 빠르게 파악하도록 돕기
- 관심사를 분리하기 (목표: 테스터블한 모듈)
- 2. 코드 생산을 줄이기
- 코드의 재사용성을 높이기
- 레거시 코드가 많지 않도록 꾸준히 관리하기
- 3. 코드를 통일화하여 가독성 올리기
- 코드 포매팅: 일관도 코드 스타일 유지
- 네이밍 규칙
- 4. 컨텍스트 이해를 빠르게 돕기
- 주석
관련 내용은 책 클린 코드를 참고하는 것이 좋을 것 같다. (다만, 클린 코드는 너무 맹신하면 오히려 역효과가 난다는 말을 어디서 들었던 것 같다. 읽을 거면 제대로 읽는 게 좋아보인다.)
프로젝트 세팅
npm
다른 사람이 만든 코드 패키지를 사용하여 프로젝트 작업의 시간을 단축할 수 있다. 다만, 패키지들의 설치 및 관리가 필요하다.
노드 패키지 매니저라는 것도 존재하는데, 이건 node.js의 패키지 관리자이다. 모듈 설치를 관리해주는 역할을 한다. 버전 관리, 코드 종속성 관리 등등 말이다.
Saas
SaaS는 스타일링용 pre-processor이다. 번역하자면 CSS 전처리기이다. CSS의 한계와 단점을 보완하는 전처리기이다. 가독성을 높이고 코드의 재사용에 유리한 CSS를 생성하기 위한 확장이다.
번들러
의존성 있는 모듈 코드를 하나의 파일로 만들어주는 도구가 번들러이다.
대표적인 번들러로는 webpack, vite, parcel 등이 있다.
Git
여러 명의 유저 간에 파일들의 작업을 조율하기 위한 버전관리 시스템이다.
Github
깃 저장소 호스팅 웹서비스이다. 보안에 주의할 필요가 있다.
Error: EPERM: operation not permitted
파일명 좀 바꾸려는데 vs code에 오류가 났다. npm 오류 같은데, 어쨌거나 수정해야 해서 이것저것 방법을 찾아봤다.
1. 관리자 권한으로 VS Code를 실행시킨다.
- 슬프게도 해당 방법은 잘 안 되었다.
2. 터미널에 npm cache verify를 입력한다.
- 슬프게도 해당 방법도 잘 안 되었다.
3. 터미널에 npm cache clean를 입력한다.
되나 싶었으나 여전히 안 되었다.
3. 터미널에 npm cache clean --force를 입력한다.
에라 모르겠다 식으로 했으나, 안 되는 건 매한가지였다.
4. 복잡한 과정을 거친다.
1) vs code를 닫는다.
2) 윈도우 터미널 혹은 파워셸을 관리자 권한으로 연다.
3) npm 캐시를 강제로 제거한다. (npm cache clean --force)
4) npm을 강제로 업데이트 한다. (npm install -g npm@latest --force)
5) npm 캐시를 '다시' 강제로 제거한다. (npm cache clean --force)
6) vs code를 새로 열어서 실행시킨다.
그제야 작동을 했다. 이거 하나 때문에 대체 시간을 얼마나 날린 것인지 모르겠다... 😭
사족
오늘은 개발에 앞서 주의해야 할 부분들, 개발에 앞서 어떤 과정을 거쳐야 하는지를 배운 것 같다. 학교에서도 관련한 내용을 배웠었는데, 당시 배운 것은 언제까지나 학부생 수준이라서 그런지 지금과는 조금 달랐다. 이런저런 차이를 느끼며 개발 공부를 해나가는 것도 나름 재미있는 것 같다.
그리고 프로그래밍적인 오류가 아닌, 개발 환경이나 시스템적인 오류는 언제나 힘들다. 프로그래밍은 고치기라도 하면 되지 이건 뭐 잘못하면 시간만 왕창 빼앗기는 느낌이다. 😣
'💻 종합 개발 주제 > 📚 웹앱 데브코스' 카테고리의 다른 글
14일차 데브코스 - 클라우딩 어플리케이션 엔지니어링 TIL (0) | 2024.01.19 |
---|---|
12일차 데브코스 - 클라우딩 어플리케이션 엔지니어링 TIL (0) | 2024.01.17 |
11일차 데브코스 pt.3 - 클라우딩 어플리케이션 엔지니어링 TIL (3) | 2024.01.13 |
11일차 데브코스 pt.2 - 클라우딩 어플리케이션 엔지니어링 TIL (0) | 2024.01.12 |
11일차 데브코스 pt.1 - 클라우딩 어플리케이션 엔지니어링 TIL (2) | 2024.01.11 |