나의 독학은

[프리코스 프리뷰] 프리코스를 시작하는 비전공자를 위한 가이드 본문

회고/우아한테크코스 6기 프리코스 회고

[프리코스 프리뷰] 프리코스를 시작하는 비전공자를 위한 가이드

안종혁 2023. 10. 18. 21:19

❗각 용어마다 깊이 들어가는 정도는 비전공자가 프리코스를 하는데에 어려움이 없을 정도까지만 들어갑니다.

❗ 각 용어들은 프리코스에 맞춰 설명드림을 미리 알려드립니다.

🕶️[프리코스 과제 제출 문서 깃허브 용어 정리]

▷ fork

우아한 코스 깃허브에 있는 Repository를 자신의 깃허브로 가져오기

*자신의 깃허브로 가져오지 않으면 Repository안에 있는 코드를 수정할 수 있는 권한이 없다.

▷Repository

코드가 들어있는 폴더(파일)을 말한다. 5기 프리코스에서는 java-baseball, java-onboarding 같은 것들을 말한다.

 

ex) 흔히 알고 있는 바탕화면의 폴더를 예시로 들었습니다.

자소서 폴더에 다양한 워드 문서들이 있다. 자소서 폴더가 Repository, 워드 문서들이 수정할 코드이다.

내 바탕화면의 자소서 폴더

▷ clone

자신의 깃허브에 있는 Repository를 자신의 IDE로 수정하기 위해 내 컴퓨터(local 컴퓨터)로 가져오는 작업

 

터미널(명령 프롬프트)에서 다음 명령을 입력

git clone https://github.com/[본인 아이디]/[저장소 아이디].git

 

*저는 깃허브에서 가져온 Repository들을 쉽게 관리하기 위해서 user폴더 안에 repo폴더를 만들고 이 곳에 clone하였습니다.

repo 폴더로 이동하기 위해 폴더 이동명령어인 cd 를 사용한 모습
repo폴더에서 java-baseball Repository를 clone하는 모습

▷ branch

  • 별도의 공간을 하는 만들어주는 작업
  • 사람이 동일한 소스 코드를 기반으로 서로 다른 작업을 할 때 동시에 다양한 작업을 할 수 있게 만들어주는 기능이다.
git checkout -b [본인 아이디]

이해를 쉽게 하기 위해서, 실무에서의 예를 들겠습니다.

master는 서비스에 적용되는 코드들이 모여있는 곳입니다. 만약, 시니어 개발자가 신입사원에게 서비스에 검색 기능을 추가하라고 말했습니다.

이 때, 신입사원이 master를 직접 건드린다면 엄청 혼납니다. 왜 일까요?

에러가 있을수도 있는 신입사원의 코드가 서비스에 직결되어 서비스가 터질 수도 있기 때문입니다.

그러니, 신입사원이 안전하게 코드를 작성할 수 있게 별도의 공간을 만들기 위해서 branch를 하는 것입니다.

▷ Gradle

빌드 도구 중 하나입니다.

빌드란?

우리 쉽게 읽을 수 있는 자바의 소스 코드를 컴퓨터의 언어인 바이트 코드(0과 1)로 바꾸기 위해 컴파일하여 실행 가능한 형태로 바꿔주는 것입니다.

 

이러한, 빌드를 도와주는 도구가 Gradle과 Maven 입니다. Maven의 기존 구조를 따르며 성능을 개선한 것이 Gradle이기 때문에 Maven을 쓰지 않고 Gradle을 빌드 도구로 사용합니다.

 

➡️여기서 부터는 안 읽으셔도 프리코스를 진행하는데 어려움이 없을 것입니다!

 

그렇다면, Gradle이 없으면 빌드 과정 중 하나인 컴파일이 안되는 것인가? 라는 의문을 가질 수 있습니다.

하지만, 우리는 이미 정답을 알고 있습니다!!

그 동안 Gradle이 없이도 인텔리제이 자체에서 제공하는 빌드 도구인 IntelliJ IDEA로 컴파일을 해왔기 때문입니다.

 

Gradle을 알게 되었으니 이제는 어떤 빌드 도구로 빌드 해야할지 선택의 순간이 왔습니다. 이를 알려면 둘의 빌드 방식에 대해 알아야 할 것입니다.

😊IntelliJ IDEA의 빌드 방식은 증분 빌드이지만, Gradle은 증분 빌드가 아닙니다.

 

증분 빌드란 변경된 부분만 빌드를 하는 방식으로 변경되지 않은 부분은 건너뛰는 방식으로 IntelliJ IDEA가 Gradle보다 빌드를 더 빠르게 수행할 수 있다는 장점이 있습니다.

 

하지만, 증분 빌드에도 단점이 존재합니다. 증분 빌드는 변경된 클래스만 컴파일을 하기 때문에 삭제된 파일(클래스)에 대해서는 컴파일을 하지 않을 수 있다는 것입니다.

 

즉, src에서 수정한 코드를 컴파일 했을 때, 빌드 결과물이 있는 out 폴더에 반영이 되지 않을 수 있다는 것입니다. 

*IntelliJ IDEA로 빌드했다면 빌드 결과물은 out 폴더에, Gradle로 빌드했다면 빌드 결과물은 build 폴더에 생성됩니다.

 

이런 단점은 정확한 빌드를 원할 때, 문제가 생깁니다. 코드를 작업하는 src 폴더에서 파일를 지웠다 생각해도 IDEA로 빌드한다면 IDEA입장에서는 우리가 삭제한 파일을 빌드에 반영하지 않고, 여전히 남아있다고 판단해서 오류를 일으킬 수 있는 것입니다. 이 때 생기는 오류는, src에서 삭제한 파일을 out 폴더에서도 똑같이 삭제해주면 해결 될 것입니다.

build 폴더, out 폴더, src 폴더가 있는 모습

✅ 결론

정확하게 빌드를 해야하고 실제로 실행하거나, 프로젝트 크기가 크다면 Gradle을 선택하고, 테스트 혹은 프로젝트 크기가 작거나, 삭제 파일이 없어서 ReBuild를 해도 된다면 속도가 더 빠른 IntelliJ IDEA를 사용하면 되겠습니다.

 

프리코스에서는 요구사항과 구현에만 집중 할 수 있는 것과 같이 원활한 진행을 하기 위해 정확한 빌드에 도움을 주는 Gradle을 사용하는 것이 아닐까 생각해 봅니다.

 

추가로, Gradle의 장점입니다.

  • 정확한 빌드를 지원하기 때문에 대규모 프로젝트의 사용되어 번거로움과 실수를 줄여 쉽게 개발할 수 있습니다.
  • 라이프사이클을 관리할 수 있습니다. (프로젝트를 빌드하거나 배포할 때 어떤 단계를 거칠지 추가할 수 있다) 

▷ gradlew.bat clean test

  • gradlew.bat clean test : Gradle 빌드 도구를 사용하여 프로젝트를 정리(clean)하고 테스트(test)를 실행하는 명령어

gradlew.bat : Gradle Wrapper 스크립트를 실행하는 명령어

*Wrapper : Gradle을 로컬에 설치하지 않고, Gradle 버전에 구애받지 않고, Gradle 빌드를 실행할 수 있게 해주는 역할.

*스크립트 : 연극에서 배우가 어떻게 행동할 지를 지시하는 것을 스크립트라 하는 것처럼, 소프트웨어를 어떻게 실행할 지 지시하고 제어하는 것

 

clean : 이전 빌드에서 생성된 파일 및 빌드 결과물을 제거하고 프로젝트 디렉토리를 초기 상태로 되돌림. 이를 통해 빌드에서 이전 결과의 영향을 제거하고 깨끗한 상태에서 새로운 빌드를 시작할 수 있음.

 

test : 프로젝트의 테스트 코드를 컴파일하고 실행하여 코드의 동작을 확인하고 유지 관리를 수행

▷ add . (add -A)

프리코스에서는 기능 단위로 커밋을 하라는 요구사항이 있기 때문에, 변경된 코드들을 한 번에 커밋하는 'add .' 와 add -A는 잘 쓰이지 않을 것이라 생각듭니다.

 

개인적으로 인텔리제이의 커밋 기능을 이용하시는 것을 추천드립니다!!

▷ commit

[commit 설명]

commit은 '던지다, 보내버리다' 란 뜻으로 코드를 작성하거나 변경할 때와 같이 작업한 내용을 메시지와 함께 기록으로 남기는 것입니다.

 

➡️커밋 방법으로 터미널을 이용하는 방법과 인텔리제이를 이용하는 방법이 있습니다. 

1. 터미널에서는 다음과 같은 메시지와 명령어로 커밋을 합니다.

git commit -m "큰 따옴표 안에는 커밋메시지가 들어갈 공간"

 

2. 인텔리제이에서는 다음과 같이 커밋을 합니다.

(단, 프로젝트가 깃과 연결되어 있고, 인텔리제이도 깃과 연동되어있어야 합니다. 연동 방법은 이 링크 참고해주세요~)

인텔리제이에서 커밋하는 모습

변경된 파일들 중 커밋하고 싶은 파일을 Changes에서 체크하고, Amend에 메시지를 남겨서 commit 버튼을 누르면 되겠습니다.

 

[commit 메시지 설명]

커밋 메시지는 docs, feat, refactor와 같은 <type>과에 작업한 내용에 해당하는 <body>로 구성되어 있습니다.

 

먼저 <type> 은 해당 커밋의 특징을 나타냅니다.

- feat : 새로운 기능을 구현 했을 때의 커밋

- docs : 문서 수정에 대한 커밋

- test : 테스트 코드에 대한 커밋

- refactor : 코드 리팩토링에 대한 커밋

 

<body>는 커밋 메시지의 본문으로 <type>에 대한 특징을 좀 더 상세히 적습니다.

[커밋 메시지를 잘한 예시] 커밋 메시지가 깃허브에 반영된 사진

❗로컬(IDE나 터미널)에서 commit 명령을 실행하면 원격 저장소인 깃허브에는 반영되지 않습니다. 위 사진처럼 깃허브에 반영이 되려면 push를 추가적으로 해줘야 합니다.

▷ push

원격 저장소인 깃허브에 커밋한 내용들을 반영하기 위한 명령어 입니다.

git push origin [브랜치이름]

▷ Pull Request

자신의 브랜치에서 작업한 코드를 우아한 코스 깃허브에 반영하기 위한 작업입니다.

 

✅지금까지의 내용을 직접 연습하고 싶으시면 이 영상 참고하셔서 진행하면 됩니다!

🕶️[ReadMe.md 문서]

▷ 인텔리제이에서 README.md 생성하기

[README.md는 프리코스에서 요구하는 기능 목록을 작성할 때 쓰입니다]

 

1. 프로젝트 창에서 마크다운 파일을 만드려는 디렉토리를 선택해서 마우스 우클릭하기

2. New의 File을 클릭

docs폴더에 README.md를 생성하는 모습

3. 파일 이름에 .md 또는 .markdown 을 사용하여 이름 설정

.md 확장자를 붙여 작성하는 모습

4. docs폴더에 ReadMe.md가 생성된 모습

docs에 기능 목록을 작성할 ReadMe가 생성된 모습

▷ README.md 작성하기

[작성법]

# : 제목, 부제목 작성 ( #이 많아질수록 글씨 크기가 줄어듬)

** : 굵은 글씨로 강조

- : 글머리 생성

 

ex 1) 변경 전 마크다운으로 작성한 문서

변경 전

ex 2) 변경 후 완성된 모습

변경 후

✅인텔리제이 탭칸의 오른쪽에 보면 Editor and Preview를 누르면 변경 전과 후를 동시에 확인할 수 있습니다.

😁 마치며

비전공자분들은 저처럼 정말 막막할 것이라고 생각합니다. 깃헙 사용 용도부터, 책에 있는 예제 코드들을 따라치는 용도였던 IDE의 다양한 사용 방법까지 프리코스를 시작하기 전부터 새로 학습할 내용이 많을 거라 생각합니다. 이 어려움을 조금 덜어드리고자 학습한 내용을 정리할 겸 글을 포스팅 했습니다.

개인적으로는 직접 찾아보시는 것이 제가 정리한 글에 있는 내용보다 훨씬 더 많은 것을 알게 될 것입니다. 그렇기에 제 글은 도움용으로 쓰시면 좋겠습니다!