우테코 일주일 해본 소감은?

정말 시간이 너~~무 빨리 지나갔다. 거짓말 많이 보태서 마치 일주일이 하루 같았다.
처음부터 무수히 쏟아지는 공지와 낯선 크루들과의 만남.. 시작하자마자 내주는 미션과 처음 해보는 페어프로그래밍, 그리고 대망의 연극.....준비까지.....
정말 일주일이 어떻게 지나갔을 지도 모를 정도로 지나간 것 같다.
앞으로 이렇게만 간다면 10개월은 정말 지나갈 것 같다.

무엇을 했나요?

1. 온보딩 미션으로 자동차 경주를 진행했다.

분명 프리코스 때 엄청 쉽게 진행하고 자신 있었던 미션인데 한동안 공부를 놓고 있다보니 프로그래밍을 어떻게 하는지 까먹었을 정도였다.. 그래도 하나씩 해보니 몸이 기억을 하였고, 페어와 함께 소통하며 같이 구글링도 하며 정보를 공유하니 어찌저찌 진행이 되었다.

난생 처음 페어 프로그래밍을 했는데, 진짜 너무 힘들었다.
각자의 개발 스타일, 습관 등이 다른 상태에서 하나의 결과물을 내려고 하니 개발하면서 소통을 많이 하게 되고, 그러다보니 더 체력적으로 힘들어지고 시간도 지체되니 정신도 아득해진다.

2. 미션 리팩터링을 진행했다.

페어도 마찬가지로 오랜만에 개발을 하는거라 모두 가물가물했었다. 그래서 일단 해보자! 는 마인드로 시작을 했다.
물론 요구사항 정리는 하였지만, 디테일하게는 하지 못하였고 사실 내가 정리하는 스타일과는 다르게 정리가 되어서 진행하는 데 있어 어려웠다.
특히 초반에 설계를 하지 않고 프로그램 흐름대로 무작정 기능 구현부터 하다보니 나중에 리팩터링할 때 구조 자체를 변경해야 하는 일이 생겼고, 그 때 머리가 조금 아팠다.

다음엔 설계를 잘 하고 진행을 해보자!

3. 연극을 했다.

엥? 우테코에서 연극? 거기 개발 공부하는 곳 아니여?

우테코는 개발 역량 뿐만아니라 소프트 스킬을 중요시 한다.
여기서 소프트 스킬이란, 글쓰기, 말하기가 해당한다.
음, 한 마디로 타인과 협업할 수 있는 능력이라고 생각된다.

그래서 100명이 넘는 곳에서 연극을 했다. (ㅋㅋㅋ)
사실 연극을 준비하는 과정과 연극을 하면서 굉장히 힘들었다. 처음 보는 사람들과 함께 협업하는 것도 힘든데 처음해보는 연극을 진행하려고 하니 진짜 힘들었다.
그래도 덕분에 즐거웠다. 서로 안부를 물으며 조금씩 장난도 치고 빠르게 가까워지는 기분이 들었다. 덕분에 10개월 간의 긴 시간을 버틸 수 있을 것 같다는 생각이 들었다.

도이, 도치, 허브, 다즐, 엔델 모두 감사합니다~!

무엇을 배웠나요?

1. 단위 테스트에 대한 내 생각을 정리해보았습니다.

• Q. 내가 단위 테스트를 작성하는 이유는 무엇인가?
  A. 내가 짠 메서드가 의도대로 동작하는지를 코드로 검증하기 위해, 협업하는 개발자에게 내가 짠 코드의 신뢰를 주기 위해, 추후 안정적인 리팩터링을 위해 등
  페어) 미리 허점을 발견할 수 있다. main이나 sout 처럼 눈에 보이게 테스트하는 거보다 쉽고 편하게 할 수 있다. 코드에 대한 보증 역할을 할 수 있다.

• Q. 내가 작성한 좋은 단위 테스트는 어떠한 부분에서 좋은 단위 테스트라 느꼈는가?
  A. 실제 경험으로 프로덕트 코드에서 도메인 로직을 변경했을 때, 발생했으면 굉장히 크리티컬한 오류를 기존에 작성했던 테스트 코드가 잡아준 경험에서 좋은 단위 테스트라고 생각한다. 이상적으로는, 한 가지의 기능만을 테스트 하는가? 테스트하는 기능의 발생할 수 있는 예외를 모두 체크하였는가?
  페어) 메서드 네이밍, 높은 예외 발견성

• Q. 위와 같은 좋은 단위 테스트를 작성하기 위해 어떠한 시도를 해볼 수 있는가?
  A. 한 가지의 기능만을 테스트하는지 체크한다, 실패하는 예외나 오류 먼저 테스트로 확인한다, 경계값을 테스트한다. 테스트명이나 @DisplayName 으로 테스트의 의도를 명확히 나타낸다.
  페어) 좋은 설계가 좋은 테스트 코드를 낳을 수 있다. 테스트 관련 라이브러리를 잘 안다.

2. 소프트웨어 품질에 대해 생각해보았습니다.

• 좋은 품질이란?
  잘 동작하고, 읽기 쉽고, 보기 좋고, 관리하기 쉽고, 테스트 가능하고, 변경이 쉽고, 효율적이다.

• 좋은 품질을 위해 최소한 노력해야하는 것들은?
  - 하고자 하는 내용을 README에 정리한다.
  - 구조를 잡고 시작한다.
  - 일관성 있게 작성한다.
  - 여러 상황을 고려하여 최적의 코드를 작성한다.
  

• 생각해본 것들
  Q1. 코드 품질이 중요한 이유 중 가장 와닿는 이유는 무엇인가?
  A. 레벨 1 미션인 자동차 경주를 하면서도 굉장히 많은 양의 리팩터링이 필요했다. 그렇기에 변경이 쉬워야 한다는 이유가 가장 와닿는다.
  
  Q2. 위 이유를 만족하기 위한 코드를 작성하기 위해 어떠한 노력을 해봤는가? 혹은 할 예정인가?
  A. README에 요구사항을 정리하고 개발을 시작하는 노력을 했다. 하지만 자동차 미션 때 정리 및 설계를 굉장히 부실하게 했다고 느껴지기에, 다음 미션 때부터는 요구사항을 섬세히 정리하며 전체적인 구조를 잡고 프로그래밍을 시작할 예정이다.

3. 현업에서 일하고 계시는 리뷰어께 코드 리뷰를 받았습니다.

1. 파일의 맨 끝에는 개행 문자를 하나 넣어주자!

왜냐하면, IEEE가 책정한 POSTFIX 에서의 하나의 행을 정의하는 표준 때문이다.

관련 포스팅
https://velog.io/@doondoony/posix-eol
https://seongwon.dev/Git/20220303-%ED%8C%8C%EC%9D%BC%EC%9D%98_%EB%A7%88%EC%A7%80%EB%A7%89_%EA%B0%9C%ED%96%89/

2. 원시값 포장을 하는 이유와 타이밍

관련 포스팅
https://tecoble.techcourse.co.kr/post/2020-05-29-wrap-primitive-type/

3. 테스트가 불가능한 로직은 남겨두고, 가능한 것들에 집중한다.

자동차 미션 중, 0~9 사이의 난수를 생성하고 그 값이 3 이하이면 정지, 4 이상이면 출발하도록 구현했어야 했다.
여기서 난수 생성 후 자동차가 올바르게 가는지 확인하기 위해 첫 번째로 인터페이스를 활용한 전략 패턴을 사용했다.

public interface NumberGenerator() {
	public int generateNumber();
}

public class RandomNumberGenerator implements NumberGenerator {
	@Override
    public int generateNumber() {
    	return (int)(Math.random() * (end - start)) + start;
    }
}

public class FixedNumberGenerator implements NumberGenerator {
	@Override
    public int generateNumber() {
    	return 3;
    }
}

하지만, FixedNumberGenerator는 실제 프로덕트 코드보다 테스트만을 위한 코드이기에 제거하고 싶었다.
이와 관련해 리뷰어께서는 구조를 변경하라는 피드백을 남겨주셨다.
따라서 나는 전략 패턴을 버리기로 했다.
그리고 우선, 자동차가 이동하기 위해

public void move(int fuel) {
	if (fuel >= MIN_FUEL) {
		position++;
	}
}

로 이동하는 로직은 난수 생성과 분리를 시켰다.
그리고, 난수를 생성하는 클래스는

public class NumberPickerUtil {
	public static int pickNumberInRange(int start, int end) {
    	return (int)(Math.random() * (end - start)) + start;
	}
}

위와 같이 static 메서드로 만들어서 Util의 성격을 띄게 하였다.

이렇게 하면 테스트를 위한 클래스 및 코드를 만들지 않아도 된다!
또한 자동차가 값에 따라 정지 혹은 출발하는 지에 대한 테스트는 파라미터로 값을 넘겨주어 테스트할 수 있게 되었다.

4. static 메서드들만 있는 클래스들은 private 생성자를 만들어서 생성자를 통해서 생성할 수 없도록 막아준다.

그러면 앞으로는?

이제 내일부터는 새로운 조에 코치 한 분이 함께 하게 된다.
다시 새로운 사람들을 알아가는 과정이 있을 것이고, 새로운 미션인 사다리 미션을 페어 프로그래밍 하게 될 것이다.
다음 페어 프로그래밍 때는 설계를 단단히 하고 개발을 시작하고자 한다.

앞으로 학습에도 가속도를 낼 생각이다 !

그리고 첫 주를 무사히, 그리고 잘 보낸 것 같아 내심 뿌듯하며 다행이라고 생각한다.