[클라우딩 어플리케이션 엔지니어링 TIL] - DAY 12

JavaScript

예외 상황(Exception)

런타임 때 발생할 수 있는 의도치 않은 상황

• 흐름 제어 시 발생할 수 있는 예외 상황이므로 이를 이해하여 코드 레벨에서 대응해야 함.
• 예외 상황을 핸들링하지 않는다면 기능이 동작하지 않거나 애플리케이션이 shout down 될 수 있음.

예외의 원인

언어 레벨에서부터 외부 요인까지 다양

• 코드 레벨
• 하드웨어, 디바이스 문제
• 라이브러리 손상
• 사용자의 입력 실수

예외의 종류

ECMAScript Error

자바스크립트 언어에서 발생하는 Error Type

• RangeError: 값이 집합에 없거나, 허용 범위가 아닐 때
• ReferenceError: 존재하지 않는 변수 참조 시
• SyntaxError: 문법을 지키지 않았을 때
• TpyeError: 값이 기대한 자료형이 아니어서 연산이 불가능할 때

DOMException

Web API 레벨에서 발생하는 Error Type

• NetworkError: 네트워크 에러 발생 시
• AbortError: 작업이 중단되었을 때
• TimeoutError: 작업 시간이 초과되었을 때

그 외

• 개발자가 예상치 못한 예외 상황
• 개발자가 직접 예외 상황을 예상하여 핸들링 가능
• 자바스크립트의 Error 객체를 사용하여 직접 에러를 정의 내리고 핸들링 가능

throw와 Error 객체

throw문: 예외를 발생시킬 때 사용 -> catch블럭에서 에러 객체 핸들링

 

예외가 발생하면

1. 현재 함수의 실행 중지
2. 에러 객체와 함께 에러가 throw
3. 제어흐름은 호출자 사이에 catch블록이 있으면 catch블록으로 전달, 없으면 프로그램 종료

Error 객체: 사용자가 직접 Error 객체를 정의하여 사용 가능

• new Error()
• Error.message
• Error.name

const customError = new Error();
customError.name = '정의할 에러 이름';
customError.message = '에러 메시지';
throw customError; // 에러 발생이 예측되는 지점에서 throw

 

 

+ 오늘은 깃과 깃허브에 대한 특강을 김송아 강사님이 진행해주셨다.

강의를 들으면서 하신 말씀을 머릿속으로 대충 정리하면서 적고 있었는데 강사님이 중간중간 질문을 자주 던지셔서 대답까지 해보려니 조금 바빴다,, 😅 그래도 말씀하신 것에 대해 잠깐 생각해 보며 대답하니까 강의를 집중하는데 도움이 됐다. 특강 세션 녹화본을 올려주시는 걸 나중에 알아서 다음 특강 땐 좀 여유를 갖고 강의를 들어야겠다.

GitHub A to Z

사전 질문: 면접에 깃허브가 포트폴리오로 유리한가? 굉장히 좋음.

 

포트폴리오로 쓰이는 유형

1. 깃허브: 무조건 유용, Readme를 잘 적고, 잘 설명할 수 있어야 함. 잔디 매일 심기는 크게 의미를 두지 않아도 됨.
2. 블로그: 본인이 어떻게 공부하는지, 했는지 적기, 내용을 줄줄이 쓰는 게 아니라 나의 생각을 중심으로, 진행하는 프로젝트가 있다면 프로젝트의 현재 상황 이슈 등
3. ppt: 클래식하지만 여전히 좋음

 

프로젝트란?

한 명 ~ 다수의 인원이 하나/특정의 목표를 이루기 위해 만들어가는 전체 프로세스

프로젝트로 자신의 역량을 나타낼 수 있어야 함.

 

- 팀 프로젝트는 협업 + 내가 맡은 역할, 이슈/해결 방안에 대해
- 개인 프로젝트는 기술 스택 + 프로젝트 관리에 대해

 

협업이란?

진행 상황에 대해 공유하는 것

Read me에는 어떤 걸 적어야 하는가

1. 프로젝트 진행 중: 진행 상황(이슈, 고민, 설계, 현황), 목표
2. 프로젝트가 종료되면: 프로젝트 소개를 잘 적기 => 설계에 관해서(면접 질문 유도), 이슈/해결 방안, 개선 방안(고도화) + 리팩토링(언제든 해도 괜찮음, 명명법, 로직, 기능추가 등)

버전이란?

유의미한 수정은 곧 새로운 버전

• 기능 추가, 수정, 삭제
• 오류 수정, 라이브러리 버전 업그레이드
• 백업과 복구, 히스토리 추적

버전 관리 시스템(Version Control System)

1. 로컬식 VCS: 내 컴퓨터에서만 관리, 협업 어려움. ex) Git
2. 중앙 집중식: 중간에 컴퓨터 한 대 두고, 이 컴퓨터에게 버전 관리 책임자를 둠. ex) SVN
3. 분산식: 서버뿐 아니라 모든 컴퓨터가 책임. + 프로젝트 단위 ex) Github, gitLab

Git은 로컬뿐만 아니라 GitHub와의 소통하는 용도.

 

Git과 GitHub의 관계

깃은 정확히 말하면 컴퓨터에 설치해 두는 로컬/분산식 버전 관리 시스템 + GitHub 중간 연결

기능: 버전 업데이트, 버전 동기화 + 코드 충돌 감지

Git에서 자주 쓰는 명령어

• init: git 폴더 만들 때 사용, 저장 폴더 경로 지정
• status: 현재 상태
• log: 이력
• add: 아직 이 파일을 버전 관리하기 전이라면 관리할 파일 추가, 이미 관리 중이면 다음 commit 전까지 임시 저장
• commit: 변경사항 저장 => 변경 지점/스냅샷 기억

• push: 내 컴퓨터에 commit 되어있는 버전을 Github에 올리는 명령어
• pull: 깃허브에 있는 내용을 받아오는 명령어, 단 기존 작업했던 것을 유지하면서 원격 저장소와 비교해 로컬 저장소 업데이트

협업에선: clone, stash, rebase 자주 사용

• clone: 원격 저장소에 있던 모든 파일 받아오기, 프로젝트에 처음 투입될 때 사용
• stash: 현재 작업을 임시로 저장하고 나중에 다시 불러와 계속 진행할 수 있게 해주는 기능, commit 하기엔 좀 부담스러울 때 사용
• rebase: 현재 브랜치의 커밋을 임시로 저장하고 대상 브랜치의 커밋으로 현재 브랜치 업데이트 후 임시 저장 커밋을 적용

 

개인적인 궁금증)

브랜치를 병합하는 방법은 merge도 있는데

그렇다면 merge와 rebase는 어떤 차이가 있는 걸까

 

merge: 브랜치를 합칠 때 두 브랜치의 공통 조상과 각 브랜치의 최신 커밋을 이용해 새로운 커밋을 생성

-> 원래 브랜치의 히스토리가 유지되는 것이 장점이나 복잡한 히스토리가 생성될 수 있음.

 

rebase -> 과거의 커밋 히스토리를 변경하여 덮어버리기 때문에 히스토리 변경 이력을 선형적으로 만들 수 있음.

 

즉, merge는 변경 이력이 담긴 모든 브랜치를 남기기 때문에 히스토리를 어지럽힐 수도 있으나

적어도 과거 브랜치를 없애지는 않아 정확한 히스토리를 남기며,

rebase는 브랜치를 합쳐 자잘한 변경 이력들은 없애기 때문에 히스토리 파악을 쉽게 만든다.

 

따라서 사실 이력을 정확하게 남겨야 하는 상황에서는 merge로, 로컬에서 작업하면서 나만 보려고 임시로 생성한 브랜치들은 rebase를 통해 정리하는 것이 좋아 보인다.