[우테코 5기 프리코스] 1주차: java-onboading

우아한테크코스 5기 백엔드에 지원하여, 프리코스에 참가하게 되었다. 1주차는 git과 친해지는 시간이었다.

---

우선, Github fork 통해 내 레퍼지토리에 저장했다.

IntelliJ의 터미널을 사용해 git clone 을 진행했다.

git clone <https://github.com/Lee-SungMin/java-onboarding.git>

git status 를 통해 잘 받아왔음을 확인하였다.

IntelliJ의 터미널을 사용해 git clone 을 진행했다.

git clone <https://github.com/Lee-SungMin/java-onboarding.git>

git status 를 통해 잘 받아왔음을 확인하였다.

 

Git branch를 활용하는 방법을 구체적으로 알기 위해서, Git flow에 대해서 알아 보았다.

아래는, 참고 자료한 자료들이다. 특히 아래 블로그들이 정말 정리가 잘 되어 있다. 도움을 많이 받았다.

https://github.com/DoTheBestMayB/UpbitAPI/issues/2

git branch 전략은 왜 사용할까? · Issue #2 · DoTheBestMayB/UpbitAPI

[GIT] 📈 깃 브랜치 전략 정리 - Github Flow / Git Flow

[GIT] 📈 깃 브랜치 전략 정리 - Github Flow / Git Flow

Git-Flow & Commit message & Issue 이용해서 협업하기

Git-Flow & Commit message & Issue 이용해서 협업하기

Git Branch & Tag를 활용한 프로젝트 배포 전략 마련하기

Git Branch & Tag를 활용한 프로젝트 배포 전략 마련하기

 

branch는 주로 아래와 같은 방식으로 사용된다.

 

 

master(main) : 제품으로 출시될 수 있는 브랜치
develop : 다음 출시 버전을 개발하는 브랜치
feature : 기능을 개발하는 브랜치, develop 브랜치에 들어간다.
release : 다음 버전을 준비하는 브랜치, develop 브랜치를 release 브랜치로 옮긴 후 QA, 테스트를 진행하고 master 브랜치로 합친다.
hotfix : 출시 버전(master 브랜치)에서 발생한 버그를 수정 하는 브랜치

 

master와 develop은 일반적으로 본래 이름 그대로 사용한다.

feature : feature/{기능 요약} 혹은 feature/{issue-number}-{기능 요약}

release : release-{버전} 혹은 release/{버전}

hotfix : hotfix-{버전}

→ 항시 유지되는 메인 브랜치: master, develop / merge되면 사라지는 보조 브랜치: feature, release, hotfix

 

Git Flow는 주로 아래와 같은 방식으로 진행한다.

 

develop 브랜치에서 feature 브랜치를 생성

→ feature 브랜치에서 기능 추가 작업이 완료되면 develop 브랜치로 merge

→ develop에 이번 버전에 포함되는 모든 기능이 merge 되었다면 QA를 하기 위해 develop 브랜치에서부터 release 브랜치를 생성

→ QA를 진행하면서 발생한 버그들은 release 브랜치에 수정

→ QA를 무사히 통과했다면 release 브랜치를 master와 develop 브랜치로 merge

 

*주의점: github를 최근에 사용한 사람이 아니라면, 기본 설정 브랜치가 master가 아니라 main인 것에 당황할 것이다.

이 부분을 조심하여 git 을 사용해야한다.

 

이번 1주차 미션을 진행할 때, 아래와 같은 flow로 진행할 것이다.

나는 문제 하나 하나를 기능 하나로 나누어 보았다. (문제마다 요구하는 기능 사항이 다르기 때문에, 각기 다른 기능을 구현해야 하는 것이므로, 하나의 feature 브랜치로 묶지 않고 여러 브랜치로 따로 작업 해야한다고 생각했다.)

→ 하지만, 문제 하나만을 기능 하나로 보면 안되고 문제 하나에서도 구현해야할 기능을 세부적으로 나눌 수 있기 때문에, 이후에 이렇게 생각한 것은 하루 뒤인 3일차에 잘못되었다는 것을 깨달았다.

 

따라서, develop에서 문제마다 feature 브랜치로 분기하여 작업하고 develop 브랜치에 merge 한다.

그 후, develop 브랜치에서 release 브랜치를 생성하고 QA 작업을 거친다. (새로운 버전을 맞이할 준비가 되었다.)

QA 작업이 잘 완료 되었다면 main branch로 merge하여 버전을 업그레이드 한다.

 

우선, develop branch를 생성하고 잘 생성되었는 지 확인했다.

git branch develop

# r 옵션으로 remove branch를 확인
git branch -r

# a 옵션으로 모든 branch를 확인
git branch -a

git checkout [브랜치명] 을 통해 해당 [브랜치명] 브랜치로 이동할 수 있다.

git checkout develop

git push origin [브랜치명] : 해당 브랜치명으로 이동하여 명령어를 사용하면, 원격 저장소인 github로 적용되는 것을 확인할 수 있다.

git checkout origin develop

 

본격적으로, 브랜치를 다루기 전에 아래 블로그들을 통해 어떻게 적용하는 지 알아보자.

https://velog.io/@j1mmyson/Git-Git-Branch-어떻게-쓰는걸까

[Git] Git Branch 어떻게 쓰는걸까?

https://velog.io/@kim-jaemin420/Git-branch-naming

Git branch & naming

https://mylko72.gitbooks.io/git/content/branch/branch_type.html

브랜치의 종류 · Git, 분산버전 관리시스템

 

feature branch 는 아래와 같은 형식으로 진행한다.

// feature 브랜치(feature/login)를 'develop' 브랜치('master' 브랜치에서 따는 것이 아니다!)에서 분기
$ git checkout -b feature/login develop

/* ~ 새로운 기능에 대한 작업 수행 ~ */

/* feature 브랜치에서 모든 작업이 끝나면 */
// 'develop' 브랜치로 이동한다.
$ git checkout develop

// 'develop' 브랜치에 feature/login 브랜치 내용을 병합(merge)한다.
# --no-ff 옵션: 새로운 커밋 객체를 만들어 'develop' 브랜치에 merge 한다. 
# 이것은 feature 브랜치에 존재하는 커밋 이력을 모두 합쳐서 하나의 새로운 커밋 객체를 만들어 'develop' 브랜치로 merge 되는 것이다.
$ git merge --no-ff feature/login

// -d 옵션: feature/login 에 해당하는 브랜치를 삭제한다.
$ git branch -d feature/login

// 'develop' 브랜치를 원격 중앙 저장소에 올린다.
$ git push origin develop

// 원격저장소(깃허브)에서도 브랜치를 삭제해준다.
$ git push origin --delete feature/login

develop branch 에서 1번 문제 기능 구현을 담당할 feature/problem_1 branch 를 생성하고 잘 생성되었는지 확인한다.

git branch feature/problem_1

⚠️ 트러블 슈팅

1번 문제를 해결하고, 1번 문제에 대한 테스트를 실행할 때 아래와 같은 문제가 발생했다.

Failed to calculate the value of task ':compileJava' property 'javaCompiler'.
SystemInfo is not supported on this operating system.

JDK 버전이 맞지 않아서 나온 문제였다. 아래 블로그를 똑같이 따라해서 JDK 17 → JDK 11로 바꿔 해결했다.

참고 링크: https://milenote.tistory.com/63

[Intellij / 인텔리제이] 프로젝트 버전 안맞는 현상 ( Execution failed for task ':compileJava'. )

 

그렇게 1번 문제를 해결하고, 다시 test 를 진행했다.

무사히 통과 됐음을 확인할 수 있었다.

 

이제, 파일을 add 하고 커밋 메시지를 작성하기 전 어떤 식으로 커밋 메시지를 작성할지 아래 블로그를 참고하여 규칙을 정한 후 진행한다.

https://velog.io/@palza4dev/TIL-28.-GitGithub-커밋-메시지-작성법

TIL 28. Git&Github 깃 터미널 명령어와 커밋 메시지 작성법

https://velog.io/@u-nij/Git-Flow-Commit-message-Issue-이용해서-협업하기

Git-Flow & Commit message & Issue 이용해서 협업하기

[ commit message 규칙 ]

Add: 레이아웃 / 기능 추가

Remove: 내용 삭제 (폴더 / 파일 삭제)

Modify: 수정 (JSON 데이터 포맷 변경 / 버튼 색깔 변경 / 폰트 변경)

Fix: 버그/오류 해결

Refactor: 코드 리팩토링 (멘토 리뷰 반영 / 스스로 리팩토링 / 중복 코드 제거 / 불필요 코드 제거 / 성능 개선)

Docs: 문서에 관련된 수정작업(README.md 등)

git commit -m “내용” 을 통해 commit 한다.

git commit -m "타입: 내용 요약
기능 구현 1
기능 구현 2
"

develop branch 에서 feature 브랜치를 merge 한다.

그 후, feature branch 는 삭제하고 develop branch 에 push 한다.

원격 저장소에 있는 feature branch 도 지워준다.

# develop branch 로 이동
git checkout develop

# feature branch 의 내용을 develop branch 에 병합
git merge --no-ff feature/problem_1

# local 에 있는 feature branch 삭제
git branch -d feature/problem_1

# develop branch 에 push
git push origin develop

# 원격 저장소에 있는 feature branch 도 삭제
git push origin --delete feature/problem_1

github 를 통해 확인해보면, 아래와 같이 develop branch 에 잘 적용된 것을 확인할 수 있다.

또한, IntelliJ의 하단에 있는 git log 를 통해 branch graph 를 확인할 수 있다.

develop branch에 1번 문제의 기능 구현을 완료하였다.

 

*추가 작업 사항

1번 문제를 develop branch 에 넣고 뒤늦게 깨달은 점이 있다.

문제별로 기능을 구현하는 것도 맞다고 볼 수 있는데, 한 번에 구현하지 말고 그 과정속에서도 세부적으로 기능을 나누어 작업해야 한다.

1번 문제는 일단 이렇게 진행해두고, 2번 문제 이후로는 더 세부적으로 나누어 commit 하고 브랜치 작업을 진행해야 할 것 같다.

나중에 리팩토링 과정에서 1번 문제를 다시 진행해야 할 것 같다.

 

클린 코드를 작성하기 위해 아래 블로그들을 참고하고, release 단계에서 작업을 진행해 주어야 할 듯하다.

woowacourse-docs/pr_checklist.md at main · woowacourse/woowacourse-docs

GitHub - woowacourse/woowacourse-docs: 우아한테크코스 문서를 관리하는 저장소

[우테코] [프리코스] 클린 코드 체크 리스트 읽기

[우테코] [프리코스] 클린 코드 체크 리스트 읽기

TIL/google java style guide.md at master · binghe819/TIL

GitHub - binghe819/TIL: 📚 Today I Learned. 기록하자.

 

예외 처리(입력으로 들어오는 값들에 대한 예외처리)를 세부적으로 구현해야 할까 싶어서, custom exception 을 알아보았다.

custom exception을 언제 써야 할까?

custom exception을 언제 써야 할까?

무분별한 커스텀 예외 정의

무분별한 커스텀 예외 정의

→ 제한 사항: 이미 한 번 거치고 온 입력값들이기 때문에, 내가 따로 예외 사항으로 구현하는 것은 오버프로그래밍이며 비효율적이다.

→ 즉, 제한 사항에 없는 예외만 처리해주도록 하자.

 

본격적인 개발에 들어가기 전에, 기능 요구 사항을 작성해보았다.

예외 사항을 다 적어놓았지만, 위와 같은 이유로 구현하지 않았다.

 

1번
[x] 페이지 번호의 각 자리 숫자를 모두 더하는 기능
[x] 페이지 번호의 각 자리 숫자를 모두 곱하는 기능
[x] 가장 큰 수를 구하는 기능(4번 과정)
[x] 점수를 비교하여 가장 높은 사람을 알아내는 기능(5번 과정)

2번
[x] cryptogram에서 연속되는 문자가 무엇인지 확인하는 기능
[x] cryptogram에서 연속되는 문자가 몇 개인지 확인하는 기능
[x] 한 개이면 그대로 진행, 두 개이상이면 제거
[x] cryptogram에서 연속되는 문자를 제거하는 기능

3번
[x] 숫자가 1부터 n까지 1씩 증가하는 기능
[x] 해당 숫자에 3, 6, 9가 몇 개 있는지 확인하는 기능(박수 횟수 체크하는 기능)

4번
[x] 개구리 사전에 맞게, 문자를 변환하는 기능
[x] 알파벳 외의 문자는 변환하지 않도록 처리(구분)하는 기능
[x] 알파벳 대문자는 대문자로, 소문자는 소문자로 변환하는 기능

5번
[x] 각 지폐와 동전의 개수를 넣을(확인할) 수 있는 리스트/배열 구현
[x] money를 지폐 및 동전으로 변환할 수 있도록 계산하는 함수 구현
[x] 오만 원권 부터 시작하여, 일원 동전까지 각 몇 개를 넣을 수 있는 지 확인하는 기능

6번
[x] 모든 닉네임에서, 같은 글자가(두 글자 이상) 연속적으로 있는지 확인 하는 기능
[x] 해당 이메일을 담는 리스트/배열 구현
[x] 이메일을 오름차순으로 정렬하는 기능
[x] 이메일 중복 시, 하나만 출력하는 기능

7번
[x] friends의 원소에서, user 아이디가 있는지 확인하는 기능
[x] 있다면, 몇 개 인지 카운트하는 기능(사용자와 함께 아는 친구의 수)

 

 

모든 문제를 구현하고, 성공적으로 테스트 케이스가 돌아간 것을 확인할 수 있었다.

 

자바의 기초 문법(문자열 접근법…)도 많이 까먹었었고, 자바에서의 자료구조 set, map을 사용하는 것은 처음이라 굉장히 시간이 많이 걸렸다.

 

마지막으로 배포를 위한, release 브랜치 사용법이다.

// release 브랜치(release-1.2)를 'develop' 브랜치('master' 브랜치에서 따는 것이 아니다!)에서 분기
$ git checkout -b release-1.2 develop

/* ~ 배포 사이클이 시작 ~ */

/* release 브랜치에서 배포 가능한 상태가 되면 */
// 'master' 브랜치로 이동한다.
$ git checkout master

// 'master' 브랜치에 release-1.2 브랜치 내용을 병합(merge)한다.
# --no-ff 옵션: 위의 추가 설명 참고
$ git merge --no-ff release-1.2

// 병합한 커밋에 Release 버전 태그를 부여한다.
$ git tag -a 1.2

/* 'release' 브랜치의 변경 사항을 'develop' 브랜치에도 적용 */
// 'develop' 브랜치로 이동한다.
$ git checkout develop

// 'develop' 브랜치에 release-1.2 브랜치 내용을 병합(merge)한다.
$ git merge --no-ff release-1.2

// -d 옵션: release-1.2에 해당하는 브랜치를 삭제한다.
$ git branch -d release-1.2

최종적으로, git log 를 확인할 수 있다.

github 에는 main 과 develop branch 만 남게된다.

리팩토링 하기 전, tag 를 사용해 저장하고, 리팩토링 한 후에도 tag 를 통해 저장하여 버전 관리를 했다.

그리고, pull request를 통해 github에 제출하고 홈페이지에도 제출 완료!

---

이번 과제는 전공자에게도 조금은 벅찼던 1주차였던 것 같습니다.

그래서, 비전공자이신 분들은 미션을 진행하는 데 더 많이 고되실 것 같다는 생각이 들었습니다.

 

저는 나름 학교 프로젝트로 git, github 를 통해 협업을 하면서 어느 정도 branch 을 사용해본 경험이 있습니다.

그러나, 이렇게 '혼자서' 구체적으로 기능 별로 branch 를 나눠가며 작업해 본 것은 이번이 처음이였습니다.

그래서, 이번 기회를 경험으로 branch 를 조금 더 이해하고 직접 부딪혀가면서 점차 체득할 수 있었습니다.

 

또한, 단순히 문제를 푸는 것 뿐 만 아니라, 자바의 클린 코드 컨밴션을 지켜가며 코딩하는 것은 정말 쉽지 않다는 것을 느꼈습니다.

기능 구현도 우선이지만, 규율을 지키도록 리팩토링 하는 과정은 많이 미숙했지만 도전해 보았다는 경험이 좋았던 것 같습니다.

 

1주차인데도 얻어가는 경험들이 정말 많은 것 같습니다.

2주차 미션에는 더 완벽히 구현하고 싶은 욕구가 생기네요!

 

이렇게, 배울 수 있고 성장할 수 있는 기회를 주셔서 정말 감사합니다.