[우아한 테크 코스] 6기 프리코스 1주차

우아한 테크 코스 6기 - 프리코스 1주 차

부제 : 시험기간 중 프리코스요? 내가 해본 밤 샘 중 최고였어요.

두둥 과제 발표

 

프리코스 1주 차가 끝나자마자 호다닥 후기? 회고? 감사합니다? 를 쓰는 중이다.🫠

지난 기수 문제를 풀어보면서 시험기간에 진행되긴 하지만 온보딩 문제가 1주 차면 할만한데~? 생각을 했다.

ㅎ...

응아니야~

프리코스는 내게 1주 차부터 숫자 야구 게임을 미션으로 주었고 일단 당황했다. 아주 조금. 많이.

그래도 5기 프리코스의 2주 차 문제라 풀어본 적이 있어서 비교적 가벼운 마음으로 시작하긴 했다.

한 달 동안 기다려온 프리코스라 그런가 스터디원들 모두 설렘을 갖고 파이팅을 외치며 시작했다. (귀여워...)

 

과제 시작

 

마음의 준비라는 것을 하고 후하후하ㅜ

확실히 한번 풀어봤다고 패키지를 나누고 기능별로 구현하는 게 익숙해진 느낌이었다. 처음 풀었을 땐 클래스 2개였나,,3개에 다 때려 넣고 와랄라 작성했던 것 같은데 이번엔 MVC 까진 아니지만 View와 Model 정도만 따로 분리하여 구현해 보았다.

미션이 그나마 쉬워서 망정이지 시험기간이랑 겹쳐버리니 구현할 시간을 따로 정하고 시험공부도 하려고 하다 보니 조급함이 생기기도 했다.

약간 매일을 결심한 날로 살았다 ㅎㅎㅎㅎ

스터디로 풀어볼 때랑 다르게 찐 과제 제출용이라고 생각하니 요구사항이나 컨벤션 등을 수십 번은 더 보고 체크했던 것 같다.

이번 우테코 프리코스는 디스코드방이 생겼는데 여기서 자바 코드 컨벤션과 관련해 꽤나 유용한 글을 발견해 공유해 본다.

 

자바 코드 설정

[IntelliJ] 코드 스타일을 설정해보자 (feat.우테코)

 

기능별로 구현할 때마다 커밋을 하는 걸 추천한다고 본 적 있어서 커밋 역시 커밋 컨벤션을 지켜보려고 노력했다. 

커밋과 관련된 공식 문서가 있긴 하지만 아래의 글이 한국말로 너무나 친절히 잘 설명되어 있어서 첨부한다.

 

Commit Message

[Git] 커밋 메시지 규약 정리 (the AngularJS commit conventions)

 

기능 구현 자체는 토요일쯤 다 끝냈다. 구현을 다 끝내고도 계속 아쉬운 점이 보이고 갈아엎을지 말지 고민하게 되고... 고민의 연속이었지만 내가 지금 할 수 있는 최선만큼 리팩터링 하고 앞으로 남은 미션들에서 아쉬웠던 점들을 고쳐나가야겠다는 생각을 했다.

 

과제 결과

테스트 짱 신기..

1주 차 과제 코드는 아래에!

https://github.com/coenfflOo/java-baseball-6/tree/coenfflOo

GitHub - coenfflOo/java-baseball-6

어우 근데 방금 올리면서 확인해 보니 fork 수가 2.8K... pull request 수는 2.5K...

아니 선생님들 경쟁률 머선일이냑우요😨

프리코스만으로도 배워가는 게 많다고는 하지만 저는 그냥 대놓고 말하겠습니다.

프리코스에서 끝나지 않고 우테코 하고 싶어요. 

남은 과제도 열심히 해야겠다.... 후엥

---

- README.md에 올리진 못하겠고 그렇다고 혼자 남겨두자니 아까워 써보는 소감

🔍  소감

프리코스의 시작을 알리는 첫 번째 과제였습니다. 미션 구현 자체에는 어려움이 없었지만 조금 더 가독성이 좋고 깔끔한 코드로 구현하려 하다 보니 자연스레 많은 것들을 배우고 익히는 과정에서 리팩토링이 이루어졌습니다. 첫 주차임에도 많은 걸 배워나가는 것 같아 앞으로의 3주도 기대가 됩니다.

 

☻ 잘한 점 & 배운 점 & 알게 된 점

 

JAVA 17 환경 설정

: JAVA 17 환경 설정은 프로젝트를 시작할 때 가장 첫 번째 단계였습니다.

• OpenJDK 17 설치를 위해 기존에 설치되어 있던 Homebrew를 사용하여 OpenJDK를 설치하고 경로를 추가한 뒤, 환경 변수를 업데이트했습니다. 이 과정에서 환경 설정이 올바르게 이루어지지 않으면 Java 애플리케이션을 실행하는 데 문제가 발생할 수 있으므로 신중하게 수행해야 했습니다. 항상 이 단계에서 많은 어려움을 느껴 걱정이 많았지만 프리코스 시작 직전 자바 버전을 바꿔본 경험을 떠올리며 그때보다 쉽게 할 수 있었습니다.
• JDK를 직접 다운로드하여 로컬에 설치하고 경로를 설정해서 경로를 찾는 것이 어려웠는데 이번엔 홈브루로 설치하고 심볼링 링크를 생성한 다음 경로를 설정하니 비교적 쉬웠습니다.

 

패키지 분리하기

: 패키지 분리는 코드를 체계적으로 구성하는 데 중요한 역할을 합니다. 이번 미션에서는 패키지를 효율적으로 분리하는 방법을 연습했습니다.

• 다른 지원자들의 대화를 보았을 때, OOP, TDD, MVC, DTO 등 다양한 형태로 코드를 구현하는 것 같았습니다. 프론트엔드로 프로젝트를 했을 때에도 저런 용어들을 많이 접하진 않았고 코드를 분리하긴 했지만 함께 협업했던 팀원의 코드에 맞추어 작성했던 것입니다. 위의 용어들을 검색해 보면서 그 당시 구현 패턴이 MVC, DTO와 유사하다는 것을 알았고 MVC 패턴을 완벽히 구현하진 못하더라도 최대한 비슷하게 기능을 분리하는 연습을 해보고 싶다는 생각을 했습니다.
• 그래서 데이터들을 생성 및 관리하는 Model 패키지와 입출력을 담당하는 View 패키지를 추가하여 구현해 보기로 했습니다. Model에서는 컴퓨터의 수를 생성하고 야구게임을 진행할 때 사용되는 수들을 상수로 지정하여 담는 클래스를 별도로 지정해 두었습니다. View에는 입력받는 클래스, 출력하는 클래스를 두어 터미널에 나타나는 모든 부분을 관리하도록 하였습니다. 예외 처리를 담당하는 클래스도 View라고 생각하여 수정하였습니다.
• Model과 View로 패키지를 분리하여 구현을 하니 구현을 하는 과정에서도 필요한 메서드나 변수를 찾기 더 쉬웠습니다. 추후에 리팩토링을 할 때에도 어떤 기능을 위해 만든 클래스인지 확인할 수 있으니 유지보수에도 용이했습니다.

 

상수

: 상수는 프로그램에서 반복적으로 사용되는 값을 중앙에서 관리하고자 할 때 중요합니다.

• 이번 미션에서는 게임의 상수와 메시지를 별도의 상수 클래스로 분리하여 관리했습니다. 이를 통해 상수를 한 곳에서 수정하면 모든 관련 코드에 적용되어 유지보수가 용이해졌습니다. 또한, 코드에서 매직 넘버를 사용하지 않아 가독성이 향상되었습니다.
• 자바로는 알고리즘과 같은 문제만 풀어보았기에 상수를 사용한다는 개념이 없었습니다. 하지만 다른 스터디원들과 코드리뷰를 하며 상수를 정말 많이 사용하길래 왜 상수를 사용해야 하지?라는 의문이 들었습니다. 그래서 상수에 대해 조금 더 공부를 해보게 되었고 그 과정에서 상수의 사용이 다른 사람들과의 협업에서 용이할 뿐만 아니라 불필요한 코드의 중복을 줄여줄 수도 있는 등 다양한 면에서 가독성을 높여준다는 것을 알게 되었습니다.

 

정규식

: 정규식은 입력값을 검증하거나 패턴을 찾을 때 유용한 도구입니다.

• 사용자 입력값의 유효성을 검사하기 위해 정규식을 활용했습니다. 정규식을 사용함으로써 코드의 간결성과 정확성이 향상되었습니다. 또한, 유효성 검사에 대한 로직을 명확하게 표현할 수 있어 가독성이 향상되었습니다.
• 숫자인지 아닌지 확인하고, 3자리의 숫자를 입력했는지 등을 모두 정규식으로 판별할 수 있다는 것은 놀라웠습니다. 코드 리뷰를 주고받으며 정규식이 훨씬 더 다양하게 구현할 수 있다는 것을 알게 되었고 리팩터링 하며 적용해 보았습니다. 덕분에 코드가 더 간결해졌고 예외처리가 더 쉬워졌습니다. 정규식에 대해 더 알아보고 기술 블로그에 작성하며 공부하는 계기가 되었습니다.

 

스트림

: 스트림은 Java에서 데이터를 처리하는 강력한 도구 중 하나입니다.

• 처음에는 split()을 하여 그 길이로만 개수를 확인했습니다. 하지만 스트림을 활용하여 중복된 값 검증 및 리스트의 각 요소 검사 등 다양한 작업을 수행할 수 있다는 것을 알게 되었습니다. 리팩토링 결과 스트림을 사용함으로써 코드가 간결해지고 반복 작업을 줄일 수 있었습니다.

 

☺︎ 오류 해결

 

GitHub 패스워드 인증 오류

• 소스트리만 사용해 보다가 터미널을 이용해 깃에서 clone 하고 commit, push 하는 것을 처음 해보았습니다. clone까지는 문제없이 했으나 저의 프로젝트를 GitHub에 commit&push를 하려고 시도할 때 "Support for password authentication was removed" 오류 메시지를 만났습니다. 이 오류는 특정 날짜 이후로 GitHub에서 패스워드 인증을 사용할 수 없다는 것을 의미합니다. 처음에는 무슨 오류인지 몰라 구글링을 해보았습니다. 먼저, GitHub에서 기존의 개인 액세스 토큰을 삭제한 뒤 다시 생성하고 이를 사용하여 Git을 통한 인증을 시도했습니다. 개인 액세스 토큰을 생성하고 Git 푸시 작업에서 사용하니 문제가 해결되었습니다. 이 경험을 통해 안전한 방식으로 코드가 관리되는 것이라고 생각되었습니다. 개인 액세스 토큰을 사용하면 계정 보안을 강화하고 기존의 패스워드 인증 문제를 해결할 수 있었습니다.

 

Application.main() 실행 오류

• 코드를 모두 구현하고 테스트 전 저의 프로젝트를 실행할 때, "Execution failed for task ':Application.main()'" 오류가 발생했습니다. 이 오류는 프로젝트의 코드 중에서 잘못된 위치에서 메서드를 참조하여 발생한 것으로 보였습니다. 오류 메시지의 스택 트레이스를 확인하고, 어떤 예외가 발생했는지 파악했습니다. 해당 잘못된 참조로 인해 실행문이 무한 루트에 빠진 것이 원인이었습니다. 그런 다음, 코드를 검토하여 잘못된 메서드 위치를 수정하였습니다. 이러한 수정을 통해 오류를 해결했습니다. 프로젝트를 유지보수하고 디버그 할 때 오류 메시지와 스택 트레이스 정보를 이해하고, 코드를 신중하게 검토하는 것이 수정에 많은 도움이 된다는 것을 깨달았습니다. 다음부터 알 수 없는 오류가 발생하더라고 스택 트레이스 정보를 먼저 찾아보거나 오류 지점을 파악하여 오류 메시지를 출력하며 코드를 수정해 가는 것이 좋겠다는 생각을 했습니다.

 

☹︎ 아쉬운 점

기능 구현에만 우선적으로 집중하여 구현하다 보니 구현을 모두 끝낸 시점에서 computer와 player의 역할을 나누어 구현했다면 더 좋았을까 하는 아쉬움도 남았고, 예외처리나 입출력을 하는 부분에서 불필요하거나 중복적인 코드가 있었던 것 같아 아쉽게 느껴졌습니다. 예외 처리 메서드의 반환형을 불린으로 두어 하나의 조건이 되게 하는 등 반환형을 더 고려하여 구현했다면 좋을 것 같다는 생각도 했습니다. 다음 미션에는 생성자 개념도 적용하여 풀면 더 좋은 코드를 짤 수 있을 것 같습니다.