3주 차 미션에서는 클래스 분리, 단위 테스트를 시작해 보는 것으로 과제를 진행했지마, 이번 4주 차 미션에서 작성하는 실습 과정의 목표는 다음과 같다.

1. 클래스(객체)를 분리하는 연습
2. 리펙터링

3주 차에서는 클래스를 분리하는 연습에 있어서 많은 어려움을 겪었지만, 이번 4주 차에서는 클래스를 분리하는 연습을 하는 것에 있어서 큰 어려움을 느끼면서 진행할 것 같은 느낌은 들지 않았다. 좀 더 자신감 있게 과제를 진행할 수 있을 것 같다.

이번에는 하나의 기능을 만들어 놓고 테스트를 할 수 있으면 테스트를 해서 그 기능이 정상적으로 동작하는지 확인해가면서 과제를 진행하였다.

코드의 내용을 다 설명을 하게 되면 글이 너무 길어질 것 같아서 어떤 과정으로 과제를 해결했는지 설명하겠다.

기능 구현 유의사항

문제 풀기에 앞서 다음과 같은 진행 방식을 유의하면서 기능을 구현해야 한다.

• 미션은 기능 요구 사항, 프로그래밍 요구 사항, 과제 진행 요구 사항 세 가지로 구성되어 있다.

• 세 개의 요구 사항을 만족하기 위해 노력한다. 특히 기능을 구현하기 전에 기능 목록을 만들고, 기능 단위로 커밋 하는 방식으로 진행한다.

• 기능 요구 사항에 기재되지 않은 내용은 스스로 판단하여 구현한다.

  🚀 기능 요구 사항

  위아래 둘 중 하나의 칸만 건널 수 있는 다리를 끝까지 건너가는 게임이다.

• 위아래 두 칸으로 이루어진 다리를 건너야 한다.

  • 다리는 왼쪽에서 오른쪽으로 건너야 한다.
  • 위아래 둘 중 하나의 칸만 건널 수 있다.

• 다리의 길이를 숫자로 입력받고 생성한다.

  • 다리를 생성할 때 위 칸과 아래 칸 중 건널 수 있는 칸은 0과 1 중 무작위 값을 이용해서 정한다.
  • 위 칸을 건널 수 있는 경우 U, 아래 칸을 건널 수 있는 경우 D값으로 나타낸다.
  • 무작위 값이 0인 경우 아래 칸, 1인 경우 위 칸이 건널 수 있는 칸이 된다.

• 다리가 생성되면 플레이어가 이동할 칸을 선택한다.

  • 이동할 때 위 칸은 대문자 U, 아래 칸은 대문자 D를 입력한다.
  • 이동한 칸을 건널 수 있다면 O로 표시한다. 건널 수 없다면 X로 표시한다.

• 다리를 끝까지 건너면 게임이 종료된다.

• 다리를 건너다 실패하면 게임을 재시작하거나 종료할 수 있다.

  • 재시작해도 처음에 만든 다리로 재사용한다.
  • 게임 결과의 총 시도한 횟수는 첫 시도를 포함해 게임을 종료할 때까지 시도한 횟수를 나타낸다.

• 사용자가 잘못된 값을 입력할 경우 IllegalArgumentException를 발생시키고, "[ERROR]"로 시작하는 에러 메시지를 출력 후 그 부분부터 입력을 다시 받는다.

  • Exception이 아닌 IllegalArgumentException, IllegalStateException 등과 같은 명확한 유형을 처리한다.

    입출력 요구 사항

• 입력*

• 자동으로 생성할 다리 길이를 입력 받는다. 3 이상 20 이하의 숫자를 입력할 수 있으며 올바른 값이 아니면 예외 처리한다.

• 라운드마다 플레이어가 이동할 칸을 입력 받는다. U(위 칸)와 D(아래 칸) 중 하나의 문자를 입력할 수 있으며 올바른 값이 아니면 예외 처리한다.

• 게임 재시작/종료 여부를 입력 받는다. R(재시작)과 Q(종료) 중 하나의 문자를 입력할 수 있으며 올바른 값이 아니면 예외 처리한다.

출력

• 게임 시작 문구

  다리 건너기 게임을 시작합니다.

• 게임 종료 문구

  최종 게임 결과
  [ O |   |   ]
  [   | O | O ]
  

게임 성공 여부: 성공 총 시도한 횟수: 2

- 사용자가 이동할 때마다 다리 건너기 결과의 출력 형식은 실행 결과 예시를 참고한다.
  - 이동할 수 있는 칸을 선택한 경우 O 표시
  - 이동할 수 없는 칸을 선택한 경우 X 표시
  - 선택하지 않은 칸은 공백 한 칸으로 표시
  - 다리의 시작은 [, 다리의 끝은 ]으로 표시
  - 다리 칸의 구분은 |(앞뒤 공백 포함) 문자열로 구분
  - 현재까지 건넌 다리를 모두 출력
- 예외 상황 시 에러 문구를 출력해야 한다. 단, 에러 문구는 "[ERROR]"로 시작해야 한다.

[ERROR] 다리 길이는 3부터 20 사이의 숫자여야 합니다.

**실행 결과 예시**

다리 건너기 게임을 시작합니다.

다리의 길이를 입력해주세요. 3

이동할 칸을 선택해주세요. (위: U, 아래: D) U [ O ] [ ]

이동할 칸을 선택해주세요. (위: U, 아래: D) U [ O | X ] [ | ]

게임을 다시 시도할지 여부를 입력해주세요. (재시도: R, 종료: Q) R 이동할 칸을 선택해주세요. (위: U, 아래: D) U [ O ] [ ]

이동할 칸을 선택해주세요. (위: U, 아래: D) D [ O | ] [ | O ]

이동할 칸을 선택해주세요. (위: U, 아래: D) D [ O | | ] [ | O | O ]

최종 게임 결과 [ O | | ] [ | O | O ]

게임 성공 여부: 성공 총 시도한 횟수: 2

## 🎯 프로그램 요구 사항
- JDK 11 버전에서 실행 가능해야 한다. JDK 11에서 정상적으로 동작하지 않을 경우 0점 처리한다.
- 프로그램 실행의 시작점은 Application의 main()이다.
- build.gradle 파일을 변경할 수 없고, 외부 라이브러리를 사용하지 않는다.
- [Java 코드 컨벤션](https://github.com/woowacourse/woowacourse-docs/tree/main/styleguide/java)  가이드를 준수하며 프로그래밍한다.
- 프로그램 종료 시 System.exit()를 호출하지 않는다.
- 프로그램 구현이 완료되면 ApplicationTest의 모든 테스트가 성공해야 한다. 테스트가 실패할 경우 0점 처리한다.
- 프로그래밍 요구 사항에서 달리 명시하지 않는 한 파일, 패키지 이름을 수정하거나 이동하지 않는다.
- indent(인덴트, 들여쓰기) depth를 3이 넘지 않도록 구현한다. 2까지만 허용한다.
  - 예를 들어 while문 안에 if문이 있으면 들여쓰기는 2이다.
- 힌트: indent(인덴트, 들여쓰기) depth를 줄이는 좋은 방법은 함수(또는 메서드)를 분리하면 된다.
- 3항 연산자를 쓰지 않는다.
- 함수(또는 메서드)가 한 가지 일만 하도록 최대한 작게 만들어라.
- JUnit 5와 AssertJ를 이용하여 본인이 정리한 기능 목록이 정상 동작함을 테스트 코드로 확인한다.
- else 예약어를 쓰지 않는다.
  - 힌트: if 조건절에서 값을 return 하는 방식으로 구현하면 else를 사용하지 않아도 된다.
  - else를 쓰지 말라고 하니 switch/case로 구현하는 경우가 있는데 switch/case도 허용하지 않는다.
- 도메인 로직에 단위 테스트를 구현해야 한다. 단, UI(System.out, System.in, Scanner) 로직은 제외한다.
  - 핵심 로직을 구현하는 코드와 UI를 담당하는 로직을 분리해 구현한다.


## ✏️ 과제 진행 요구 사항
- 기능을 구현하기 전 ```docs/README.md```에 구현할 기능 목록을 정리해 추가한다.
- Git의 커밋 단위는 앞 단계에서 ```docs/README.md```에 정리한 기능 목록 단위로 추가한다.


    - [커밋 메시지 컨벤션 가이드](https://gist.github.com/stephenparish/9941e89d80e2bc58a153)를 참고해 커밋 메시지를 작성한다.

- - -
# 진행 과정
이번에도 작성한 코드에 대한 설명을 다 진행하기에는 글이 너무 길어질 것 같아서 과제를 진행하면서 있었던 일들 위주로 소개를 하려고 한다.

## 주요 기능에 대한 목록 고찰
문제 요구 사항대로 최대한 한 가지의 기능을 담당할 수 있도록 목록을 고찰하려고 노력하였다.
예를 들어서 게임 시작 문구 출력 기능이 있으면 그것에 대한 메서드를 만들고 출력 관련 기능을 담당하는 클래스에 담는 방식으로 생각하면서 기능 목록을 구상하였다.

지금까지 계속 기능 목록을 작성해봤으므로 기능 목록을 정리하는데는 크게 어려움이 없었다.

## 기능 구현 후 테스트 코드 작성 병행
지난 3주 차에서는 모든 기능들을 구현 후 그에 따른 테스트 코드를 한번에 작성하는 방식으로 진행했었다면 이번 4주 차 과제에서는 기능을 생성하고 그 기능이 제대로 동작하는지 테스트 코드를 작성하는 방식으로 과제를 진행했다.
테스트 코드를 통해서 기능 오류가 발견되면 기능을 수정하고 커밋 컨벤션에 따라서 커밋을 하였다.

## 기능 목록 수정이 있을 때마다 작성했던 기능 목록을 고치기
기능 목록은 처음부터 항상 완벽하진 않기에 코드 작성시 중간에 항상 추가적으로 필요한 기능이 있는 경우도 있었고, 기능의 역할 수정이 필요한 경우도 있었다.
예를 들어서 단순히 다리를 생성하는 기능을 기능 목록에 처음에 작성했었다면, 다리를 생성하기 위해서 세부적으로 어떤 기능이 필요할지 추가적으로 기능이 필요했다. 그에 따른 추가 가능 사항들을 다시 정리하고 기능 목록을 항상 라이브성을 유지하기 위해서 실시간으로 업데이트 하는 방식으로 과제를 진행했다.

## 파일 구조를 변경하는 등 리펙토링 작업 진행
주어진 클래스 파일을 다른 패키지로 이동하는 작업 및 코드 변수명 변경 등의 리펙토링 작업과 클래스 내에서 작성했던 메서드를 다른 클래스로 옮기는 리펙토리 작업을 하며 과제를 진행했다.


## 과제 진행 중 어려웠던 사항
### 주어진 클래스 및 메서드를 활용하기 위한 고찰의 어려움
3주 차 과제는 단순히 자기 자신만의 힘으로 클래스와 메서드를 알아서 구현해서 문제를 해결하면 됐으나, 4주 차는 몇 개의 클래스와 메서드가 주어진다.

각 클래스에 대한 요구 사항(기능 구현 유의 사항 설명에는 기재하지 않았다. 생성자, 필드 등의 요구 사항)과 그 클래스가 가지고 있는 메서드를 활용해서 어떻게 내가 구상한 기능들을 구현을 해야할지 고민하는데 많은 시간이 걸렸다.

### 다리 건너기 게임의 결과 출력에 대한 구현
다리를 생성하고 다리 건너기를 진행하기 위한 기능 구현은 어렵지 않았다.
다만 다리 건너기 게임 진행 중 현재 내가 건너고 있는 다리의 상황을 출력으로 나타낼 때 어떤 방식을 사용해야 할지 고민을 했지만 쉽게 방법이 떠오르지 않았다.

## 어려웠던 과정들을 해결하기 위한 노력
처음에는 아무것도 작성할 수가 없을 만큼 막막하고 멍때리는 경우가 많았다. 한편으로는 내가 생각했던 방식으로 작성을 했는데 작성하는 과정 중에서 또다른 오류가 발생하거나 막히면 곤란할 것 같다는 그 불안감이 나의 코드 작성에 영향을 미치면서 무기력한 상황에 처해지기도 하였다.
그렇지만 무기력하게 아무것도 하지 않으면 처음부터 과제를 안하는 상황과 다름없기에 일단은 이것저것 부딪혀보고 왔던 길을 되돌아가면서 피드백을 차차 쌓아가며 코드 작성을 하는 것이 낫겠다는 생각이 들었다. 
그래서 일단은 계속 작성을 해보고 이 코드는 어떤 방식으로 구현 방식을 하는 것이 좋을지 보완하는 방식으로 코드를 작성하였다.
그런 방식으로 코드를 완성도 있게 작성할 수 있는 단계까지 도달하여 좌절을 딛을 수 있다는 성취감을 가질 수 있었고, 4주 차 과제도 내 자신만의 힘으로 해결할 수 있었다.

2주 차 미션에서는 함수를 분리하고 각각의 함수마다 기능 테스트 코드 작성하는 실습 진행하는 것을 목표로 진행했다.

이번 3주 차 미션에서는 2주 차에서 진행한 내용에서 다음과 같은 목표가 추가된다. 1. 클래스(객체)를 분리하는 연습 2. 도메인 로직에 대한 단위 테스트를 작성하는 연습

자발적으로 객체를 분리하면서 기능 구현을 별로 해본 경험이 없는 나로써는 딱 안성맞춤인 과제였다. 하지만 기능 구현을 완료하고 그에 따라 테스트 코드를 작성하는 습관이 아직 덜 들여진 것 같다. 좀 더 많은 작업을 하면서 테스트 코드를 습관적으로 작성할 줄 아는 습관을 빨리 들일 수 있도록 해야겠다.

기능 구현 유의사항

문제 풀기에 앞서 다음과 같은 진행 방식을 유의하면서 기능을 구현해야 한다.

• 미션은 기능 요구 사항, 프로그래밍 요구 사항, 과제 진행 요구 사항 세 가지로 구성되어 있다.

• 세 개의 요구 사항을 만족하기 위해 노력한다. 특히 기능을 구현하기 전에 기능 목록을 만들고, 기능 단위로 커밋 하는 방식으로 진행한다.

• 기능 요구 사항에 기재되지 않은 내용은 스스로 판단하여 구현한다.

  🚀 기능 요구 사항

  로또 게임 기능을 구현해야 한다. 로또 게임은 아래와 같은 규칙으로 진행된다. ```TEXT

• 로또 번호의 숫자 범위는 1~45까지이다.

• 1개의 로또를 발행할 때 중복되지 않는 6개의 숫자를 뽑는다.

• 당첨 번호 추첨 시 중복되지 않는 숫자 6개와 보너스 번호 1개를 뽑는다.

• 당첨은 1등부터 5등까지 있다. 당첨 기준과 금액은 아래와 같다.

  • 1등: 6개 번호 일치 / 2,000,000,000원
  • 2등: 5개 번호 + 보너스 번호 일치 / 30,000,000원
  • 3등: 5개 번호 일치 / 1,500,000원
  • 4등: 4개 번호 일치 / 50,000원
  • 5등: 3개 번호 일치 / 5,000원 ```

• 로또 구입 금액을 입력하면 구입 금액에 해당하는 만큼 로또를 발행해야 한다.

• 로또 1장의 가격은 1,000원이다.

• 당첨 번호와 보너스 번호를 입력받는다.

• 사용자가 구매한 로또 번호와 당첨 번호를 비교하여 당첨 내역 및 수익률을 출력하고 로또 게임을 종료한다.

• 사용자가 잘못된 값을 입력할 경우 IllegalArgumentException를 발생시키고, "[ERROR]"로 시작하는 에러 메시지를 출력 후 종료한다.

  🎯 프로그램 요구 사항

• JDK 11 버전에서 실행 가능해야 한다. JDK 11에서 정상적으로 동작하지 않을 경우 0점 처리한다.

• 프로그램 실행의 시작점은 Application의 main()이다.

• build.gradle 파일을 변경할 수 없고, 외부 라이브러리를 사용하지 않는다.

• Java 코드 컨벤션 가이드를 준수하며 프로그래밍한다.

• 프로그램 종료 시 System.exit()를 호출하지 않는다.

• 프로그램 구현이 완료되면 ApplicationTest의 모든 테스트가 성공해야 한다. 테스트가 실패할 경우 0점 처리한다.

• 프로그래밍 요구 사항에서 달리 명시하지 않는 한 파일, 패키지 이름을 수정하거나 이동하지 않는다.

• indent(인덴트, 들여쓰기) depth를 3이 넘지 않도록 구현한다. 2까지만 허용한다.

  • 예를 들어 while문 안에 if문이 있으면 들여쓰기는 2이다.

• 3항 연산자를 쓰지 않는다.

• 함수(또는 메서드)가 한 가지 일만 하도록 최대한 작게 만들어야 한다.

• JUnit 5와 AssertJ를 이용하여 본인이 정리한 기능 목록이 정상 동작함을 테스트 코드로 확인한다.

추가된 요구 사항

• 함수(또는 메서드)의 길이가 15라인을 넘어가지 않도록 구현한다.

• 함수(또는 메서드)가 한 가지 일만 잘 하도록 구현한다.

  • else 예약어를 쓰지 않는다.

  • 힌트: if 조건절에서 값을 return하는 방식으로 구현하면 else를 사용하지 않아도 된다. else를 쓰지 말라고 하니 switch/case로 구현하는 경우가 있는데 switch/case도 허용하지 않는다.

  • Java Enum을 적용한다.

  • 도메인 로직에 단위 테스트를 구현해야 한다. 단, UI(System.out, System.in, Scanner) 로직은 제외한다.

• 핵심 로직을 구현하는 코드와 UI를 담당하는 로직을 분리해 구현한다.

• 단위 테스트 작성이 익숙하지 않다면 test/java/lotto/LottoTest를 참고하여 학습한 후 테스트를 구현한다.

라이브러리

• camp.nextstep.edu.missionutils에서 제공하는 Randoms 및 Console API를 사용하여 구현해야 한다.
• Random 값 추출은 camp.nextstep.edu.missionutils.Randoms의 pickUniqueNumbersInRange()를 활용한다. 사용자가 입력하는 값은 camp.nextstep.edu.missionutils.Console의 readLine()을 활용한다.

LOTTO 클래스를 사용하며 구현해야 한다.

✏️ 과제 진행 요구 사항

• 기능을 구현하기 전 docs/README.md에 구현할 기능 목록을 정리해 추가한다.
• Git의 커밋 단위는 앞 단계에서 docs/README.md에 정리한 기능 목록 단위로 추가한다.

- [커밋 메시지 컨벤션 가이드](https://gist.github.com/stephenparish/9941e89d80e2bc58a153)를 참고해 커밋 메시지를 작성한다.

진행 과정의 순서

⭐️ 객체 분리를 위한 디자인 패턴 공부

그냥 무작정 객체를 분리했다간 오류가 났을 때 다시 처음부터 짜야할 것 같다는 생각에 객체를 잘 분리하기 위한 효율적인 방법들은 어떤 것들이 있을지 생각해보았다.

검색을 통해 확인을 해봤는데 객체를 분리하기 위한 패턴은 정말 다양하다는 것을 알았다. 싱글톤 패턴, 빌더 패턴, 전략 패턴, 어댑터 패턴 등등... 그렇게 다양한 패턴이 존재하고 있다는 것을 알았지만 실제로 이 패턴들 중에서 어떤 방식이 적합할 지 감이 오지 않았다.

그래서 일단 각 기능을 만들 때 한 가지 일만 함녀서 만드는 것에 집중하면서 객체를 분리해보기로 하였다.

💻 인스턴스형 객체와 클래스형 객체에 대한 공부

코드를 작성하기에 앞서 어떤 클래스 함수 앞에 static키워드가 앞에 붙고 어떤 함수 앞에는 안 붙어 있는 경우를 볼 수가 있었다. 나는 클래스를 분리하고 함수를 만들기 위해서는 static키워드의 역할을 제대로 알아야 할 필요가 있다는 생각이 들었다.

Java에서는 메모리 영역이 존재하는데 메모리 영역은 static 영역과 heap 영역으로 나누어져 있다는 것을 알았다.

핵심 부분을 정리하자면 다음과 같다.

1. static 영역

• Garbage Collector가 관리하는 영역은 아니며 단순히 class만 모여 있는 공간을 의미(객체가 아니다.)한다. 그래서 static 영역의 메모리를 무분별하게 사용하면 메모리 누수가 발생할 수 있다.
• class 안에 존재하는 필드(class 변수)가 static으로 지정이 된다면(static 멤버) 이 멤버는 동일한 클래스의 모든 객체들에 의해 공유가 되고(클래스가 생성될 때마다 각각 생성이 되는 것이 아니라 단 하나로 생성이 되기 때문), 객체가 사라져도 이 멤버는 사라지지 않는다.
• static 메서드는 static 멤버들만 접근 가능하고, 객체가 생성되지 않는 상황에서도 사용 가능하다.
• static 메서드는 this 키워드를 사용할 수 없다.
• static 메서드에 대하여 오버라이딩이 불가능하다.

2. heap 영역

• Garbage Collector가 관리하는 영역이며 객체들이 모여 있는 공간(new 연산을 통해 생성)이다. 메모리 누수의 걱정은 없다.

🖥️ 프로그램 기능 구현 시작

사전 공부를 마치고 기능 구현에 들어갔다. 기능 구현을 하면서 필요한 클래스 및 패키지를 분리했고, 클래스를 만들어 기능별 구현을 시작했다. 코드까지 첨부하면서 설명하면 내용이 길어질 것 같아서 내가 구현했던 기능 목록들만 나열하겠다.

✅ ”구입금액을 입력해 주세요.” 출력 기능, 구입 금액 입력 기능(수정)

✅ 문자열로 입력 받은 금액에 대한 검증 후 정수형으로 반환 기능

• 입력 금액의 맨 앞자리가 0이면 IllegalArgumentException 발생시키기

• 만약 1000원 단위의 금액이 아니면 IllegalArgumentException 을 발생시키기

  → [ERROR] 입력 금액은 천 원 단위어야 합니다.

✅ 입력한 금액에 대하여 로또 개수 구하기 기능

✅ 로또 개수 출력 기능 → “8개를 구매했습니다.”

✅ 로또 개수 만큼 6개의 숫자를 랜덤으로 생성하는 기능

• pickUniqueNumbersInRange(1, 45, 6)

✅ 생성된 로또 번호 오름차순으로 정렬하기 기능

✅ 입력 형식 (, 구분해서 입력) 검증 포함한 당첨 번호 입력 받기 기능

✅ 각각의 당첨 번호 유효성 검증

• 각각의 당첨 번호의 범위 검증 (1 ≤ 당첨 번호 ≤ 45)
• 각각의 당첨 번호 중복 여부 검증

✅ 보너스 번호 입력 받기 기능

✅ 보너스 번호 유효성 검증 기능

✅ 당첨 통계 출력 기능

✅ 모든 로또의 번호와 당첨번호를 비교해 각각의 일치 개수에 대하여 몇 개의 로또가 있는지 정보 출력 기능

✅ 총 수익률 계산 기능(소수점 둘째 자리에서 반올림)

3주차 진행 후 받은 공통 피드백

🔔 함수(메서드) 라인에 대한 기준

프로그래밍 요구사항을 보면 함수 15라인으로 제안하는 요구사항이 있다. 이 기준은 main() 함수에도 해당된다. 공백 라인도 한 라인에 해당한다. 15라인이 넘어간다면 함수 분리를 위한 고민을 한다.

🔔 발생할 수 있는 예외 상황에 대해 고민한다

정상적인 경우를 구현하는 것보다 예외 상황을 모두 고려해 프로그래밍하는 것이 더 어렵다. 예외 상황을 고려해 프로그래밍하는 습관을 들인다. 예를 들어 로또 미션의 경우 아래와 같은 예외 상황을 고민해 보고 해당 예외에 대해 처리를 할 수 있어야 한다.

• 로또 구입 금액에 1000 이하의 숫자를 입력
• 당첨 번호에 중복된 숫자를 입력
• 당첨번호에 1~45 범위를 벗어나는 숫자를 입력
• 당첨 번호와 중복된 보너스 번호를 입력

  🔔 비즈니스 로직과 UI 로직을 분리한다

  비즈니스 로직과 UI 로직을 한 클래스가 담당하지 않도록 한다. 단일 책임의 원칙에도 위배된다. 현재 객체의 상태를 보기 위한 로그 메시지 성격이 강하다면 toString()을 통해 구현한다. View에서 사용할 데이터라면 getter 메서드를 통해 데이터를 전달한다.

🔔 연관성이 있는 상수는 static final 대신 enum을 활용한다

🔔 final 키워드를 사용해 값의 변경을 막는다

최근에 등장하는 프로그래밍 언어들은 기본이 불변 값이다. 자바는 final 키워드를 활용해 값의 변경을 막을 수 있다.

🔔 객체의 상태 접근을 제한한다

인스턴스 변수의 접근 제어자는 private으로 구현한다.

🔔 객체는 객체스럽게 사용한다

Lotto 클래스는 numbers를 상태 값으로 가지는 객체이다. 그런데 이 객체는 로직에 대한 구현은 하나도 없고, numbers에 대한 getter 메서드만을 가진다. Lotto에서 데이터를 꺼내지(get) 말고 메시지를 던지도록 구조를 바꿔 데이터를 가지는 객체가 일하도록 한다.

🔔 필드(인스턴스 변수)의 수를 줄이기 위해 노력한다

필드(인스턴스 변수)의 수가 많은 것은 객체의 복잡도를 높이고, 버그 발생 가능성을 높일 수 있다. 필드에 중복이 있거나, 불필요한 필드가 없는지 확인해 필드의 수를 최소화한다.

🔔 성공하는 케이스 뿐만 아니라 예외에 대한 케이스도 테스트한다

테스트를 작성하면 성공하는 케이스에 대해서만 고민하는 경우가 있다. 하지만 예외에 대한 부분 또한 처리해야 한다. 특히 프로그램에서 결함이 자주 발생하는 부분 중 하나는 경계값이므로 이 부분을 꼼꼼하게 확인해야 한다.

🔔 테스트 코드도 코드다

테스트 코드도 코드이므로 리팩터링을 통해 개선해나가야 한다. 특히 반복적으로 하는 부분을 중복되지 않게 만들어야 한다.

🔔 테스트를 위한 코드는 구현 코드에서 분리되어야 한다

테스트를 위한 편의 메서드를 구현 코드에 구현하지 마라. 아래의 예시처럼 테스트를 통과하기 위해 구현 코드를 변경하거나 테스트에서만 사용되는 로직을 만들지 않는다.

🔔 테스트를 위한 코드는 구현 코드에서 분리되어야 한다

테스트를 위한 편의 메서드를 구현 코드에 구현하지 마라. 아래의 예시처럼 테스트를 통과하기 위해 구현 코드를 변경하거나 테스트에서만 사용되는 로직을 만들지 않는다.

• 테스트를 위해 접근 제어자를 바꾸는 경우
• 테스트 코드에서만 사용되는 메서드

🔔 단위 테스트를 할 때 테스트하기 어려운 부분은 분리하고 테스트 가능한 부분을 단위 테스트한다.

🔔 private 함수를 테스트 하고 싶다면 클래스(객체) 분리를 고려한다

가독성의 이유만으로 분리한 private 함수의 경우 public으로도 검증 가능하다고 여겨질 수 있다. public 함수가 private 함수를 사용하고 있기 때문에 자연스럽게 테스트 범위에 포함된다. 하지만 가독성 이상의 역할을 하는 경우, 테스트하기 쉽게 구현하기 위해서는 해당 역할을 수행하는 다른 객체를 만들 타이밍이 아닐지 고민해 볼 수 있다. 다음 단계를 진행할 때에는 너무 많은 역할을 하고 있는 함수나 객체를 어떻게 의미 있는 단위로 분할할지에 초점을 맞춰 진행한다.

1주 차 미션에서 작성했던 준비 운동을 마무리하고 본격적인 미션이 시작되는 것 같다.

이번 2주 차 미션에서는 1주 차에서 학습한 것에 더해 함수를 분리하고, 각 함수별로 테스트를 작성하는 것에 익숙해지는 것을 목표로 하고 있다.

그리고 작성한 함수에 대한 테스트 코드를 작성하여 내가 생각한 기능대로 제대로 동작을 하는지 테스트도 진행을 해아 한다. 자발적으로 작성해 본 적이 없는 내 입장에서는 가치 있는 미션인 것 같다.

2주차 과제를 진행하면서 내가 과제를 진행했던 과정을 정리하겠다.

기능 구현 유의사항

문제 풀기에 앞서 다음과 같은 진행 방식을 유의하면서 기능을 구현해야 한다.

• 미션은 기능 요구 사항, 프로그래밍 요구 사항, 과제 진행 요구 사항 세 가지로 구성되어 있다.

• 세 개의 요구 사항을 만족하기 위해 노력한다. 특히 기능을 구현하기 전에 기능 목록을 만들고, 기능 단위로 커밋 하는 방식으로 진행한다.

• 기능 요구 사항에 기재되지 않은 내용은 스스로 판단하여 구현한다.

  🚀 기능 요구 사항

  1부터 9까지 서로 다른 수로 이루어진 3자리의 수를 맞추는 게임 기능을 구현해야 한다.

• 같은 수가 같은 자리에 있으면 스트라이크, 다른 자리에 있으면 볼, 같은 수가 전혀 없으면 낫싱이란 힌트를 얻고, 그 힌트를 이용해서 먼저 상대방(컴퓨터)의 수를 맞추면 승리한다.

  • 예를 들어 상대방(컴퓨터)의 수가 425일 때
    • 123을 제시한 경우: 2의 위치가 하나 맞았고, 1과 3은 425에서 존재하지도 않으므로 1스트라이크
    • 456을 제시한 경우: 5의 위치가 서로 다르고 4의 위치가 같으므로 1볼 1스트라이크
    • 789를 제시한 경우: 425에서 해당 숫자가 존재하지 않으므로 낫싱

• 위 숫자 야구 게임에서 상대방의 역할을 컴퓨터가 한다. 컴퓨터는 1에서 9까지 서로 다른 임의의 수 3개를 선택한다. 게임 플레이어는 컴퓨터가 생각하고 있는 서로 다른 3개의 숫자를 입력하고, 컴퓨터는 입력한 숫자에 대한 결과를 출력한다.

• 이 같은 과정을 반복해 컴퓨터가 선택한 3개의 숫자를 모두 맞히면 게임이 종료된다.

• 게임을 종료한 후 게임을 다시 시작하거나 완전히 종료할 수 있다.

• 사용자가 잘못된 값을 입력할 경우 IllegalArgumentException을 발생시킨 후 애플리케이션은 종료되어야 한다.

• 프로그램이 실행될 때 다음과 같은 내용들이 출력되어야 한다.

  숫자 야구 게임을 시작합니다.
  숫자를 입력해주세요 : 123
  1볼 1스트라이크
  숫자를 입력해주세요 : 145
  1볼
  숫자를 입력해주세요 : 671
  2볼
  숫자를 입력해주세요 : 216
  1스트라이크
  숫자를 입력해주세요 : 713
  3스트라이크
  3개의 숫자를 모두 맞히셨습니다! 게임 종료
  게임을 새로 시작하려면 1, 종료하려면 2를 입력하세요.
  1
  숫자를 입력해주세요 : 123
  1볼
  ...

🎯 프로그램 요구 사항

• JDK 11 버전에서 실행 가능해야 한다. JDK 11에서 정상적으로 동작하지 않을 경우 0점 처리한다.
• 프로그램 실행의 시작점은 Application의 main()이다.
• build.gradle 파일을 변경할 수 없고, 외부 라이브러리를 사용하지 않는다.
• Java 코드 컨벤션 가이드를 준수하며 프로그래밍한다.
• 프로그램 종료 시 System.exit()를 호출하지 않는다.
• 프로그램 구현이 완료되면 ApplicationTest의 모든 테스트가 성공해야 한다. 테스트가 실패할 경우 0점 처리한다.
• 프로그래밍 요구 사항에서 달리 명시하지 않는 한 파일, 패키지 이름을 수정하거나 이동하지 않는다.

추가된 요구 사항

• indent(인덴트, 들여쓰기) depth를 3이 넘지 않도록 구현한다. 2까지만 허용한다.

  • 예를 들어 while문 안에 if문이 있으면 들여쓰기는 2이다.

• 3항 연산자를 쓰지 않는다.

• 함수(또는 메서드)가 한 가지 일만 하도록 최대한 작게 만들어야 한다.

• JUnit 5와 AssertJ를 이용하여 본인이 정리한 기능 목록이 정상 동작함을 테스트 코드로 확인한다.

  라이브러리

• camp.nextstep.edu.missionutils에서 제공하는 Randoms 및 Console API를 사용하여 구현해야 한다.

- Random 값 추출은 ```camp.nextstep.edu.missionutils.Randoms```의 ```pickNumberInRange()```를 활용한다.
- 사용자가 입력하는 값은 ```camp.nextstep.edu.missionutils.Console```의 ```readLine()```을 활용한다.

✏️ 과제 진행 요구 사항

• 기능을 구현하기 전 docs/README.md에 구현할 기능 목록을 정리해 추가한다.
• Git의 커밋 단위는 앞 단계에서 docs/README.md에 정리한 기능 목록 단위로 추가한다.

- [커밋 메시지 컨벤션](https://gist.github.com/stephenparish/9941e89d80e2bc58a153) 가이드를 참고해 커밋 메시지를 작성한다.

진행 과정의 순서

⭐ git commit convention에 대한 공부

프로그램 요구 사항에서 Java 코드 컨벤션의 링크를 들어가보았다. git commit을 할 때 어떤 형태로 작성을 해야 하는지 그에 대한 가이드가 들어있었다.

그 외에도 git comit에 대한 자세한 내용을 알고 싶어서 구글링을 통해 git commit convention에 대해 다양한 가이드를 참조했고, 내가 공부했던 내용들을 바탕으로 벨로그에 정리를 하였다.

⚾ 야구 게임을 위한 필요한 기능 목록들을 고찰

문제에서 이번 주차의 미션은 함수를 분리하고 이에 따른 테스트 코드를 작성하는 것을 목표로 한다. 그래서 나는 각 기능을 하나의 함수로 취급해서 각 가능들을 고찰하였다. 즉, 하나의 Application 파일 안에서 코드 작성을 진행했다. 내 코드의 내용이 정답이라는 보장은 없기에 어떤 함수를 만들었고, 무슨 기능인지 간단하게 설명만 하려고 한다. 최종적으로 내가 생각했던 기능들은 다음과 같다. 1️⃣ 게임 시작 공지 기능 2️⃣ 1부터 9까지 3개의 서로 다른 자연수의 컴퓨터 숫자 뽑기 기능 3️⃣ 사용자로부터 3개의 숫자 입력 받기 기능 4️⃣ 사용자로부터 입력된 3개의 숫자의 유효성 검증 기능 5️⃣ 컴퓨터 숫자와 사용자 숫자로부터 '볼'의 개수 뽑기 기능 6️⃣ 컴퓨터 숫자와 사용자 숫자로부터 '스트라이크'의 개수 뽑기 기능 7️⃣ '스트라이크' 및 '볼'의 개수 정보 출력 기능 8️⃣ 3스트라이크가 나올 때까지 3번과 7번을 반복 기능 9️⃣ 3스트라이크가 달성 후 게임 재시작 여부 기능

🏀 각 기능 목록 하나씩 구현 후 commit 진행

목록 당 기능을 구현 후 commit convention에 따라서 commit을 진행했다.

1️⃣ 숫자 야구 게임을 시작합니다.문구 출력을 위한 기능이다. 이 기능에 대한 메서드를 따로 구현을 했고, 메서드 이름을 noticeStartGame으로 설정했다. 2️⃣ createComputerNumbers 메서드를 만들었고, Randoms의 pickNumberInRange메서드를 사용하였다. 3️⃣ inputUserNumbers메서드를 만들었다. 이 메서드에는 숫자를 입력해주세요 :도 출력이 된다. 처음에는 숫자 입력 출력 문구도 따로 기능으로 뺄 생각을 했지만, 입력 기능에 관련이 있으므로 빼지 않기로 결정했다. 4️⃣ isValidUserNumbers 메서드를 만들었다. 이 메서드는 다음과 같은 내용을 검증한다.

• 입력한 숫자의 길이가 3인지 검증
• 각 자리당 숫자의 범위가 1이상 9이하인지 검증
• 각 자리마다 중복된 숫자가 있는지 검증

5️⃣ getBallNumber 메서드를 만들었고, 3자리의 유효한 사용자 숫자와 컴퓨터 숫자를 비교하여 볼의 개수를 출력한다. 6️⃣ getStrikeNumber메서드를 만들었고, 3자리의 유효한 사용자 숫자와 컴퓨터 숫자를 비교하여 스트라이크의 개수를 출력한다. 7️⃣ printBallStrikeResult를 만들었다. 이 메서드는 들어온 볼의 개수와 스트라이크의 개수 정보를 바탕으로 알맞은 결과를 출력한다. 또한 boolean형의 메서드이므로 3스트라이크가 아니면 true를 반환한다. 8️⃣ 7️⃣번에서 3스트라이크가 나오지 않을 경우 true를 반환하는 것을 이용하여 main함수에서 반복문을 통해서 야구 게임 숫자 반복 입력을 설정했다. 9️⃣ wantRestart를 구현했고, 이 메서드는 boolean형이다. 즉, 사용자가 게임 재시작을 원하면 true를 반환, 게임 종료를 원하면 false를 반환하도록 설정해 main에서 반복문을 통해서 게임을 재시작 하도록 설정하였다.

🔧 전반적인 코드 리펙토링 진행

Java 코드 컨벤션에 따라서 전반적으로 가독성을 높이기 위한 코드 리펙토링을 진행했다.

• while, if 등의 내용 다음에 수직 빈 줄 쓰기
• 메서드와 메서드 사이에 수직 빈 줄 쓰기

🔍 기능별 테스트 코드 작성

모든 기능 및 코드 리펙토링을 마치고 전반적으로 각 기능들이 이상이 없는지 그에 따른 테스트 코드를 작성하였다. 테스트 코드에 대한 작성 경험은 별로 많지 않아서 테스트 코드를 쓸 때 주로 어떤 기능을 쓰는지, 또 어떤 방식으로 테스트를 진행하는지 공부하였다. 테스트를 진행하는 방식에는 BDD(Behavior-driven development), TDD(Test-driven development)이 두 가지가 존재한다는 것을 알았다. TDD는 테스트를 먼저 작성하고 그 테스트를 통과시키는 코드를 작성하는 흐름을 기본으로 하지만, BDD는 시나이오를 기반으로 테스트를 작성한다. 그리고 given, when, then등의 구조로 테스트를 작성한다. 나는 BDD방식을 통해, 즉 given, when, then의 구조로 테스트 코드를 작성하려고 노력했다. 그래야 일반 사람들이 언뜻 봐서도 이해가 될 것 같았기에 가독성 면에서도 좋을 것 같다는 생각이 들었다. 테스트 코드를 작성을 해보면서 힘들었던 점을 꼽아서 얘기하자면 출력 관련 테스트에 대한 코드 작성과 private으로 설정된 메서드를 테스트 코드 파일로 불러오는 일이었다. 나는 이것과 관련하여 구글링을 하는데 많은 시간을 투자했었다. 하지만 결과적으로 테스트 코드를 완성했고, 꽤 유용한 기능들에 대한 노하우를 얻었다는 느낌을 받았다.

2주차 진행 후 받은 공통 피드백

🔔 README.md를 상세히 작성한다

미션 저장소의 README.md는 소스코드에 앞서 해당 프로젝트가 어떠한 프로젝트인지 마크다운으로 작성하여 소개하는 문서이다. 해당 프로젝트가 어떠한 프로젝트이며, 어떤 기능을 담고 있는지 기술하기 위해서 마크다운문법을 검색해서 학습해보고 적용해 본다.

🔔 기능 목록을 재검토한다

기능 목록을 클래스 설계와 구현, 함수(메서드) 설계와 구현과 같이 너무 상세하게 작성하지 않는다. 클래스 이름, 함수(메서드) 시그니처와 반환값은 언제든지 변경될 수 있기 때문이다. 너무 세세한 부분까지 정리하기보다 구현해야 할 기능 목록을 정리하는 데 집중한다. 정상적인 경우도 중요하지만, 예외적인 상황도 기능 목록에 정리한다. 특히 예외 상황은 시작 단계에서 모두 찾기 힘들기 때문에 기능을 구현하면서 계속해서 추가해 나간다.

🔔 기능 목록을 업데이트한다

README.md 파일에 작성하는 기능 목록은 기능 구현을 하면서 변경될 수 있다. 시작할 때 모든 기능 목록을 완벽하게 정리해야 한다는 부담을 가지기보다 기능을 구현하면서 문서를 계속 업데이트한다. 죽은 문서가 아니라 살아있는 문서를 만들기 위해 노력한다.

🔔 값을 하드 코딩하지 않는다

문자열, 숫자 등의 값을 하드 코딩하지 마라. 상수(static final)를 만들고 이름을 부여해 이 변수의 역할이 무엇인지 의도를 드러내라. 구글에서 "java 상수"와 같은 키워드로 검색해 상수 구현 방법을 학습하고 적용해 본다.

🔔 구현 순서도 코딩 컨벤션이다

클래스는 상수, 멤버 변수, 생성자, 메서드 순으로 작성한다.

class A {
    상수(static final) 또는 클래스 변수

    인스턴스 변수

    생성자

    메서드
}

🔔 변수 이름에 자료형은 사용하지 않는다

변수 이름에 자료형, 자료 구조 등을 사용하지 마라.

String carNameList = Console.readLine();
String[] arrayString = carNameList.split(",");

🔔 한 함수가 한 가지 기능만 담당하게 한다

함수 길이가 길어진다면 한 함수에서 여러 일을 하려고 하는 경우일 가능성이 높다. 아래와 같이 한 함수에서 안내 문구 출력, 사용자 입력, 유효값 검증 등 여러 일을 하고 있다면 이를 적절하게 분리한다.

🔔 함수가 한 가지 기능을 하는지 확인하는 기준을 세운다

만약 여러 함수에서 중복되어 사용되는 코드가 있다면 함수 분리를 고민해 본다. 또한, 함수의 길이를 15라인을 넘어가지 않도록 구현하며 함수를 분리하는 의식적인 연습을 할 수 있다.

🔔 테스트를 작성하는 이유에 대해 본인의 경험을 토대로 정리해본다

단지 기능을 점검하기 위한 목적으로 테스트를 작성하는 것은 아니다. 테스트를 작성하는 과정을 통해서 나의 코드에 대해 빠르게 피드백을 받을 수 있을 뿐만 아니라 학습 도구로도 활용할 수 있다. 이런 경험을 통해 테스트에 대해 어떤 유용함을 느꼈는지 알아본다.

🔔 처음부터 큰 단위의 테스트를 만들지 않는다

테스트의 중요한 목적 중 하나는 내가 작성하는 코드에 대해 빠르게 피드백을 받는 것이다. 시작부터 큰 단위의 테스트를 만들게 된다면 작성한 코드에 대한 피드백을 받기까지 많은 시간이 걸린다. 그래서 문제를 작게 나누고, 그 중 핵심 기능에 가까운 부분부터 작게 테스트를 만들어 나간다.

큰 단위의 테스트

• 숫자 야구 게임을 시작해서 사용자가 숫자를 입력하면, 컴퓨터 숫자와 비교하여 그 결과를 알려준다.

  작은 단위의 테스트

• 사용자의 숫자가 컴퓨터의 숫자와 하나도 일치하지 않으면 낫싱을 출력한다.
• 사용자의 숫자가 컴퓨터의 숫자와 1개는 일치하고, 위치가 다르면 1볼을 출력한다.

우리가 작업을 하게 된다면 git을 이용한 commit 활동을 하게 된다.

개인 프로젝트 및 토이 프로젝트를 진행하는 경우에는 우리는 단순히 다음과 같은 명령어를 통해서 commit을 해봤을 것이다.

git commit -m “커밋할 메시지”

이 커밋할 메시지에서 자기가 원하는 방식대로 메시지를 작성했을 것이다.

하지만 다른 사람과 같이 협업해야 하는 상황이라면 자기가 원하는대로 메시지를 작성하면 다른 협업 작업자 입장에서는 나의 메시지를 이해하기 힘들 수도 있고, 작업 하기가 수월하지 않을 수도 있는 상황이 발생할 수 있다. 또한 내가 그동안 작성한 commit의 log를 살펴보면 과거 내가 작성했던 commit의 내용을 이해하지 못하는 상황도 발생할 수 있다.

그래서 이러한 상황들을 방지하기 위해서 commit convention을 지키는 습관도 중요하다.

편집기를 통해서 commit 내용 작성하기

1️⃣ git config —global core.editor (사용할 편집기)

어떤 환경에서 commit을 할 지 정하기 위해서 쓰이는 명령어이다.

나는 vim 편집기가 익숙해서 다음과 같은 명령어를 사용했다.

git config —global core.editor vim

그 밖에 nano, emacs 등이 있다.

2️⃣ git commit -a

위의 명령어를 사용하면 자신이 설정한 편집기 환경에서 commit 내용을 작성할 수 있다.

좋은 commit message를 작성하기 위한 형태

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

⚠️ 한 라인에서 작성할 수 있는 글자 수는 100자를 넘어가면 안된다!

<type> 의 종류

👉 feat(feature): 새로운 기능을 추가할 시 작성한다. 👉 fix: 코드내에서 버그를 수정할 때 사용한다. 주로 기능상 오류를 수정할 때 사용한다. 👉 docs(documentation): 문서 등의 내용을 수정할 때 쓰인다. 👉 style (formatting, missing semi colons, …): 코드 포멧팅, 세미콜론 누락 등 코드 스타일링을 했을 때 사용한다. 👉 refactor: 코드 리펙토링시 사용한다. 코드를 수정하되 프로그램의 흐름은 변경이 없어야 한다! 예를 들어 어떤 입력값에 대한 결과값은 변경이 없어야 한다. 가독성, 복잡성 관련 작업을 진행할 때 사용한다. 👉 test: 누락된 테스트 코드를 작성했을 때 사용한다. 👉 chore(maintain): 유지 보수 등의 내용일 때 사용한다. 👉 build: 빌드 관련 내용 변경이 있을 때 사용한다. (ex. npm 관련 내용, 외부 dependency 추가 등) 👉 perf: 성능 관련 코드 수정이 있을 때 사용한다.

<scope>의 종류

이 영역은 입력해도 되고 입력하지 않아도 된다. 사용자의 선택사항이다. 어떤 내용을 작성할지도 사용자의 선택사항이다. 예를 들어서 다음과 같이 사용할 수 있다.

$location, $browser, $compile, $rootScope, ngHref, ngClick, ngView, etc…

<subject\>의 내용을 나타내기 위한 단어로 봐도 무방하다.

<subject>

commit message의 제목을 작성하는 영역으로 다른 작업자가 보기 좋게 최대한 간결하고 보기 좋게 어떤 내용 변경이 있었는지 작성한다. 해당 영역에서 마지막에는 마침표를 쓰면 안된다. 영어권의 경우 첫 글자는 대문자가 아닌 소문자로 시작해야하며 현재형을 사용해야 한다.

<body>

반드시 현재형으로 작성해야 한다. 변경 내용에 대한 동기가 있어야 하고, 변경 전과 후에 대한 차이를 설명해야 한다.

<footer>

여기에 모든 변경 사항들과 변경 내용의 정당성, 그리고 변경한 내용(변경 전과 변경 후)이 상세하게 작성이 되어야 한다. 특히 이슈 및 버그 관련 내용이라면 이슈 및 버그를 해결했을시 그동안 있었던 이슈 및 버그 번호들을 closes를 통해서 명시를 해주어야 한다. footer 초반에 명시를 해줘야 한다. 👉 closes #이슈번호

우아한테크코스 5기의 1주차 미션은 7개의 알고리즘 문제풀이였다.

본격적인 과제 들어가기에 앞서 준비운동을 위한 과제라고 생각이 되었다. 오리엔테이션 때 난이도는 쉬운 문제라고 하였으나 알고리즘 문제를 전혀 풀어본 경험이 없는 사람들에게는 만만치 않겠다는 생각이 들었다.

이번 과제를 통해서 각각의 문제마다 내가 생각했었던 문제풀이 설계 과정을 여기에 적어보려고 한다. 내 생각이 무조건 옳다라는 보장은 없다. 코드는 내용상 길어지므로 첨부는 하지 않았다.

기능 구현 유의사항

문제 풀기에 앞서 다음과 같은 진행 방식을 유의하면서 기능을 구현해야 한다.

• 미션은 기능 요구 사항, 프로그래밍 요구 사항, 과제 진행 요구 사항 세 가지로 구성되어 있다.
• 세 개의 요구 사항을 만족하기 위해 노력한다. 특히 기능을 구현하기 전에 기능 목록을 만들고, 기능 단위로 커밋 하는 방식으로 진행한다.
• 기능 요구 사항에 기재되지 않은 내용은 스스로 판단하여 구현한다.

🚀 기능 요구 사항

기능 요구 사항은 7가지의 알고리즘 문제를 말한다. 이 7문제에 대해서 요구 사항에 따라 적절한 기능을 구현하면 된다.

🎯 프로그램 요구 사항

• JDK 11 버전에서 실행 가능해야 한다. JDK 11에서 정상적으로 동작하지 않을 경우 0점 처리한다.
• build.gradle을 변경할 수 없고, 외부 라이브러리를 사용하지 않는다.
• 프로그램 종료 시 System.exit()를 호출하지 않는다.
• 프로그램 구현이 완료되면 ApplicationTest의 모든 테스트가 성공해야 한다. 테스트가 실패할 경우 0점 처리한다.
• 프로그래밍 요구 사항에서 달리 명시하지 않는 한 파일, 패키지 이름을 수정하거나 이동하지 않는다.

✏️ 과제 진행 요구 사항

• 미션은 java-onboarding 저장소를 Fork & Clone해 시작한다.
• 과제 진행 및 제출 방법은 프리코스 과제 제출 문서를 참고한다.

🚀 Problem 1

🔔 기능 목록 정리

• 페이지 번호 게임을 하기 위해서 페이지 번호 검증 기능
  • pobi와 crong에서 들어온 페이지가 1페이지 이상 400페이지 이하인지 확인
  • 리스트 형태인 pobi와 crong에서 첫 요소의 값은 홀수이고, 두 번째 요소의 값은 짝수인지 확인
  • pobi, crong 둘 다 오른쪽 페이지가 왼쪽 페이지보다 값이 커야 하고, 둘의 차이가 1인지 확인
• 페이지 번호 규칙에 따라 한 페이지에서의 페이지 번호 값을 추출기능
• 페이지 번호 검증, 게임 진행 후 pobi와 crong의 페이지 번호 게임의 결과값의 크기 비교에 따라 적당한 값 반환

  🤔 고찰의 단계 과정

1. 페이지 번호 게임을 하기에 앞서서 pobi 또는 crong이 가진 페이지 번호들이 페이지 게임을 하기에 적절한지 검증하는 과정을 먼저 거쳐야 한다는 생각이 들었다. 내가 생각한 검증의 내용은 다음과 같다.
   • pobi 또는 crong이 가지고 있는 페이지 정보들이 전부 1페이지 이상 400페이지 이하인지 검증
   • pobi 또는 crong이 가지고 있는 페이지 정보에서 왼쪽 페이지는 홀수, 오른쪽 페이지는 짝수이므로 pobi또는 crong이 가지고 있는 페이지 정보 중 첫 번째 인덱스는 홀수, 두 번째 인덱스는 짝수인지 검증
   • 오른쪽 페이지와 왼쪽 페이지의 차이가 1인지 검증
2. 페이지 번호 게임이 가능하지 않은 경우라면 -1을 반환한다.
3. 페이지 번호 게임이 가능한 경우라면 페이지 번호 게임에 따라서 pobi와 crong의 페이지 번호 게임 결과값을 추출한다.
4. 만약 pobi의 페이지 번호 게임 결과가 crong의 페이지 번호 게임의 결과보다 크다면 1을 반환한다.
5. 만약 pobi의 페이지 번호 게임 결과가 crong의 페이지 번호 게임의 결과보다 작다면 2을 반환한다.
6. 만약 pobi의 페이지 번호 게임 결과가 crong의 페이지 번호 게임의 결과와 같다면 0을 반환한다.

🚀 Problem 2

🔔 기능 목록 정리

• 연속된 문자가 나오는 문자열의 밤위 찾기
• 중복된 문자로 구성된 문자열을 제거

  🤔 고찰 단계 과정

1. 문자열의 시작점부터 살펴보면서 중복된 문자가 나오는 지점을 찾는다. 중복된 문자가 나오는 지점을 중복 시작점으로 잡아준다.
2. 중복 문자열의 시작점부터 중복 문자가 어디까지 연속되었는지 그 끝지점을 잡아준다. 반복문을 통해서 중복 끝지점을 잡아주었다.
3. 중복 시작점과 중복 끝지점을 잡아주었으므로 입력으로 들어온 기존 문자열에서 이 범위의 문자열을 제거한다.
   • 중복된 문자로 구성된 문자열이 기존 문자열의 중간 부분에 있으면 중간 부분의 문자열을 지운 후 나뉘어진 두 문자열을 서로 합쳐준다.
4. 1번 ~ 3번의 과정을 반복한다.
5. 1번의 과정에서 중복 시작점을 잡지 못했다면 문자열에서 중복되는 문자가 없다는 의미이므로 현재 문자열을 반환한다.

🚀 Problem 3

🔔 기능 목록 정리

• 1부터 주어진 자연수까지 3, 6, 9의 출현 횟수 계산

  🤔 고찰 단계 과정

• 단순 반복문을 활용하여 1부터 주어진 자연수까지 3, 6, 9의 출현 횟수를 계산해주었다.

🚀 Problem 4

🔔 기능 목록 정리

• 주어진 문자열에서 특정 알파벳의 대소문자 구분 기능
• 대문자에 대응하는 청개구리 문자 추출 기능
• 소문자에 대응하는 청개구리 문자 추출 기능

  🤔 고찰 단계 과정

1. 문제 그림에서 사전순으로 정렬된 대문자의 배열에 대응하는 청개구리 문자의 정보를 관찰하였다.
2. 이 정보를 보고 사전순 문자로 구성된 대문자의 문자열 "ABCDEFGHIJKLMNOPQRSTUVWXYZ"과 사전순 문자로 구성된 소문자의 문자열 "abcdefghijklmnopqrstuvwxyz"을 만들었다.
3. 청개구리 결과 문자열을 담아주기 위해서 자바의 StringBuilder 객체를 사용하였다.
   • StringBuilder 객체는 다음과 같이 선언이 가능하다. StringBUilder sb = new StringBuilder();
   • StringBuilder의 append 메서드를 통해서 문자 또는 문자열을 추가할 수 있다. sb.append('c')
   • StringBuilder 객체로 들어온 문자 또는 문자열은 배열의 형태로 문자를 저장하기 때문에 toString 메서드를 통해서 문자열로 변형을 해준다. sb.toString()
4. 주어진 word 문자열을 구성된 문자를 하나씩 살피면서 특정 문자가 소문자인데 대문자인지 구별하였다.
5. 만약 대문자이면 대문자에 대응하는 청개구리 문자를 StringBuilder 객체에 담는다.
   • 대문자에 대응하는 청개구리 문자를 찾는 방법은 다음과 같다.
     • 예를 들어 어떤 문자 A를 살펴본다고 한다면 "ABCDEFGHIJKLMNOPQRSTUVWXYZ"에서 0번 인덱스를 말한다.
     • 사전순 대문자열의 전체 크기는 26이므로 청개구리 문자는 25번 인덱스에 대응한다.
     • 즉 청개구리 문자의 인덱스는 다음과 같이 뽑을 수가 있다. 25 - 대문자열에서 특정 문자의 인덱스 번호
6. 만약 소문자이면 소문자에 대응하는 청개구리 문자를 StringBuilder 객체에 담는다.
7. 소문자, 대문자도 아니면 그냥 StringBuilder 객체에 담는다.
8. StringBuilder에 담겨진 문자의 배열을 toString 메서드를 통해서 문자열로 변형해준다.

🚀 Problem 5

🔔 기능 목록 정리

• 주어진 돈에 대하여 필요한 특정 돈(50000원 지폐, 10000원 지폐 등)의 개수 구하기

  🤔 고찰 단계 과정

1. 문제에서 필요한 돈의 개수를 최소로 해야 한다.
2. 그래서 먼저 주어진 돈에 대해서 가장 큰 값을 가진 돈(50000)부터 필요한 개수를 구하는 방식을 고안하였다.
3. 이를 위해서 내림차순으로 구성된 돈 정보의 배열을 만들었다. moneyList = [50000, 10000, 5000, 1000, 500, 100, 50, 10, 1]
4. moneyList의 첫 원소보터 주어진 돈을 나눈 몫의 정보를 담아준다. 이 정보가 곧 각 돈 당 필요한 개수이다.
5. 나눈 몫을 구했으면 주어진 돈을 나눈 나머지 값으로 업데이트 한다.

🚀 Problem 6

🔔 기능 목록 정리

• 주어진 닉네임의 목록에서 특정 닉네임에 대한 연속으로 중복된 다른 닉네임 존재 여부 판단 기능
• 중복된 닉네임이 존재한 이메일들 사전순으로 정렬

  🤔 고찰 단계 과정

1. 주어진 닉네임들에 대해서 어떤 닉네임이 연속으로 중복된 다른 닉네임이 존재하는지 판단하는 기능을 먼저 고찰했다.
   • 연속 중복된 닉네임의 존재여부를 판단을 위해서 boolean형의 배열을 사용하였다. 배열 이름은 visited로 설정 boolean[] visited = new boolean[forms.size()];
   • 예를 들어서 닉네임 "제이엠", "제이슨", "워니"가 있다면 "제이엠"과 "제이슨"에서 제이가 중복이 되므로 visited는 정보는 다음과 같다. [true, true, false]
2. 닉네임 목록을 살피면서 연속 중복된 닉네임 검증을 위해서 내 입장에서 단순히 떠오르는 방식은 이중 반복문을 통한 확인 방법이었다.
   • 두 닉네임을 검사할 때 연속된 두 글자가 같기만 해도 두 닉네임은 중복된 글자가 있는 닉네임이라고 판단을 하였다.
3. 각 닉네임에 대하여 visited를 업데이트 한다.
4. visited의 정보를 바탕으로 중복된 닉네임끼리 이메일을 따로 리스트에 담아준다.
5. 담겨진 이메일들에 대해 사전순 정렬한다.

🚀 Problem 7

🔔 기능 목록 정리

• 사용자의 친구 목록 담기 기능
• 사용자를 제외한 모든 사람들에 대한 점수 0점 부여 기능
• 함께 아는 친구에 대하여 점수 10점 부여 기능
• 방문자에 대하여 점수 1점 부여 기능
• 결과 정렬 기능

  🤔 고찰 단계 과정

1. 사용자와 함께 아는 친구의 의미가 무엇인지 처음에는 잘 이해가 가지 않았다.
2. 거듭 고민을 해본 결과 나는 사용자와 함께 아는 친구에 대하여 다음과 같이 생각하였다.
   • 사용자의 직접적인 친구 관계는 아무 점수도 부여하지 않는다. (사용자 - 친구)
   • 사용자의 친구의 친구 관계는 점수 10점을 부여한다. (사용자 - 친구 - 친구)
3. 사용자의 직접적인 친구는 0점을 부여해야하므로 사용자의 친구 목록 리스트에 사용자의 친구를 담았다.
4. 사용자를 제외한 모든 사람들에 대하여 추천 점수를 먼저 0점으로 초기화를 진행했다. 이 때 사용한 객체는 자바의 HashMap을 사용하였다.
   • 선언 및 점수 부여 방식은 다음과 같이 진행했다. 선언: Map<String, Integer> map = new HashMap<>(); 점수 부여: map.put("name", 0);
   • 여기서 사용자 자신은 점수를 부여할 필요가 없으므로 HashMap 목록에서 제외한다.
5. friends에서 2번에서 고찰한 결과를 바탕으로 HashMap을 통해서 10점을 부여하였다.
6. visitors에서도 마찬가지로 HashMap을 통해서 2번에 따라 점수 1점을 부여한다.
7. HashMap에 있는 사람들마다 점수 부여를 완료했으므로 점수 기준으로 내림차순으로 HashMap을 정렬한다.
   • HashMap의 내림차순 방식은 다음과 같다.

     List<Map.Entry<String, Integer>> entryList = new LinkedList<>(map.entrySet());
     entryList.sort(new Comparator<Map.Entry<String, Integer>>() {
        @Override
        public int compare(Map.Entry<String, Integer> o1, Map.Entry<String, Integer> o2) {
            return o2.getValue() - o1.getValue();
        }

   • 위의 방식의 코드를 줄이면 다음과 같다.

     List<Map.Entry<String, Integer>> entryList = new LinkedList<>(map.entrySet());
     entryList.sort((o1, o2) -> o2.getValue() - o1.getValue());

8. 내림차순으로 정렬된 점수를 기준으로 HashMap에서 최대 5개의 이름들을 뽑아 따로 리스트로 모아준다. (단, 0점인 지점부터는 뽑지 않는다.)
9. 중복된 점수 구간에 대해서 해당 구간에 속한 이름들을 사전순으로 정렬해준다.

1주차 과제 후 받은 공통 피드백

🔔 요구사항을 정확히 준수한다

과제 제출 전에 기능 요구 사항, 프로그래밍 요구 사항, 과제 진행 요구 사항의 항목을 모두 잘 지켰는지 다시 한 번 점검한다.

🔔 커밋 메시지를 의미 있게 작성한다

커밋 메시지에 해당 커밋에서 작업한 내용에 대한 이해가 가능하도록 작성한다.

🔔 git을 통해 관리할 자원에 대해서도 고려한다

.class 파일은 java 코드가 있으면 생성할 수 있다. 따라서 .class 파일은 굳이 git을 통해 관리하지 않아도 된다. IntelliJ IDEA의 .idea 폴더, Eclipse의 .metadata 폴더 또한 개발 도구가 자동으로 생성하는 폴더이기 때문에 굳이 git으로 관리하지 않아도 된다. 앞으로 git에 코드를 추가할 때는 git을 통해 관리할 필요가 있는지를 고려해볼 것을 추천한다.

🔔 Pull Request를 보내기 전 브랜치를 확인한다

기능 구현 작업을 fork된 Repository의 main branch가 아닌, 기능 구현을 위해 새로 만든 브랜치에서 작업한 후 PR을 보낸다.

🔔 PR을 한 번 작성했다면 닫지 말고 추가 커밋을 한다

PR을 이미 한 번 보냈다면, 새로운 PR을 생성할 필요가 없다. 수정이 필요하다면 추가 커밋을 하면 자동으로 반영된다. 단, 미션 제출 기간 이후에는 추가 커밋을 하지 않는다.

🔔 이름을 통해 의도를 드러낸다

나 자신, 다른 개발자와의 소통을 위해 가장 중요한 활동 중의 하나가 좋은 이름 짓기이다. 변수 이름, 함수(메서드) 이름, 클래스 이름을 짓는데 시간을 투자하라. 이름을 통해 변수의 역할, 함수의 역할, 클래스의 역할에 대한 의도를 드러내기 위해 노력하라. 연속된 숫자를 덧붙이거나(a1, a2, ..., aN), 불용어(Info, Data, a, an, the)를 추가하는 방식은 적절하지 못하다.

🔔 축약하지 않는다

의도를 드러낼 수 있다면 이름이 길어져도 괜찮다.

누구나 실은 클래스, 메서드, 또는 변수의 이름을 줄이려는 유혹에 곧잘 빠지곤 한다. 그런 유혹을 뿌리쳐라. 축약은 혼란을 야기하며, 더 큰 문제를 숨기는 경향이 있다. 클래스와 메서드 이름을 한 두 단어로 유지하려고 노력하고 문맥을 중복하는 이름을 자제하자. 클래스 이름이 Order라면 shipOrder라고 메서드 이름을 지을 필요가 없다. 짧게 ship()이라고 하면 클라이언트에서는 order.ship()라고 호출하며, 간결한 호출의 표현이 된다.

• 객체 지향 생활 체조 원칙 5: 줄여쓰지 않는다 (축약 금지)

  🔔 공백도 코딩 컨벤션이다

  if, for, while문 사이의 공백도 코딩 컨벤션이다.

  🔔 공백 라인을 의미 있게 사용한다

  공백 라인을 의미 있게 사용하는 것이 좋아 보이며, 문맥을 분리하는 부분에 사용하는 것이 좋다. 과도한 공백은 다른 개발자에게 의문을 줄 수 있다.

  🔔 space와 tab을 혼용하지 않는다

  들여쓰기에 space와 tab을 혼용하지 않는다. 둘 중에 하나만 사용한다. 확신이 서지 않으면 pull request를 보낸 후 들여쓰기가 잘 되어 있는지 확인하는 습관을 들인다.

  🔔 의미 없는 주석을 달지 않는다

  변수 이름, 함수(메서드) 이름을 통해 어떤 의도인지가 드러난다면 굳이 주석을 달지 않는다. 모든 변수와 함수에 주석을 달기보다 가능하면 이름을 통해 의도를 드러내고, 의도를 드러내기 힘든 경우 주석을 다는 연습을 한다.

  🔔 IDE의 코드 자동 정렬 기능을 활용한다

  IDE의 코드 자동 정렬 기능을 사용하면 더 깔끔한 코드를 볼 수 있다.

IntelliJ IDEA: ⌥⌘L, Ctrl+Alt+L Eclipse: ⇧⌘F, Ctrl+Shift+F

🔔 Java에서 제공하는 API를 적극 활용한다

함수(메서드)를 직접 구현하기 전에 Java API에서 제공하는 기능인지 검색을 먼저 해본다. Java API에서 제공하지 않을 경우 직접 구현한다. 예를 들어 사용자를 출력할 때 사용자가 2명 이상이면 쉼표(,) 기준으로 출력을 위한 문자열은 다음과 같이 구현 가능하다.

List<String> members = Arrays.asList("pobi", "jason");
String result = String.join(",", members); // "pobi,jason"

🔔 배열 대신 Java Collection을 사용한다

Java Collection 자료구조(List, Set, Map 등)를 사용하면 데이터를 조작할 때 다양한 API를 사용할 수 있다. 예를 들어 List에 "pobi"라는 값이 포함되어 있는지는 다음과 같이 확인할 수 있다.

List<String> members = Arrays.asList("pobi", "jason");
boolean result = members.contains("pobi"); // true

소감

문제를 설계하고 코드를 작성하면서 코드 리펙토링에 대한 필요성을 느껴 코드 리펙토링에 대한 습관과 가독성을 위해서 좋은 네이밍 습관을 들여야겠다는 생각도 들었다.

이것저것 시행착오를 겪으면서 내 자신의 코딩 습관에 대한 피드백을 스스로 가질 수 있는 의미 있는 주차였던 것 같다.

우아한테크코스를 지원 후 2022년 10월 26일 우아한테크코스 5기 오리엔테이션을 들었다. 오리엔테이션에서는 우아한테크코스 과정에 대한 소개와 질의 응답 시간을 가졌는데 그런 시간들을 가지면서 내게는 정말 유익한 정보들을 얻을 수 있었던 것 같다.

코딩테스트 없는 프리코스 과정

이번 우테코 5기에서는 프리코스에 들어가기 위한 별도의 코딩테스트 과정을 거치지 않는다. 그래서 지난 기수에 비해서 이번 프리코스의 참가자들 수가 꽤 많았다. 그만큼 본과정 진출도 많이 힘들어질 수도 있을 것 같다는 생각에 긴장 풀지 말고 항상 나태해지지 말고 더 열심히 해야겠다는 생각이 들었다.

프리코스 교육의 목적

프리코스에서의 가장 큰 목적은 읽기 좋은 프로그래밍 코드를 만들고, 유지보수에 대한 역량을 기르는 것에 있다. 수많은 프로그래밍 교육기관이 있지만 그만큼 유지보수 등 효율적으로 가르치는 교육기관이 별로 없는 느낌을 받았는데 이번 우아한테크코스 프리코스를 통해서 나도 그런 역량들을 가질 수 있을 것 같다는 기대감이 든다.

커뮤니케이션

개발은 혼자만의 것이 아니다. 내가 쓴 프로그래밍 코드가 항상 옳은 코드는 아닐 수 있으므로 항상 피드백이 필요하다. 이번 프리코스에서 제공하는 미션을 통해서 동료들과의 소통 및 토론을 통해서 함께 과정을 해결하고, 더 나은 피드백을 받을 수 있도록 소통의 장을 이번 기수에서 더 많이 마련한 것 같다.

앞으로의 다짐

항상 정해진 계획을 지키려고 노력하고 개발을 게을리하지 않으며 미션을 잘 수행할 수 있도록 하고, 더 나은 나를 만들 수 있도록 해야겠다.

mac을 통한 인스턴스 서버의 접속 방법

1. 만들어진 인스턴스의 아이디를 클릭해서 인스턴스 정보로 이동한다.그림에서 connect를 클릭
2. ssh client로 들어간다.
3. mac에서 터미널을 열고, cd ~/.ssh를 입력하여 .ssh 디렉토리로 이동. 필자의 경우는 iterm2를 사용한다. 그리고 ls -al명령어를 통해서 인스턴스에서 받은 pem 키가 있는지 확인한다. 만약 없다면 인스턴스를 만들었을 때 새로 키를 발급받았다면 Downloads 디렉토리로 가서 해당 키를 .ssh 디렉토리로 옮겨준다. 참고로 보통은 mv (받은 키 경로) (.ssh 경로)명령어로 키를 옮길 수가 있다.
4. 이제 2번의 그림에서 3번의 내용을 복사해서 터미널에 붙여넣기 해주고, Example에 있는 명령어를 복사 붙여넣기를 진행해서 서버가 잘 접속 되는지 확인한다.
5. 접속이 되는 경우도 있지만 접속이 안되는 경우도 있다! 그럴 때는 Example이 적혀있는 명령어 앞에 sudo를 붙여서 실행을 해보면 실행이 될 것이다.
6. 만약 이런 상황에도 실행이 안된다면 아쉽지만 인스턴스를 다시 만들어야 할 것 같다. 필자 같은 경우는 인스턴스를 다시 만들었다.

mac 터미널로 좀 더 간단하게 서버에 접속하기

기본 과정

1. ".ssh" 디렉토리로 이동한다. 이 디렉토리에서 config파일을 열어서 내용을 추가해준다. 만약에 config 파일이 존재하지 않다면 vi config 또는 nano config명령어를 통해서 config파일의 내용을 수정해준다. 필자는 전자의 명령어로 내용을 수정하였다. 아래 그림은 config의 내용이다. -> cat config를 통해서 config의 내용을 출력했다. #은 주석 내용으로 신경 안 써도 된다.

• Host부분에 자신이 변경하고 싶은 명령어를 입력하는 부분이다. 예를 들어서 Host temp라고 내용을 입력했으면 서버 접속 시 ssh temp를 입력하면 서버로 접속할 수가 있다.
• Hostname 부분에는 자신이 만든 aws 서버의 ip 주소를 입력한다. 만약 탄력적 ip 주소를 등록했다면 탄력적 ip를 입력하도록 한다.
• User부분에는 만든 인스턴스의 사용자 이름을 입력한다. 만약 인스턴스를 설정시 ubuntu로 만들어주었다면 ubuntu로 입력을 해주면 된다.
• 마지막으로 IdentityFile 부분에는 자신이 만든 pem 키의 위치를 지정하면 된다.

2. 이제 어느 디렉토리에서든 ssh (자신이 만든 명령어 이름)을 통해서 서버 접속을 할 수가 있다.
3. 하지만 이 방법으로도 접속이 안되는 경우가 있다. 그 경우는 "mac을 통한 인스턴스 서버의 접속 방법"의 5번의 sudo를 통한 접속 경우이다.

sudo 권한 없이 서버 접속할 수 있도록 설정하기

1. 먼저 sudo를 통한 서버 접속("mac을 통한 인스턴스 서버의 접속 방법"의 5번)을 하고 cd /etc/ssh로 이동하고 ls -al을 통해서 파일들을 확인해준다. 다양한 파일들이 나오는데 여기서 이 파일의 내용을 봐야한다. 검은색으로 칠해져 있는 부분은 숫자이다.

2. 맨 마지막에 "root@ip주소" 부분이 있는데 이 내용을 제외한 그 전의 내용들을 전부 복사해준다.

3. exit명령어를 통해서 서버를 나와 로컬로 돌아온다. ".ssh"디렉토리에서 "known_hosts"파일을 찾는다.

4. vi known_hosts로 서버에서 복사한 내용들을 맨 밑에 추가해준다. (필자는 known_hosts의 적혀있는 내용들의 맨 마지막에 추가했다.) 그리고 추가한 내용의 앞에다 자신이 만들어준 자신이 만든 인스턴스의 ip 주소를 입력해준다!

-> "인스턴스 ip주소(탄력적 ip 주소가 존재하면 탄력적 ip입력)" "복사한 내용" 5. :wq를 통해서 저장을 하고 자신이 받은 pem 키의 권한 변경을 해야한다! -> chmod 600 (자신의 pem 키) 6. 이제 ssh (자신이 만든 명령어)를 통해서 접속을 시도해보면 접속이 잘 되는 것을 확인할 수가 있다!

• 2000년대 초반, 이 당시 개발자들은 java의 Enterprise Java Beans(EJB)를 사용했었음

• EJB는 애플리케이션의 비즈니스 로직을 캡슐화하는 서버 측 소프트웨어 구성요소임

• 하지만 EJB의 복잡성(그리고 EJB로직에 의존하며 코드를 짜야 하는 경우가 많았음), 느린 속도 때문에 EJB의 단점이 부각.

• 그런 단점 때문에 다시 간단한 자바 오브젝트를 사용했던 시절로 돌아가고 싶은 개발자들이 많았다.

• Plain Old Java Object(POJO)

• 이에 로드 존슨이 EJB의 문제점을 비판하고 이를 해결하기 위한 오픈소스를 담은 책을 발간 -> 이 때 많은 개발자들이 로드 존슨의 오픈소스를 많이 사용하였다고 한다. -> 로드 존슨이 발간한 책에는 스프링 핵신 개념과 기반 코드가 들어 있다.

• 유겐 휠러, 얀 카로프가 로드 존슨에게 오픈소스 프로젝트를 제안.

• 얀 카로프는 J2EE(EJB) 겨울을 넘어 새롭게 시작하자는 의미로 프로젝트 이름을 spring으로 지었다.

문맥에 따른 spring의 의미

• 스프링은 문맥에 따라 다음과 같은 의미를 가지고 있음 -> 스프링 DI 컨테이너 기술(spring의 핵심이다) -> 스프링 프레임워크 -> 스프링 부트, 스프링 프레임워크 등을 모두 포함한 스프링 생태계

spring 존재의 핵심

• 당시 java에서 EJB를 사용하려면 EJB의 있는 기능들에 의존해서 코드를 짜야했음
• 의존해서 코드를 짜게 되면 객체 지향 언어가 가지는 의미가 사라지게 됨
• spring은 객체 지향 언어가 가진 강력한 특징을 살려낸 프레임워크이다. -> 객체 간의 종속이 없다.
• 그 때문에 좋은 객체 지향 애플리케이션을 개발할 수 있도록 도와줌

Spring Framework의 기술 소개

🔔 스프링의 핵심 기술: 스프링 DI 컨테이너, AOP, 이벤트

🔔 웹 기술: 스프링 MVC, 스프링 WebFlux

🔔 데이터 접근 기술: 트랜잭션, JDBC, ORM 지원, XML 지원

🔔 기술 통합: 캐시, 이메일, 원격접근, 스케줄링

🔔 테스트: 스프링 기반 테스트 지원

🔔 언어: 코틀린, 그루비

Spring Boot 소개

✅ 스프링의 다양한 기능들을 편리하게 사용할 수 있도록 지원한다.

✅ Tomcat과 같은 웹 서버를 내장하므로 별도로 Tomcat을 설치할 필요가 없다.

✅ 손쉬운 빌드 구성을 위해 starter 종속성을 제공한다.

• 스프링 프레임워크를 사용할 때 사용해야할 라이브러리들이 다양한데 starter를 통해서 필요한 라이브러리들을 전부 가져올 수가 있다.

  ✅ 스프링과 3rd parth(외부) 라이브러리 자동 구성한다.

• 스프링 프레임워크 버젼마다 적용해야할 라이브러리들이 다를 수가 있는데 스프링부트는 스프링프레임워크의 버젼과 외부 라이브러리들과의 궁합을 직접 테스트해주고 적절한 버젼을 뽑아내주는 역할을 한다.

  ✅ 메트릭, 상태 확인, 외부 구성 같은 프로덕션 준비 기능 제공한다.

  ✅ 관례에 의한 간결한 설정을 해준다.

• 스프링프레임워크에 대한 사전 설정의 복잡성을 해소해준다.