플레이데이터 백엔드 8기 유승현님의 1주차 회고
2025년 2월 18일, 첫 수업부터 금요일까지 배운 내용과 중요한 점/새로 알게된 점 그외의 것을 적어보도록 하겠다.
1. Git
Git은 소프트웨어 개발에서 사용되는 DVCS(클라이언트가 서버의 파일을 복제함으로 네트워크에 접근할 수 없는 상황일지라도 개발을 계속 진행할 수 있는 것) 중 하나로, 소스 코드 관리에 주로 사용되고 있음.
- 다른 개발자와의 협업을 하거나, 코드의 안정성 유지, 배포 관리, 코드 리뷰 및 추척이 가능하다는 특징이 있음.
- 또한, 인터넷 연결을 해야 동작하는 GitHub와 달리 Git은 오프라인 상태에서도 사용이 가능함.
| pwd | 현재 위치한 폴더 출력 |
| cd | 원하는 경로로 이동 |
| clear | 현재 터미널 출력 내용 지우기 |
| cd .. | 상위 경로로 이동 |
| ls | 하위 폴더, 파일 보기 |
| ls -al | 하위 폴더, 모든 파일 보기 |
| mkdir <newFolder> | 새 디렉토리 생성 |
| rm -rf <Folder, File> | 폴더, 파일 삭제 |
| open <file> | 해당 폴더 실행 |
| touch <file> | 파일 생성하기 |
2. Git Repository
Git Repository는 git에 의해 관리되는 프로젝트 디렉터리. 이 안에는 프로젝트의 모든 파일, 각 파일의 수정 이력을 담은 정보가 포함되어 있음.
이 것은 프로젝트의 상태를 특정 시점으로 되돌리거나 다른 브랜치로 전환하는 등의 기능을 수행함.
(쉽게 설명하면, 게임할 때 세이브를 하는 그런 느낌이라고 보면 될 것 같다.)
1. Working Directory : 현재 작업 중인 프로젝트의 파일들이 위치하는 디렉토리.
2. Staging Area (Index) : commit하기 위한 파일을 저장하는 영역 (add 명령어를 이용), 이 영역을 통해, 원하는 파일만 커밋할 수 있음.
3. Repository : git의 메타데이터와 객체 데이터베이스를 저장하는 디렉토리. (commit 명령어를 이용)
3. Git ignore
.gitignore 파일은 Git에서 특정 파일 또는 디렉토리를 버전 관리에서 제외할 때 사용한다. 주로 개인 정보가 담겨있는 파일들을 지정하고 제외시킨다.
.gitignore 파일에서 사용할 수 있는 패턴
| *.log | 모든 log 파일을 무시. |
| !important.log | iimportant.log 파일은 무시하지 않도록 예외 설정. |
| /tmp | 프로젝트의 루트 디렉토리에 있는 tmp 디렉토리만 무시. |
| debug/ | debug라는 이름의 디렉토리 무시. |
| doc/*.txt | doc 디렉토리에 있는 .txt 파일 무시. |
.gitignore파일은 이미 커밋된 파일에는 영향을 미치지 않기 때문에 처음부터 만들어야 한다.
4. Branch
브랜치(Branch)란, 코드의 특정 버전을 가리키는 포인터와 같은 것.
브랜치를 사용하면 동일한 소스코드에 대해 동시에 여러가지 작업을 수행할 수 있고, "main"브랜치의 안정성을 유지하면서, 다른 브랜치에서는 실험적인 변경 또는 새로운 기능을 추가할 수 있어 필수적인 요소이다.
Git의 HEAD는 현재 작업 중인 커밋을 가리키는 포인터. 다른 말로, "현재 Git이 어디를 바라보고 있는지"로 표현할 수 있다.
기본적으로 HEAD는 항상 작업트리의 최상단/ 가장 최근의 커밋을 가리킴.
- 어떤 커밋이 현재 작업 중인지를 식별하는 기능
- 새로운 커밋이 생성될 때, HEAD는 자동으로 새 커밋을 가리킴.
- HEAD는 상대 참조를 이용하여 커밋 트리를 쉽게 탐색할 수 있게 함.
5. Merge
Metge란, 여러 브랜치에 분산된 코드 변경 사항을 하나의 브랜치로 합치는 과정을 말한다.
두 브랜치가 공통 조상에서 다르게 발전한 경우에 사용하는 병합 전략. 단, 충돌이 발생하는 경우, 사용자가 직접 해결해야 하는 복잡한 상황이 발생할 수 있음.
- 빠른 포워드 병합(fast-forward merge)
하나의 브랜치에서만 변경 사항이 있고, 다른 브랜치는 변경되지 않은 경우에 발생. 이 경우 git은 단순히 브랜치 포인터를 앞으로 이동.
Git의 강력한 기능 중 하나로, 복잡한 병합 작업 없이 브랜치를 간결하게 병합할 수 있음.
충돌은 2개 이상의 변경 사항이 merge과정에서 서로 충돌할 때 발생하는 문제.
주로 여러 사람이 동시에 동일한 파일의 같은 부분을 변경했을 때, 자주 발생함.
이러한 충돌은 git 스스로 해결할 수 없으므로, 사용자에게 직접 해결을 요청함.
만약 충돌이 발생할 경우, git은 Conflict marker를 사용하여, 사용자에게 어디에 문제가 발생했는지 알려줌.
해결 방법
1. git status 명령어를 이용하여 충돌이 발생한 파일 확인.
2. 충돌이 발생한 파일을 열고 충돌 마커를 찾는다.
3. 각 충돌에 대해 어떤 변경 사항을 유지할지 결정하고 수정한다. 그 후에 충돌 마커를 모두 제거.
4. 파일을 저장하고 스테이징 후, 커밋한다.
6. Git diff
diff는 작업 트리와 Index 영역 사이의 차이를 보여주거나, 두 커밋 사이의 차이를 보여주는 명령어이다.
주로 코드 리뷰, 디버깅, 병합 충돌 해결 등의 다양한 상황에서 사용할 수 있다.
7. Git Stash
stash란, git에서 제공하는 일시적인 작업 저장소이다.
이를 사용하면 아직 완료되지 않은 변경 사항을 일시적으로 저장이 가능하고,나중에 다시 불러와 작업을 이어갈 수 있음.
- 현재 브랜치에서 작업하던 중 다른 브랜치로 전환해야할 때 stash를 사용함으로써,
브랜치의 작업 상태를 저장하고 깨끗한 작업 디렉토리로 다른 브랜치로 이동할 수 있음. - 코드 변경 사항이 문제를 일으키고 있는지 확인하기 위해, stash를 사용하여 변경사항을 일시적으로 제거하고 코드의 이전 상태를 테스트할 수 있음.
- 중요하지 않거나, 아직 커밋하고 싶지 않은 변경 사항을 일시적으로 보관하고 필요시, 다시 불러올 수 있음.
- 관련 명령어
8. Detached HEAD
특정 브랜치가 아닌 커밋에 직접 체크아웃한 상태를 나타내는 말.
1. 단순히 HEAD를 분리시킨 상태로 이전 커밋의 파일들을 돌아볼 수 있음.
2.git switch -c <new_branch> 명령어를 이용하여, 현재 커밋을 기반으로 새 브랜치를 생성할 수 있음.
3. git stash를 사용하여 변경 사항을 저장한 다음, 브랜치로 체크 아웃할 수 있음. 이후에 해당 변경 사항을 다시 불러와 작업 가능
* 주의할 점은 Detached HEAD 상태에서의 변경 사항은 참조되지 않는 커밋이 되고, 시간이 지나면 git의 GC에 의해 제거될 수 있으므로, 작업 내용을 유지할려면 적절한 브랜치에 체크인 하는 것이 중요.
9. restore
작업 디렉토리나 인덱스의 변경 사항을 특정 커밋의 상태로 되돌리는데 사용되는 명령어.
예기치 않게 수정한 파일을 원래 상태로 되돌리거나, 커밋하지 않은 변경 사항을 제거하는데 사용.
10. reset
현재 HEAD를 특정 커밋으로 이동시키는데 사용되는 명령어. 주로 이전의 상태로 되돌리고 싶을 때 사용됨.
11. revert
git에서 특정 커밋을 취소하는 데 사용되는 명령어. 단순히 이전 상태로 되돌리는 것이 아닌, 취소하려는 커밋의 변경 사항을 반대로 적용하는 커밋을 생성. (히스토리를 유지하면서 변경 사항을 되돌리기 때문에, 공동 작업에서 유용한 명령어이다.)
12. git hub
Git을 사용하는 프로젝트를 지원하는 웹 기반 호스팅 서비스. 즉, 코드를 온라인으로 저장하고 관리하며, 여러 사람이 동시에 작업을 할 수 있다.
1. 코드를 클라우드에 저장하고 언제든지 접근이 가능하다. 또한, 다른 사용자와 코드 공유를 할 수 있음.
2. 프로젝트의 과거 시점 또는 변경 사항을 비교할 수 있음.
3. 코드를 공유하고 다른 사용자와 협업을 진행할 수 있음.
4. 버그 추적, 기능 개발, 작업 할당, 프로젝트 진행 상황 관리 가능.
5. 다양한 개발 도구와 연동이되고, 사용자 정의 스크립트 또는 앱을 통해 기능 확장이 가능.
13. git fetch, git pull
원격 저장소에서 정보를 가져오는 명령어들.
14. Collaborator
git hub에서 프로젝트는 repository형태로 관리되는데, repository의 소유자 또는 관리자는 다른 git hub 사용자를 Collaborator로 초대할 수 있음.
즉, collaborator는 해당 프로젝트에 기여하는 사람들을 말함.
1. collaborator는 소유자와 동일하게 저장소에 직접 푸시할 수 있음.
2. 저장소의 이슈를 열고 닫을 수 있음. (이슈는 프로젝트의 오류 보고/기능 추가 요청/개선 사항을 관리하는 것에 유용함.)
3. collaborator는 다른 사람들이 제출한 코드 변경사항을 검토 및 결정하는 풀 리퀘스트를 수락하거나 거절할 수 있음.
15. README.md
GitHub repositiry의 시작점. 이 파일 안에는 일반적으로 프로젝트에 대한 정보와 사용 방법을 소개하는데 사용.
보통 Markdown이라는 경량 마크업 언어로 작성됨.
16. Pull Request (PR)
개발자가 자신이 작업한 브랜치를 원격 저장소의 타켓 브랜치와 병합하는 것을 제안할 때 사용하는 기능.
1. Create a merge commit : 일반 merge와 동일. git history에서 해당 PR에 대해 상세하게 알 수 있지만, 프로젝트의 규모가 커질수록 히스토리를 알아보가 힘들어진다.
2. Rebase merge : Merge할 branch의 커밋 내역들을 그대로 옮기는 것. 히스토리를 깔끔하게 볼 수 있지만, 여러개의 커밋을 rebase merge를 했는데 충돌이 발생한다면 병합하려는 모든 커밋에서 충돌이 발생함.
3. squash merge : rebase하되, 병합할 커밋들을 하나의 커밋으로 뭉친다. 브랜치를 깔끔하게 유지하면서 자잘한 커밋을 제거 및 의미있는 커밋만으로 히스토리를 이룰 수 있는 장점이 있다.
17. Fork
다른 사람의 원격 저장소를 자신의 깃허브 계정으로 복제하는 것.
- 프로젝트를 자신의 계정으로 가져와서 새로운 기능을 추가하거나 버그를 수정할 수 있음.
- 자신이 수정한 내용을 원본 저장소에 반영해달라고 PR을 보낼 수 있음.
18. JAVA
1995년 발표된 객체지향 프로그래밍 언어
1. 개발자 친화적인 언어로 개발자가 반드시 필요하지 않다고 생각한 부분은 스스로 처리한다.
2. 숫자, 문자, 논리형 등의 기본 타입을 제외하고는 객체로 이루어진 객체 지향적 언어이다.
3. 컴파일 언어이면서, 인터프리터 언어이다.
4. 문법이 엄격해서 안전하다.
- 프로그램 소스코드에 프로그래머의 의견 또는 설명을 적기 위해 사용하는 것.
- 프로그램 수행에 영향을 미치지 않기 때문에, 어디에든 작성이 가능함.
- 데이터가 저장되는 곳에 이름을 붙여 놓은 것.
- 자주 사용할 값 또는 복잡한 연산의 결과값 또는 사용자의 입력값 등등의 내가 따로 보관해 두었다가 나중에 꺼내에 사용하고 싶은 값들을 담아 놓는 공간.
- 이 때, 변수에는 값을 하나 당 하나밖에 넣지 못한다. 만약 이미 값을 가지는 변수에 새로운 값을 할당 시, 기존 값이 밀려나감.
1. byte : 1byte 크기의 정수형.
2. short : 2byte 크기의 정수형.
3. int : 4byte 크기의 정수형.
4. long : 8byte 크기의 정수형.
1. float : 4byte의 실수형이며, 소수점 이하 7자리까지 표현이 가능.
2. double : 8byte의 실수형, 소수점 이하 15자리까지 표현이 가능.
boolean : 1bit의 크기를 가지고, true/false 이외에는 어떠한 값을 가지지 못한다.
char : 단일 문자를 표현할 수 있는 데이터 타입으로 홀따음표(' ')안에 문자를 한 개만 넣어서 표현. (2 byte 크기)
* String : 단일 문자들이 쭉 나열되어 있는 형태. 쌍 따옴표(" ")를 통해 여러 문자들을 한번에 묶을 수 있다.
여기서 주의할 점은 String은 기본 데이터 타입이 아닌, 클래스 타입이다.
1. 자동 형 변환
큰 데이터 타입에 작은 데이터 타입 값이 들어갈 때는 자동으로 형 변환이 발생. (값의 손실이 없기 때문에)
2. 명시 형 변환
- 자동 형 변환과는 다른 상황. 크기가 큰 데이터 타입을 작은 타입으로 내려야하기 위해서는 강제 변환을 해야한다.
- 괄호 안에 변환하고자 하는 타입을 작성해야함. ex) int num = (int) num2;
- 변환하는 과정에서 overflow 또는 값 손실이 발생할 수 있어, 신중하게 결정해야함.
변수에 값을 변경하거나 대입하는 등의 작업을 수행해 주는 여러가지 기호들
연산자의 종류
전반적인 느낀 점 (일주일 동안 한 일)
부트캠프에 들어가기전, "수업에 잘 따라올 수 있을까?"라는 막연한 걱정이 있었다.
하지만 강사님의 디테일한 진행과 수업으로 걱정은 싹 사라졌고, 할 수 있다는 자신감이 생겼다.
또한 git/github 및 java 맛보기 느낌으로 배웠는데, 생각보다 괜찮았다.
반면, 항상 느끼는 거지만 강남 출퇴근 시간대는 지옥이다. (그래도 예전에 다녔던 직장도 강남이라 그런지, 아직은 버틸만 하다. 아직은....)
좋았던 점 (좋았거나 내가 잘했던 점)
git/gitub에 대해 배우고, 이와 관련된 간단한 프로젝트를 수행함으로써, 어떻게 개발자들이 git을 이용하는지 또는 협업할 때 어떻게 하는지에 대한 윤곽이 잡혔다. 이를 바탕으로 앞으로의 협업이나 토이 프로젝트를 진행 시에 많은 도움이 될 것 같아 좋았다.
아쉬웠던 점
개념과 이론을 숙지했는데 불구하고 조별과제 진행 시, 머리가 하얘졌다. (머리로는 알겠는데, 몸이 따라주지 않는 느낌이랄까..?)
개선할 점
손에 익히기 위해 계속해서 연습 또 연습!! (+ 체력관리를 위해 운동 빈도를 늘리는 것도 덤!)
다음주 계획
- 자바 언어를 활용하여 알고리즘 문제 풀기
- git/github 친해지기
승현님의 더 많은 이야기가 궁금하다면?
👉 플레이데이터 백엔드 8기 유승현님의 블로그에서 확인해보세요!🚀
[블로그 바로 가기]
1. Git
Git은 소프트웨어 개발에서 사용되는 DVCS(클라이언트가 서버의 파일을 복제함으로 네트워크에 접근할 수 없는 상황일지라도 개발을 계속 진행할 수 있는 것) 중 하나로, 소스 코드 관리에 주로 사용되고 있음.
- 다른 개발자와의 협업을 하거나, 코드의 안정성 유지, 배포 관리, 코드 리뷰 및 추척이 가능하다는 특징이 있음.
- 또한, 인터넷 연결을 해야 동작하는 GitHub와 달리 Git은 오프라인 상태에서도 사용이 가능함.
2. Git Repository
Git Repository는 git에 의해 관리되는 프로젝트 디렉터리. 이 안에는 프로젝트의 모든 파일, 각 파일의 수정 이력을 담은 정보가 포함되어 있음.
이 것은 프로젝트의 상태를 특정 시점으로 되돌리거나 다른 브랜치로 전환하는 등의 기능을 수행함.
(쉽게 설명하면, 게임할 때 세이브를 하는 그런 느낌이라고 보면 될 것 같다.)
1. Working Directory : 현재 작업 중인 프로젝트의 파일들이 위치하는 디렉토리.
2. Staging Area (Index) : commit하기 위한 파일을 저장하는 영역 (add 명령어를 이용), 이 영역을 통해, 원하는 파일만 커밋할 수 있음.
3. Repository : git의 메타데이터와 객체 데이터베이스를 저장하는 디렉토리. (commit 명령어를 이용)
3. Git ignore
.gitignore 파일은 Git에서 특정 파일 또는 디렉토리를 버전 관리에서 제외할 때 사용한다. 주로 개인 정보가 담겨있는 파일들을 지정하고 제외시킨다.
.gitignore 파일에서 사용할 수 있는 패턴
.gitignore파일은 이미 커밋된 파일에는 영향을 미치지 않기 때문에 처음부터 만들어야 한다.
4. Branch
브랜치(Branch)란, 코드의 특정 버전을 가리키는 포인터와 같은 것.
브랜치를 사용하면 동일한 소스코드에 대해 동시에 여러가지 작업을 수행할 수 있고, "main"브랜치의 안정성을 유지하면서, 다른 브랜치에서는 실험적인 변경 또는 새로운 기능을 추가할 수 있어 필수적인 요소이다.
Git의 HEAD는 현재 작업 중인 커밋을 가리키는 포인터. 다른 말로, "현재 Git이 어디를 바라보고 있는지"로 표현할 수 있다.
기본적으로 HEAD는 항상 작업트리의 최상단/ 가장 최근의 커밋을 가리킴.
5. Merge
Metge란, 여러 브랜치에 분산된 코드 변경 사항을 하나의 브랜치로 합치는 과정을 말한다.
두 브랜치가 공통 조상에서 다르게 발전한 경우에 사용하는 병합 전략. 단, 충돌이 발생하는 경우, 사용자가 직접 해결해야 하는 복잡한 상황이 발생할 수 있음.
하나의 브랜치에서만 변경 사항이 있고, 다른 브랜치는 변경되지 않은 경우에 발생. 이 경우 git은 단순히 브랜치 포인터를 앞으로 이동.
Git의 강력한 기능 중 하나로, 복잡한 병합 작업 없이 브랜치를 간결하게 병합할 수 있음.
충돌은 2개 이상의 변경 사항이 merge과정에서 서로 충돌할 때 발생하는 문제.
주로 여러 사람이 동시에 동일한 파일의 같은 부분을 변경했을 때, 자주 발생함.
이러한 충돌은 git 스스로 해결할 수 없으므로, 사용자에게 직접 해결을 요청함.
만약 충돌이 발생할 경우, git은 Conflict marker를 사용하여, 사용자에게 어디에 문제가 발생했는지 알려줌.
해결 방법
1. git status 명령어를 이용하여 충돌이 발생한 파일 확인.
2. 충돌이 발생한 파일을 열고 충돌 마커를 찾는다.
3. 각 충돌에 대해 어떤 변경 사항을 유지할지 결정하고 수정한다. 그 후에 충돌 마커를 모두 제거.
4. 파일을 저장하고 스테이징 후, 커밋한다.
6. Git diff
diff는 작업 트리와 Index 영역 사이의 차이를 보여주거나, 두 커밋 사이의 차이를 보여주는 명령어이다.
주로 코드 리뷰, 디버깅, 병합 충돌 해결 등의 다양한 상황에서 사용할 수 있다.
7. Git Stash
stash란, git에서 제공하는 일시적인 작업 저장소이다.
이를 사용하면 아직 완료되지 않은 변경 사항을 일시적으로 저장이 가능하고,나중에 다시 불러와 작업을 이어갈 수 있음.
브랜치의 작업 상태를 저장하고 깨끗한 작업 디렉토리로 다른 브랜치로 이동할 수 있음.
8. Detached HEAD
특정 브랜치가 아닌 커밋에 직접 체크아웃한 상태를 나타내는 말.
1. 단순히 HEAD를 분리시킨 상태로 이전 커밋의 파일들을 돌아볼 수 있음.
2.git switch -c <new_branch> 명령어를 이용하여, 현재 커밋을 기반으로 새 브랜치를 생성할 수 있음.
3. git stash를 사용하여 변경 사항을 저장한 다음, 브랜치로 체크 아웃할 수 있음. 이후에 해당 변경 사항을 다시 불러와 작업 가능
* 주의할 점은 Detached HEAD 상태에서의 변경 사항은 참조되지 않는 커밋이 되고, 시간이 지나면 git의 GC에 의해 제거될 수 있으므로, 작업 내용을 유지할려면 적절한 브랜치에 체크인 하는 것이 중요.
9. restore
작업 디렉토리나 인덱스의 변경 사항을 특정 커밋의 상태로 되돌리는데 사용되는 명령어.
예기치 않게 수정한 파일을 원래 상태로 되돌리거나, 커밋하지 않은 변경 사항을 제거하는데 사용.
10. reset
현재 HEAD를 특정 커밋으로 이동시키는데 사용되는 명령어. 주로 이전의 상태로 되돌리고 싶을 때 사용됨.
11. revert
git에서 특정 커밋을 취소하는 데 사용되는 명령어. 단순히 이전 상태로 되돌리는 것이 아닌, 취소하려는 커밋의 변경 사항을 반대로 적용하는 커밋을 생성. (히스토리를 유지하면서 변경 사항을 되돌리기 때문에, 공동 작업에서 유용한 명령어이다.)
12. git hub
Git을 사용하는 프로젝트를 지원하는 웹 기반 호스팅 서비스. 즉, 코드를 온라인으로 저장하고 관리하며, 여러 사람이 동시에 작업을 할 수 있다.
1. 코드를 클라우드에 저장하고 언제든지 접근이 가능하다. 또한, 다른 사용자와 코드 공유를 할 수 있음.
2. 프로젝트의 과거 시점 또는 변경 사항을 비교할 수 있음.
3. 코드를 공유하고 다른 사용자와 협업을 진행할 수 있음.
4. 버그 추적, 기능 개발, 작업 할당, 프로젝트 진행 상황 관리 가능.
5. 다양한 개발 도구와 연동이되고, 사용자 정의 스크립트 또는 앱을 통해 기능 확장이 가능.
13. git fetch, git pull
원격 저장소에서 정보를 가져오는 명령어들.
14. Collaborator
git hub에서 프로젝트는 repository형태로 관리되는데, repository의 소유자 또는 관리자는 다른 git hub 사용자를 Collaborator로 초대할 수 있음.
즉, collaborator는 해당 프로젝트에 기여하는 사람들을 말함.
1. collaborator는 소유자와 동일하게 저장소에 직접 푸시할 수 있음.
2. 저장소의 이슈를 열고 닫을 수 있음. (이슈는 프로젝트의 오류 보고/기능 추가 요청/개선 사항을 관리하는 것에 유용함.)
3. collaborator는 다른 사람들이 제출한 코드 변경사항을 검토 및 결정하는 풀 리퀘스트를 수락하거나 거절할 수 있음.
15. README.md
GitHub repositiry의 시작점. 이 파일 안에는 일반적으로 프로젝트에 대한 정보와 사용 방법을 소개하는데 사용.
보통 Markdown이라는 경량 마크업 언어로 작성됨.
16. Pull Request (PR)
개발자가 자신이 작업한 브랜치를 원격 저장소의 타켓 브랜치와 병합하는 것을 제안할 때 사용하는 기능.
1. Create a merge commit : 일반 merge와 동일. git history에서 해당 PR에 대해 상세하게 알 수 있지만, 프로젝트의 규모가 커질수록 히스토리를 알아보가 힘들어진다.
2. Rebase merge : Merge할 branch의 커밋 내역들을 그대로 옮기는 것. 히스토리를 깔끔하게 볼 수 있지만, 여러개의 커밋을 rebase merge를 했는데 충돌이 발생한다면 병합하려는 모든 커밋에서 충돌이 발생함.
3. squash merge : rebase하되, 병합할 커밋들을 하나의 커밋으로 뭉친다. 브랜치를 깔끔하게 유지하면서 자잘한 커밋을 제거 및 의미있는 커밋만으로 히스토리를 이룰 수 있는 장점이 있다.
17. Fork
다른 사람의 원격 저장소를 자신의 깃허브 계정으로 복제하는 것.
18. JAVA
1995년 발표된 객체지향 프로그래밍 언어
1. 개발자 친화적인 언어로 개발자가 반드시 필요하지 않다고 생각한 부분은 스스로 처리한다.
2. 숫자, 문자, 논리형 등의 기본 타입을 제외하고는 객체로 이루어진 객체 지향적 언어이다.
3. 컴파일 언어이면서, 인터프리터 언어이다.
4. 문법이 엄격해서 안전하다.
- 프로그램 소스코드에 프로그래머의 의견 또는 설명을 적기 위해 사용하는 것.
- 프로그램 수행에 영향을 미치지 않기 때문에, 어디에든 작성이 가능함.
- 데이터가 저장되는 곳에 이름을 붙여 놓은 것.
- 자주 사용할 값 또는 복잡한 연산의 결과값 또는 사용자의 입력값 등등의 내가 따로 보관해 두었다가 나중에 꺼내에 사용하고 싶은 값들을 담아 놓는 공간.
- 이 때, 변수에는 값을 하나 당 하나밖에 넣지 못한다. 만약 이미 값을 가지는 변수에 새로운 값을 할당 시, 기존 값이 밀려나감.
1. byte : 1byte 크기의 정수형.
2. short : 2byte 크기의 정수형.
3. int : 4byte 크기의 정수형.
4. long : 8byte 크기의 정수형.
1. float : 4byte의 실수형이며, 소수점 이하 7자리까지 표현이 가능.
2. double : 8byte의 실수형, 소수점 이하 15자리까지 표현이 가능.
boolean : 1bit의 크기를 가지고, true/false 이외에는 어떠한 값을 가지지 못한다.
char : 단일 문자를 표현할 수 있는 데이터 타입으로 홀따음표(' ')안에 문자를 한 개만 넣어서 표현. (2 byte 크기)
* String : 단일 문자들이 쭉 나열되어 있는 형태. 쌍 따옴표(" ")를 통해 여러 문자들을 한번에 묶을 수 있다.
여기서 주의할 점은 String은 기본 데이터 타입이 아닌, 클래스 타입이다.
1. 자동 형 변환
큰 데이터 타입에 작은 데이터 타입 값이 들어갈 때는 자동으로 형 변환이 발생. (값의 손실이 없기 때문에)
2. 명시 형 변환
- 자동 형 변환과는 다른 상황. 크기가 큰 데이터 타입을 작은 타입으로 내려야하기 위해서는 강제 변환을 해야한다.
- 괄호 안에 변환하고자 하는 타입을 작성해야함. ex) int num = (int) num2;
- 변환하는 과정에서 overflow 또는 값 손실이 발생할 수 있어, 신중하게 결정해야함.
변수에 값을 변경하거나 대입하는 등의 작업을 수행해 주는 여러가지 기호들
연산자의 종류
전반적인 느낀 점 (일주일 동안 한 일)
부트캠프에 들어가기전, "수업에 잘 따라올 수 있을까?"라는 막연한 걱정이 있었다.
하지만 강사님의 디테일한 진행과 수업으로 걱정은 싹 사라졌고, 할 수 있다는 자신감이 생겼다.
또한 git/github 및 java 맛보기 느낌으로 배웠는데, 생각보다 괜찮았다.
반면, 항상 느끼는 거지만 강남 출퇴근 시간대는 지옥이다. (그래도 예전에 다녔던 직장도 강남이라 그런지, 아직은 버틸만 하다. 아직은....)
좋았던 점 (좋았거나 내가 잘했던 점)
git/gitub에 대해 배우고, 이와 관련된 간단한 프로젝트를 수행함으로써, 어떻게 개발자들이 git을 이용하는지 또는 협업할 때 어떻게 하는지에 대한 윤곽이 잡혔다. 이를 바탕으로 앞으로의 협업이나 토이 프로젝트를 진행 시에 많은 도움이 될 것 같아 좋았다.
아쉬웠던 점
개념과 이론을 숙지했는데 불구하고 조별과제 진행 시, 머리가 하얘졌다. (머리로는 알겠는데, 몸이 따라주지 않는 느낌이랄까..?)
개선할 점
손에 익히기 위해 계속해서 연습 또 연습!! (+ 체력관리를 위해 운동 빈도를 늘리는 것도 덤!)
다음주 계획
- 자바 언어를 활용하여 알고리즘 문제 풀기
- git/github 친해지기
승현님의 더 많은 이야기가 궁금하다면?
👉 플레이데이터 백엔드 8기 유승현님의 블로그에서 확인해보세요!🚀
[블로그 바로 가기]