.jpg)
TypeScript 기본기 다지기
Table of Content
0. IDE
통합 개발 환경(IDE)이란?
•
IDE(Integrated Development Environment)는 프로그래머가 소프트웨어를 개발 할 때 사용하는 소프트웨어 애플리케이션
•
코딩, 디버그, 컴파일, 배포 등 프로그램 개발에 관련된 모든 작업을 하나의 프로그램 안에서 처리하는 환경
어떤 IDE를 사용해야 하는가?
•
2024 IDE 사용률 통계로 살펴보는 현황
•
개발 언어에 따라 특화된 툴이 있기도 하며, 최근에는 전반적으로 기능을 제공하기 위한 플러그인도 개발되며 점점 개성으로 변하고 있음
•
그 경계가 흐릿한 만큼 유료인 것과 무료인 것에서 사용률에 큰 차이가 있을 수 있음
1. Git
Git이란?
•
Git은 분산 버전 관리 시스템(DVCS)으로, 소스 코드의 변경 이력을 관리하고 여러 개발자 간의 협업을 용이하게 해주는 도구
◦
모든 개발자가 자신의 로컬 저장소에서 작업할 수 있도록 하며, 중앙 서버에 의존하지 않음
◦
각 개발자는 전체 프로젝트의 히스토리를 로컬에 저장하고, 필요할 때 중앙 저장소와 동기화
◦
파일의 변경 이력을 기록하여, 이전 버전으로 쉽게 되돌릴 수 있음
◦
브랜치(분기)를 쉽게 생성하고 관리할 수 있어, 여러 개발자가 동시에 작업할 수 있음
◦
오픈 소스 소프트웨어로, 다양한 운영 체제에서 사용 가능
Git의 전체적인 구성
•
핵심 위치
◦
현재 작업중인 Working Directory
◦
commit 할 파일의 예비 저장소, 혹은 추적 대상 파일의 공간인 Staging Area
◦
각 유저의 컴퓨터에서 관리되고 있는 Local Repository
◦
Github 사가 관리하는 클라우드에서 관리되는 Remote Repogitory
•
이런 변경 사항들에 대하여 위치를 명령어(git command)로 이동
Local Repository는 Git이 관리한다.
•
진행하다보면 혼란스러울 수 있는 부분은 바로 로컬 저장소
•
내 컴퓨터에 분명이 있는 저장 공간이지만 실제로는 눈에 보이지 않기 때문
•
이 로컬 저장소는 우리가 Working Directory로 부터 commit 한 내용들이 스냅샷으로 저장되는 곳
◦
즉, commit이 된 순간의 파일과 그 내용을 로컬 저장소에서 가지고 있기 때문에 언제든지 commit 했던 지점으로 돌아가는 것이 가능함
◦
이 관리는 Git 시스템이 변경사항을 기록할 때마다 쌓아 나가는 방식으로 관리함
▪
마치 수작업으로 백업을 해야 하는 단순 작업을 대신 해주는 역할
1.1 Git 설치
Git 설치
Git 설치 이후
•
깃 설정 정보 확인
git config --list
Shell
복사
•
현재 로컬 컴퓨터의 사용자 설정 적용
git config --global user.name "yourname"
git config --global user.email "youremail@email.com"
Shell
복사
1.2 간단 Git 사용 시작하기
폴더 생성 (metaverse/gittest)
•
VSCode로 해당 폴더 열기
•
해당 폴더 git 초기화 터미널에 아래 명령어 입력
git init
Shell
복사
•
hello.txt 파일 생성 - 변경사항 발생
◦
변경 사항 확인
git status
Shell
복사
•
변경 사항 스테이징
git add hello.txt
Shell
복사
•
스테이징 된 상태 기록 - 커밋(Commit)
git commit -m "test : first git test"
Shell
복사
•
hello.txt 파일 내용 수정 + function.txt 파일 추가 - 추가 변경사항 발생
◦
변경 사항 확인
git status
Shell
복사
•
모든 변경사항 스테이징
git add .
Shell
복사
•
스테이징 된 상태 기록 - 커밋(Commit)
git commit -m "test : second git test"
Shell
복사
•
3번째 변경사항을 자유롭게 만들고, 이번엔 메시지를 변경 사항에 대해 직접적으로 표현해보기
◦
ex) “fix : 나누기 기능 추가”
GUI로 보다 쉽게 다뤄보기
•
GUI는 CLI를 보조하는 역할이며 일부 기능에서 오류, 딜레이가 발생하는 경우도 있다.
•
CLI로 상태를 정확하게 확인하는 습관을 들이자.
•
VSCode는 기본적으로 git과 연동 될 수 있는 플러그인이 있으며, 추가적으로 플러그인을 통해 좀 더 나은 환경을 구축 할 수 있음
•
또다른 변경사항을 GUI에서 스테이징 하는 과정을 통해 CLI 도 동일한 기능이 실시간으로 작동되는 것을 확인
2. Github
Git과 Github는 비슷한듯 다르다
•
Git은 로컬 저장소에서 작업 및 변경 이력을 기록, 협업을 돕는 도구
•
Github는 Git의 기능을 확장 활용하여 온라인에서 협업 할 수 있는 플랫폼
◦
GitHub는 각 팀원들이 로컬에서 작업한 변경 사항과 기록을 중앙에서 모아서 관리
◦
Github 또한 Git을 기반으로 구축된 플랫폼이다.
어떻게 사용해야 하는가?
•
간단히 기본적으로 각자의 컴퓨터에서의 모든 작업은 Git으로 관리
•
통합 시점(주기적인 회의, 기능 점검 등)을 정해서 공유해야 하는 상황 = Github로 공유
Github 가입과 저장소 생성
•
Github 계정을 만들고 로그인
•
VSCode와 Github 계정의 연동
•
현재 Local Repository를 Github의 Remote Repository로 생성(및 연결)
•
Github의 원격 저장소 확인
3. Git&Github 동기화
현재 프로젝트 삭제
•
작업하던 프로젝트 폴더를 삭제해본다.
•
github로 생성했던 원격 저장소에서 <>Code 부분을 눌러서 HTTPS 주소를 복사
•
VSCode를 열고 원격 저장소를 클론한다.
•
이후 다시 동일하게 복제된 프로젝트를 확인
위와 같은 작동 방법을 통해 온라인 백업(기록)의 개념을 활용
•
이것으로 URL만 있으면 모두 같은 저장소를 복제 할 수 있음
•
이제 로컬에서 변경사항을 다시 만들어보자
•
현재 커밋한 내용은 master라는 것으로 표기되어 있지만
•
아래 origin/HEAD, origin/master가 아래 표기되어 있다.
•
하나 아랫줄을 선택하여 Checkout 을 눌러보자
•
현재 변경사항이 사라졌다.
•
다시 좌측 하단 부분을 눌러 master를 선택
•
다시 최신 상태로 복구되었다.
•
이번엔 github에 생성했던 원격 저장소를 살펴보자.
•
제곱, 루트 처럼 변경사항이 적용되어 있지 않다.
•
처음 git remote를 통해 연결했던 시점까지만 온라인으로 업데이트를 했을 뿐이지 그 이후로는 로컬의 커밋을 전송한적이 없기 때문이다.
•
push 를 통해 업데이트 사항을 원격 저장소로 전송해보자.
◦
아래와 같은 버튼 또는 터미널을 통해 git push 명령어로 진행
•
변경 사항(커밋 내용 및 코드 내용)이 전달 된 것을 확인
•
이와 같이 로컬의 작업 → 커밋 → 푸시 를 연속적으로 진행하면서 계속해서 변경 사항을 온라인으로 공유하게 된다.
하지만 항상 클론해야 하는가?
•
이번엔 원격 저장소에서 먼저 업데이트된 경우를 가정하려 한다.
•
github 메인 페이지에서 아래 Add a README 를 선택
•
README.md 라는 파일을 Github에서 추가하고 있고, Github에서 커밋하고 있다.
•
실제로 해당 파일은 생성되었다.
•
하지만 반대로 로컬 컴퓨터의 입장에서는 원격 저장소의 변경사항을 모르고있다.
•
이 때 git pull 또는 sync 버튼을 통해서 원격의 업데이트 사항을 로컬에 반영 시킬 수 있다.
•
이와 같이 로컬 저장소와 원격 저장소를 계속하여 업데이트 해 나가면서 서로의 작업 현황을 공유해 나갈 수 있음
4. Branch
이 정도로 협업이 원활하게 진행 될까?
•
현재 혼자 커밋을 기록하고 푸시, 풀 하고 있기 때문에 전혀 문제가 발생하지 않고 있다.
•
여러명이 작업한다면 누가 무엇을 하는지 알 수 없다.
•
혹시나 같은 파일을 동시에 작업한다면??
우선 역할 분담에 따라 Branch를 생성한다.
•
Branch는 분기라는 의미로 말그대로 시점의 상태를 그대로 다른 이름으로 복제하는 것이라 볼 수 있음
•
이전에 checkout이 마치 그 시점으로 로그인하는 개념이었다. 이번엔 git checkout –b Board 명령어를 사용해보자 또는
•
master 브랜치를 클릭하면 다음과 같은 메뉴가 나타나기도 하며 Board를 입력
•
이것으로 master 브랜치의 현재 시점 상태로부터 Board라는 브랜치를 생성했다.
•
현재 내가 체크아웃되어있는(로그인되어있는) 브랜치는 git branch 명령어를 통해서도 확인 할 수 있으며
•
VSCode에서 하단 브랜치명을 통해서도 확인 할 수 있다.
•
Branch 이름은 정해진 규칙은 없지만 관례적으로 기능 단위로 구분한다.
◦
그 이유는 해당 브랜치가 master(또는 메인) 브랜치에 합쳐지면 해당 기능이 추가되었다는 의미로 쉽게 해석되기 때문이다.
◦
boardFunction.txt 와 같이 게시판 브랜치를 가진 사람이 해당 기능을 기획, 구현, 완료까지 진행했다. 각각 진행 상황마다 커밋을 진행
•
master 브랜치로 체크아웃하여 README.md를 일부 수정하자.
•
이제 Git Graph, GitLens 등을 통해 비주얼화 시켜 보면 다음과 같다
•
분기되었던 시점, Board라는 브랜치가 작업한것, master가 직접 작업한것이 구분된다.
•
이제 master, Board 브랜치 각각 push를 통해 원격 저장소에서 다뤄보자.
◦
Board 브랜치에서 git push로 단순히 푸시하면 경고가 나타날 것이다.
◦
해당 브랜치는 원격 저장소에서는 모르는 브랜치기 때문에 자동 생성하면서 업데이트 할 필요가 있다. 해당 명령어를 그대로 사용하면 된다.
◦
git push --set-upstream origin Board
Github에서의 병합과 재시작
•
master와 Board 브랜치가 각각 본인의 변경사항만을 업데이트했다.
•
원격저장소는 기본적으로 master 브랜치가 선택되어있기 때문에 master의 변경사항은 바로 적용된 것을 볼 수 있다. 해당 저장소의 기본 브랜치가 master로 설정되어 있기 때문
•
우리는 게시판 기능을 완성했기 때문에, 중간점검 차원에서 master 브랜치에 합쳐서 잘 작동하는지 테스트해야 한다.
•
이 때 위에 나타난 버튼 Compare & pull request가 병합을 위한 직전 보고와 같은 상태이다.
◦
각 브랜치로 작업하는 인원들은(팀장도 마찬가지) 모두 PR을 통해서 master 브랜치에 적용 할지를 확인하고 병합해야 한다.
◦
해당 브랜치 작업자는 PR을 생성하고 다음과 같이 작성
◦
작성 후에는 해당 브랜치가 활동한 각 커밋의 내용, 일정 등이 나타난다.
◦
이후 팀 담당자, 팀장 등이 Merge pull request 를 누르면서 Board 브랜치의 내용이 master로 병합 되게 된다.
◦
이후 master 브랜치는 Board의 변경사항까지 모두 병합된 최종 상태가 되며,
◦
개발은 계속되기 때문에 모든 작업자들은 최신 상태인 원격 저장소의 master 브랜치로부터 pull 로 업데이트를 해야 한다.
◦
당장 로컬 컴퓨터의 master 브랜치 또한 원격에서 병합되고 최신화된 정보를 모를것이다. 로컬의 master 브랜치로 체크아웃해보자.
◦
실제로 원격 master의 병합된 내용이 로컬 master에는 적용되어 있지 않다.
◦
git pull또는 업데이트 버튼을 통해서 최신화 시켜준다.
5. Conflicts
충돌 해결
•
지금까지는 원활하게 진행되면 큰 문제가 없지만 여러명이 작업하는 만큼 공용부분인 동일한 파일을 수정하는 문제가 발생한다.
•
Function 브랜치 담당자가 function.txt의 여러가지를 수정했다.
•
Calculator 브랜치 담당자는 다른 코드를 작업하다가 function.txt의 파일의 부분을 사용하기 때문에 조금 수정하게 되었다.
•
두 작업자 모두 주간 회의겸 병합을 위해서 Push를 통해 원격 저장소에 동기화했으며 각자 PR을 작성해둔 상태이다.
•
팀장은 점검을 위해서 두사람의 기능을 모두 master에 병합하려고 체크하고 있다. 우선 Function 의 PR부터 확인하고 merge를 진행했다.
•
이후 Calculator의 PR을 병합하려했는데 다음처럼 나타날 수 있다.
•
이와 같이 공통된 부분을 작업하다 보면 연관된 모듈, 변수 등을 사용하게 되면서 이런 충돌이 발생 할 수 있다.
•
Resolving conflicts 와 같이 메뉴로 접근하면 아래와 같은 형식으로 표기된다.
<<< 1 name
...
...codes...
...
=========
...
...diffcodes...
...
>>> 2 name
Shell
복사
•
이 때 === 표시를 기준으로 위아래로 구분해서 보면 된다.
•
그리고 둘중 하나의 내용을 선택하던지, 합치던지 내용을 서로 확인하고 회의하면서 수정해야 한다. 아니면 한명의 작업 내용이 적용되지 않을 수 있기 때문에 충돌은 해당 담당자가 모두 참여해서 확인하고 해결해야 한다.
•
해당 내용이 정리되었다면, 관련 기호 및 브랜치명들을 모두 제거하면서 실제 병합으로 남아야 하는 코드만 남겨둔다.
◦
나는 Calculator 브랜치 담당자가 모든 기능을 필요로 하는 의견에 따라 모든 기능을 그대로 남겨두는 것을 선택했다.
▪
Mark as resolved 를 선택하여 충돌 해결을 완료한다.
◦
이후 다시 PR에서 merge 부분이 활성화되면 병합 하여 팀원들에게 재배포 할 수 있다.
6. 정리
현재까지 Git과 Github 주요 명령어 및 핵심을 정리하면
•
주요 명령어
◦
git init 을 통해 초기화(처음 필수)
◦
git status 깃 상태 확인
◦
git add filename.txt or git add . 변경사항 스테이징
◦
git commit -m “내용” 스테이징된 내용 커밋
◦
git clone <저장소 url> 원격 저장소 클론
◦
git remote add <원격 저장소> <저장소 url> 원격 저장소 연결
◦
git push 연결된 원격 저장소로 푸시
◦
git pull 연결된 원격 저장소의 내용을 로컬로 업데이트
◦
git branch 브랜치 확인
◦
git branch <새로운 브랜치> 브랜치 생성
◦
git checkout <브랜치> 브랜치 체크아웃(로그인)
◦
git checkout -b <새로운 브랜치> 브랜치 생성하며 체크아웃하기 동시에
◦
git log 커밋 이력 보기
◦
git log -oneline 커밋 제목만 보기
•
작업순서
참고용 커밋 컨벤션
•
컨벤션(convention)은 소프트웨어 개발 및 프로그래밍에서 널리 사용되는 규칙, 표준, 또는 관행을 의미
•
이러한 규칙과 표준은 코드의 일관성, 가독성, 유지보수성을 향상시키고, 팀원 간의 협업을 원활하게 하도록 도움
•
변수나 클래스명같은 명명규칙, 코드스타일 규칙등 맞추지만 지금은 그 중 버전 관리 규칙에 대한 일부
◦
커밋 메시지 작성 규칙
•
git 커밋 메시지는 개인 기록용이 아니라 협업에서는 이것도 하나의 커뮤니케이션 툴이며 공통된 규칙이 있어야 됨
•
분명 회사마다 방식이 조금 다를 수도 있지만 기본적인 규칙을 다른 사람들은 어떻게 사용하는지 이번 기회에 올바른, 다른 사람들도 알아보기 편한 커밋 메시지 규칙들을 찾아 보고 정해보자.
feat : 게시판 기능 구현
refactor : 게시판 글작성 부분 코드 수정
fix : 게시판 삭제 버그 수정 및 기능 복구
chore : 초기 프로젝트 생성
chore : Express 라이브러리 추가
7. 개발 환경구축
Node.js란?
Node.js는 Chrome V8 JavaScript 엔진으로 빌드된 JavaScript 런타임입니다.
-Node.js는 공식 홈페이지-
•
자바스크립트(Javascript)의 특징
◦
JavaScript는 HTML을 동적(Dynamic)하게 바꿔주는 기능을 하게 하는 스크립트이다.
◦
자바스크립트는 본래 웹 브라우저에서만 동작하는 프로그래밍 언어
◦
따라서 프론트엔드만 커버할 수 있었지만 Node.js는 JavaScript를 웹 브라우저로부터 독립시켜 서버 구현을 가능하게 함
◦
이처럼 특정 언어가 구동되는 환경을 ‘런타임’이라고 한다.
◦
쉽게 말해 기존 자바스크립트의 런타임은 오직 웹 브라우저뿐이었는데, Node.js로 새로운 런타임(실행환경)이 생긴 것으로 이해
•
V8 엔진은 원래 구글이 웹 브라우저인 Chrome의 성능을 높이려는 목적으로 개발
◦
이전까지의 JavaScript 엔진들은 코드가 많아질수록 속도가 느려진다는 단점이 있었음
◦
코드 번역 방식을 바꿔 속도를 획기적으로 개선함, 구글이 이를 오픈소스로 공개하면서 전 세계적으로 V8엔진을 활용해 웹을 개발할 수 있게 됨
Node.js는 비동기 이벤트 기반 JavaScript 런타임이다.
- MDN
•
2008년에 구글이 V8 엔진을 사용하여 크롬을 출시했는데, V8 엔진은 엄청 빨랐고, 오픈 소스로 코드도 공개되었. 그 기능을 좀 더 더해서 V8 엔진 기반에 노드 프로젝트를 시작했고, Node.js(V8)이 등장했다.
•
웹 서버와 같이 확장성 있는 네트워크 프로그램 제작을 위해 고안되었다.
쉽게 말해 JavaScript 기반 런타임 환경으로 브라우저 내에서 말고도 다른 환경에서 자바스크립트를 사용할 수 있게 해주는 실행환경이다.
Node.js가 자바스크립트를 컴퓨터에서 쉽게 실행시켜줬기 때문에 자바스크립트를 프로그래밍 언어처럼 사용하기 시작했다.
Node.js를 서버로 만드는 이유?
그렇다면 왜 새로운 런타임 환경까지 만들면서 JavaScript를 사용하고자 했을까?
•
JavaScript가 높은 생산성과 편리함을 지녔기 때문
•
프론트엔드 주요 언어이기 때문에 백엔드까지 영역을 확장하게 되면서 풀스택 개발이 훨씬 수월해짐
Node.js의 핵심은 크게 3가지이다.
1.
Non-blocking I/O(I/O 작업이 다른 작업들에게 영향을 미치지 않고 비동기적으로 처리되도록 하는 기술)
2.
코드가 매우 짧고 쉬워서 빠른 개발 가능
3.
웹서비스 제작에 적합
여기서 특히 Non-blocking I/O 특징을 통해 Node.js로 구현하면, 요청이 많거나 오래 걸리는 요청이 있어도 멈추거나 요청 대기시간이 없다는 것이다. (비동기식 이벤트 기반 아키텍처)
비동기식 이벤트 기반 아키텍처란?
동기식(Synchronous) VS 비동기식(Asynchronous)
Node.js는 비동기 I/O를 지원하며 Single-Thread 기반으로 동작하는 서버이기 때문에 요청을 처리하면서 다음 요청을 받을 수 있다.
병렬처리를 Thread 로 처리하지 않으므로 Multi-Thread가 갖는 근원적인 문제에서 자유로운 특징이 있다.(멀티스레드는 스레드 1개의 오류가 전체 프로세스에 영향을 주는 등)
•
요청 순서: 코드가 실행되는 순서는 동기적으로 진행
◦
즉, 요청1, 요청2, 요청3, 요청4와 같은 순서로 코드가 작성되면, 이 요청들은 순차적으로 실행
•
비동기 처리: 하지만 각 요청의 처리 결과는 비동기적으로 처리되기 때문에, 요청이 완료되는 순서는 요청을 보낸 순서와 다를 수 있음. 예를 들어, 요청1이 1초 후에 완료되고, 요청2가 500ms 후에 완료된다면, 요청2의 결과가 먼저 출력될 수 있다.
•
이벤트 루프: 이벤트 루프는 비동기 작업이 완료되면 해당 작업에 등록된 콜백 함수를 호출합니다. 이때, 비동기 작업의 완료 시점에 따라 콜백의 실행 순서가 결정되므로, 요청의 결과가 도착하는 순서는 요청을 보낸 순서와 다를 수 있습니다.
결론적으로, 요청을 보내는 순서는 동기적으로 진행되지만, 결과가 도착하는 순서는 비동기적으로 처리되기 때문에 다를 수 있음, 이러한 비동기 처리 방식이 Node.js의 주요 특징 중 하나이며, 이를 통해 높은 성능과 효율성을 제공
NVM vs NPM?
두 용어가 나타나서 혼동될 수 있지만 풀어쓰면 명확해진다.
nvm - Node Version Manager
nvm 은 Node.js 를 설치하는 툴이라 이해하자.
Node.js 의 각 버젼을 유지하면서 시스템을 구성해야 하는 경우를 위해 사용하는 경우에 많이 이용된다. 다시말해 같은 시스템 안에서 여러 Node.js 를 사용하기 위해 버젼별로 Node.js 환경을 격리시키는 역할
npm - Node Package Manager
node에서 다양한 라이브러리를 다운로드하는 패키지 매니저로 보면 된다.
노드 패키지 매니저. 간단하게 얘기하면 npm 서비스를 통하여 Node.js 로 개발된 프로그램을(npm 패키지) 편리하게 설치, 업데이트 및 삭제를 해 주는 프로그램이다.
Node.js 를 설치하면 npm 도 같이 설치된다.
Java를 기준으로 생각하면 maven과 같이 다양한 패키지들을 다운로드 할 수 있는 경로로도 알고 있으면 된다. Java의 MavenCentral처럼 npm에서도 다양한 라이브러리 의존성(node진영에선 주로 모듈이라고 부르는것 같다.)들을 검색하고 다운로드 할 수 있다.
모듈과 패키지, 라이브러리 모두 결국 함수의 집합이다. 물론 정확한 개념은 차이가 있지만 메인언어의 진영마다 통상적으로 부르는 용어의 차이가 존재하는것으로 보인다. 자바진영에서는 코드상의 동작과 관련된 개념은 대부분 메서드라는 명칭을 쓰지만 JS진영에서는 대부분 함수(function)이라고 부르는 것처럼 라이브러리나, 모듈이나 결국 특별한 기능을 하는 함수의 집합이라고 보는게 편하다.
•
환경 구축
Node.js 설치 환경 구축(MacOS기준)
Node.js 설치 환경 구축(Windows)
nvm으로 Node.js 설치(위 해결 후 공통)
Related Posts
Search
