[우아한테크코스 4기] 프리코스 2주차 회고

벌써 프리코스 2주 차도 끝이 났다. 😱

이번 과제에서 주신 피드백을 적용하기 위해 많은 고민을 하고, 조금이라도 더 확신이 드는 코드를 작성하기 위해 노력했다.

어려웠던 점

• 설계 과정은 여전히 쉽지 않았다. 🙃
• 클래스를 분리하고, 어떠한 책임을 부여할지 결정하는 부분이 어려웠다.
• 의도가 드러나는 변수, 클래스, 함수명을 짓는데 많은 고민을 했다.
• 1차보다 README.md 문서를 자세하게 작성하려고 노력했다.
• Stream을 적용해 보았다.

  클래스  분리  

JAVA에서 지향하는 OOP를 고려하여 클래스를 다음과 같이 설계했다.

Car

• 이름과 위치를 저장한다.
• 전진 혹은 정지한다.
• 가장 앞선 위치에 있는지 체크한다.

CarRepository

• 입력받은 차들을 저장한다.
• 난수를 발생시킨다.
• 우승자를 계산한다.

GameController

• 사용자에게 자동차 이름들을 요청한다.
• 사용자에게 시도 횟수를 요청한다.
• 시도 횟수만큼 게임을 진행한다.
• 우승자를 사용자에게 출력한다.

InputView

• 자동차 이름들을 입력받는다.
• 시도 횟수를 입력받는다.

OutputView

• 입력 요청 메세지를 출력한다.
• 에러 메세지를 출력한다.
• 실행 결과를 출력한다.
• 최종 우승자를 출력한다.

클래스 설계와 구현 후, 우테코 4기 오픈 카톡방에서 getter 사용하지 않는 것이 좋다는 이야기를 들었다.

처음에는 "아니 어떻게 getter를 사용하지 않고 구현하지?!!? 필드는 거의 getter를 사용한 것 같은데.." 하며 당황스러웠다. 해당 내용을 찾아보니 getter를 사용하지 말라는 것이 아니라, 논점은 getter를 통해 객체의 상태를 가져와서 판단하거나 직접 상태를 변경하는 방식을 지양하라는 것이었다.

 

이 내용을 이해하고 뜨끔했던 부분의 코드가 있다. CarRepository 클래스에서 우승한 자동차의 이름들을 뽑아내는 메소드였다.

Car 객체의 position 값을 getter로 가져와서 maxPosition을 찾아내고, 현재 position 상태 값을 받아와서 비교하고 판단하여 우승자를 뽑아내도록 했었다.

 

CarRepository.java

	public static ArrayList<String> getWinnerNames() {
		int maxPosition = 0;
		for (Car car : cars) {
			int position = car.getPosition();
			if (position > maxPosition) {
				maxPosition = position;
			}
		}
		ArrayList<String> winnerNames = new ArrayList<>();
		for (Car car : cars) {
			if (car.getPosition() == maxPosition) {
				winnerNames.add(car.getName());
			}
		}
		return winnerNames;
	}

 

아니 그럼 어떻게 값을 비교해서 우승자를 찾아내라는 거지?!

객체와 메시지를 주고받으며 객체가 직접 로직을 수행하도록 하자

 

객체를 사람이라고 생각하고 메세지를 주고 받는다는 생각을 하면서 코드를 수정해갔다. position 필드의 getter를 삭제하고 Car 객체에게 "너 maxPostion보다 앞에 있니?" , "너 maxPosition 에 위치하고 있니?" 라고 메세지를 보내고 그에 대한 판단은 Car 객체에게 하도록 수정했다.

 

Car.java

	public boolean isMoreAdvancedPosition(int maxPosition) {
		return maxPosition < position;
	}
    
	public boolean isMaxPosition(int maxPosition) {
		return maxPosition == position;
	}

CarRepository.java

	public static ArrayList<String> getWinnerNames() {
		int maxPosition = 0;
		for (Car car : cars) {
			if (car.isMoreAdvancedPosition(maxPosition)) {
				maxPosition = car.getPosition();
			}
		}
		ArrayList<String> winnerNames = new ArrayList<>();
		for (Car car : cars) {
			if (car.isMaxPosition(maxPosition)) {
				winnerNames.add(car.getName());
			}
		}
		return winnerNames;
	}

 

이런 방식으로 수정하다 보니 객체의 상태에 대한 자율성과 책임이 보장되는 것을 확인할 수 있었다. 앞으로 이런 방식으로 객체의 기능을 설계하고 구현해나가도록 해야겠다.

 

  클래스 / 함수 / 변수  이름  정하기  

이름을 통해 의도를 드러내라

 

이전에 프로젝트를 하면서 함수, 변수 네이밍에 크게 시간을 쏟진 않았었다. 내가 이해할 수 있는 함수 이름, 그리고 Arr이나 Num, Tmp 같은 축약된 변수들을 많이 사용하곤 했다.

 

축약은 혼란을 주고 더 큰 문제를 내포하기 때문에, 이름이 길어지더라도 역할에 대한 의도가 바로 파악될 수 있도록 하는 이름을 지으라는 피드백을 받았다. 따라서 이름 하나를 지을 때마다 많은 고민을 하게 되었고, 다른 사람들은 어떻게 지었을지 의견이 궁금하기도 했다.

함수 명명 규칙

• 메서드 이름은 lowerCamelCase로 작성한다.
• 메서드 이름은 동사/전치사로 시작한다.
  • 메서드명은 기본적으로는 동사로 시작한다.
  • 다른 타입으로 전환하는 메서드나 빌더 패턴을 구현한 클래스의 메서드에는 전치사를 쓸 수 있다.
    • ex) toString
• is/has/can
  • boolean 값을 리턴한다.
  • is는 맞는지 틀린 지 판단하는 메서드 명에 쓰인다.
  • has는 데이터를 가지고 있는지 확인하는 메서드 명에 쓰인다.
  • can는 할 수 있는지 없는지 확인하는 메서드 명에 쓰인다.
• A-By-B
  • B를 기준으로 A를 하겠다는 메소드명에 쓰인다.

CarRepository 객체에서 우승자 명단을 가져오는 메소드의 이름을 짓는데 많은 고민이 됐다.

1. getWinnerNames()
2. findWinnerNames()

get / find 와 고민이 됐다. get은 왠지 필드 getter 같고, find는 리턴해주는 게 이상하기도 하고?

그러다 나만의 기준을 정했다!

 

• get : 바로 값을 찾아주는 함수
• find : 어떠한 로직을 통해 값을 계산/검색해서 찾아주는 함수

최종적으로 이렇게 함수 이름을 정했다. List 타입으로 리턴해주니 List 라고 명시해주고, 우승자들의 자동차 이름이라는 의도가 드러나도록 수정했다. ( 함수 이름 정하면서 이렇게 고민 많이 해보긴 처음...! 앞으로 연습하고, 익숙해져 가야지!!! )

public static List<String> findCarNameListByWinner()

 

최종 코드

나름 MVC 패턴도 적용하고 객체지향스러운 코드를 짜도록 노력해봤다. 이번에도 "이게 정답이다."라는 확신은 없지만 1주 차보단 내가 어떤 의도로 작성했는지 더 자신 있게 말할 수 있다. 더더더 확신에 가득 찬 코드를 작성하게 되길 !!! 😆

최종 코드 링크

마무리

이번엔 피드백을 적용시키다 보니 코드를 작성하는데 많은 고민과 함께 시간을 보냈던 것 같다. 중간중간 어떤 게 답인지 누가 알려주길 바라거나 다른 동료들의 코드를 참고하며 이게 정답일까? 생각하기도 했다. 결과적으론 나만의 기준을 정하고, 어떤 기준과 의도를 가지고 코드를 작성했는지 말할 수 있는 코드를 작성하도록 했다. 뭐든지 정답은 없다고 생각하기 때문에, 나만의 색깔을 찾고, 협업하기 좋은 세은스러운 코드를 작성해나가고 싶다.

 

설계 과정은 아직도 쉽진 않지만, 설계 후 기능을 구현해나갔더니 리팩토링하는 과정이 더 수월하고 수정할 부분이 그렇게 많지 않았다. ( 1주 차엔 구현 후 클래스를 분리하고 수정해나갔더니 커밋 수가 어마어마했다...! ) 설계하고 기능 명세서를 작성하는 과정을 복습하며 더 연습해봐야겠다.

 

 

아직 2주 차밖에 되지 않았는데 지난 과제의 부족한 부분을 개선해나가며 조금씩 성장해나가고 있다는 게 느껴졌다. 과연 3주 차 과제와 최종 코딩 테스트가 끝난 후 얼마나 성장해있을지 궁금하고 기대가 된다! 남은 3주차 과제와 최종 코딩 테스트까지 최선을 다해봐야겠다!!! 화이팅팅 ㅎ_ㅎ