우아한 테크코스 7기 _ 프리코스 2주차 회고

 

벌써 프리코스 2주차가 끝났다....

시간이 너무 빠르게 흐르는 기분은 나만 느끼고 있는걸까..?

1주차에는 다른 분들의 코드를 보고 구현하는데 급급해 기본적인 SOLID 원칙도 지키지 못한 내 코드가 부끄러웠는데 

이번 2주차에서는 그래도 부끄럽지 않도록 노력해 구현하였다!!

더 많은 분들과 소통하고 서로 코드리뷰 주고 받아야지 ㅎㅎㅎ

 

2주차 과제를 볼려고 들어가면 밑의 3가지 질문이 적혀있었다. 질문을 보고 곰곰히 생각을 했다.

1. 지원서에 작성한 목표를 얼마나 달성하고 있다고 생각하나요? 그 이유는 무엇인가요?

2. 지원서에 작성한 목표를 변경해야 한다고 생각하시나요? 그렇다면 그 이유와 어떤 목표로 변경하고 싶으신가요?

3. 프리 코스를 진행하면서 눈에 띄는 변화나 깨달은 점이 있나요?

 

1주차에 정했던 2주차 목표

좀 더 객체지향적 설계를 하자!!!!!!!

우선순위 :

1순위 : 주어진 요구사항을 제한된 시간에 구현하기

2순위 : 내가 세운 예외 사항을 추가해서 반영하기

• 미션을 수행할 때 1주차에 리뷰달아주셨던 내용을 토대로 SOLID원칙에서 단일책임 원칙부터 지킬 수 있도록 설계하고 구현하는 것이 목표!!
• 1주차 공통 피드백을 코드에 최대한 반영하기!!!!
• 나의 티스토리에 자바 관련 글 2개 적기!
• Git과 더 친해지자. (이건 아직 갈 길이 멀었어.. 한참은 더 친해져야해)

전체적으로 잘 지켜진 것 같은데, 2순위 예외사항 추가해서 반영하기 부분을 너무 간소하게 한 것같은 아쉬움이 있다.

 

그래서 이번 2주차 과제가 무엇이었나!! 
2주차 과제는 자동차 경주를 구현하는 것!

 

내가 구현한 코드  ↓ ↓ ↓ ↓
https://github.com/woowacourse-precourse/java-racingcar-7/pull/962

 

• SOLID원칙을 지킬 수 있도록 기능을 단위별로 나눠 클래스별 역할 분리와 메서드의 단일 책임을 지키기 위해 설계 후 구현했다.
• 배열을 안쓰고 컬렉션 프레임워크를 사용하기 위해 List를 사용했다.

 

해서 이번엔 구현뿐 아니라 다른 분과 코드리뷰를 더 활발히 하기 위해, 코드를 리뷰할때 어떤 부분을 중점적으로 보면 좋은지에 대해서도 공부해보았다.

GitHub에서 다른 사람의 코드를 리뷰할 때 중점적으로 보면 되는 포인트

1. 코드 가독성

• 변수명과 함수명이 명확하게 코드의 역할을 드러내고 있는지 확인, 이름만 보고도 해당 변수나 함수가 어떤 역할을 하는지 알 수 있으면 좋다.
• 주석이 필요한 부분에 적절하게 작성되어 있는지, 복잡한 로직이라면 간단한 설명이 있으면 가독성에 좋다.

2. 효율성과 성능

• 반복문, 재귀 호출, 데이터 구조가 효율적으로 사용되었는지, 불필요한 반복이나 중복 연산은 없는지 본다.
• 처리 속도나 메모리가 중요한 경우라면 알고리즘의 시간 복잡도도 고려해야 한다.

3. 테스트 커버리지

• 테스트 코드가 충분히 작성되었는지, 예외 상황과 다양한 입력에 대한 테스트가 있는지, 테스트 코드가 명확하게 의도를 나타내고 있는지 본다.
• 특정 기능이 버그 없이 잘 작동하는지 검증할 수 있도록 경계 값이나 예외 케이스까지 테스트가 있는지 확인합니다.

4. 모듈화와 재사용성

• 코드가 함수나 클래스로 적절히 분리되어 있는지, 한 함수나 클래스가 너무 많은 역할을 하고 있으면, 필요에 따라 분리할 수 있는지 피드백하자.
• 특정 기능을 다른 곳에서 재사용해야 한다면, 일반화할 수 있는 부분이 있는지 생각해 볼 수 있다.

5. SOLID 원칙과 객체 지향 설계

• 객체 지향 코드라면 SOLID 원칙에 따라 잘 설계되었는지 검토한다. 예를 들어, 단일 책임 원칙(SRP)을 따르고 있는지, 클래스나 메서드가 하나의 명확한 역할만 하고 있는지 본다.
• 코드가 확장에 용이하게 설계되어 있는지, 특정 변경이 전체 구조에 큰 영향을 주지 않는지 확인하자.

6. 에러 처리

• 에러가 발생할 수 있는 곳에 예외 처리가 적절히 되어 있는지, 사용자에게 좋은 에러 메시지를 전달하는지 확인한다.
• 예외 처리에서 불필요한 중복이 있거나 너무 많은 예외를 포괄적으로 잡는 건 아닌지 보자.

 

2주차 공통 피드백

• README.md를 상세히 작성한다.
• 기능 목록을 재검토한다.
  • 기능 목록을 작성할 때 클래스 설계와 구현, 메서드 설계와 구현 같은 상세한 내용은 포함하지 않는다. 클래스 이름이나 메서드 시그니처, 반환값 등은 언제든지 변경될 수 있기 때문이다. 구현해야 할 기능 목록을 중심으로 작성하되, 정상적인 경우뿐만 아니라 예외 상황도 함께 정리한다. 예외 상황은 시작 단계에서 파악하기 어려우므로, 기능을 구현하면서 지속적으로 업데이트하는 것이 좋다.
• 기능 목록을 업데이트한다.
• 값을 하드 코딩하지 않는다.
• 구현 순서도 코딩 컨벤션이다.
  • 클래스는 상수, 멤버 변수, 생성자, 메서드 순으로 작성한다.
• 변수이름에 자료형은 사용하지 않는다.
• 한 메서드가 한 가지 기능만 담당하게 한다.
• 메서드가 한가지 기능을 하는지 확인하는 기준을 세운다.
• 테스트를 작성하는 이유에 대해 본인의 경험을 토대로 정리해본다.
• 처음부터 큰 단위의 테스트를 만들지 않는다.
  • 테스트의 핵심 목적 중 하나는 코드에 대해 빠르고 자주 피드백을 받는 것이다. 처음부터 큰 단위의 테스트를 작성하게 되면, 작성한 코드의 문제를 발견하기까지 시간이 오래걸린다. 따라서 문제를 작게 나누어 핵심 기능부터 작게 테스트를 만들어 가는 것이 효과적이다.

 

3주차 목표 !!!

- MVC 패턴 공부하고 사용해보기

- commit 메세지 작성에 익숙해지기!!

- git desktop 이나 git kraken에 대해 알아보고 사용해보기

- 여유가 되면 테스트 코드 작성해보기