레벨 1 - 사다리 타기 회고

주노·2023년 2월 20일

5기 레벨1 미션 백엔드 우아한테크코스

우테코 5기 회고

목록 보기

2/12

서론

페어 도이와 미션 사다리타기를 진행했다.

페어로 매칭되기 하루 전에 청소하다가 인사했었는데 이렇게 만나다니 정말 우연도 이런 우연이 😮

이번 미션은 TDD를 최대한 적용해보는 과정을 통해 TDD에 익숙해지는 것에 초점을 두고 미션을 진행했다. 낯선 방식에 속도는 느렸을지언정 그 과정은 정말 재미있었다.

이번 페어프로그래밍이 끝나고 회고에 대한 특강이 있었는데 스스로에 대한 회고, 페어에 대한 회고를 작성하면서 많은 점을 느낄 수 있었다.

소프트스킬

💡 소프트스킬?
소프트 스킬이란 다른 사람과 함께 일하고 상호작용하는 방식을 나타내는 대인관계 스킬을 의미한다.

좋았던 점

구현에 조급한 마음을 내려두고 진행할 수 있어서 좋았다.

이번 미션에서는 시간내에는 무조건 낼 수 있다는 (근거없는)자신감과 함께 TDD를 가장 우선순위로 두고 미션을 진행하기로 마음먹었다.
덕분에 급한마음 없이 차분하게 TDD와 친해지는 시간을 가질 수 있었다.

혼자 미션을 진행할때는 어느순간 TDD를 망각하고 클래스 내부 구현을 먼저 하고있는 모습이 나오곤 했는데 페어와 같이 진행하면서 "저희 TDD 먼저 해야해요" 하면서 서로의 이정표가 되어주었던 부분이 너무 좋았다.

5분타이머

이전 강의시간에 코치님이 말씀하셨던 내용중
한명이 코드를 치다가 다른사람에게 넘어갔을 때 이어서 치지 못한다면 그것은 페어프로그래밍을 제대로 하고 있지 않다는 의미다 라는 말씀을 해주셨던 것이 인상깊어 이번에는 꼭 타이머를 재보자고 마음먹었다.

위 내용을 계속해서 인지하며 5분 타이머를 맞춰두고 페어프로그래밍을 진행하려고 노력했다.
페어도 함께 적응해주어 원활한 교대가 이뤄질 수 있었다.

고민시간

성급한 코드작성보다는 토론을 통해 서로의 근거를 명확하게 밝히는 것이 더 의미있다고 생각하여 페어와 코드를 작성하다가 구조적으로나 기술적으로 고민이 생기면 타이머를 멈춰두고 키보드에서 손을 뗀 뒤 토론을 하는 시간을 가졌다.

테스트를 작성하기 전에도 항상 타이머를 멈추고 페어에게 "이 객체는 무슨 역할과 책임을 가져야할까요?" 라는 질문을 통해 한번 정리하는 시간을 가졌는데 이러한 과정이 너무 마음에 들었다.

아쉬웠던 점

페어에게 집중하는 시간

개인적으로 너무 많은사람과 인사하고다니면서 페어에게 집중하지 못했던 것이 아쉬웠다.
하루는 사물함에 키보드를 가지러갔다가 다른사람이 어려움을 겪고있어 이를 해결해주고 온다고 시간이 지체된적이 있었다.

페어프로그래밍 시간에 온전하게 페어에게 집중하지 못한 점이 가장 큰 아쉬움으로 다가왔다.

만나자마자 미션이야기로 시작해서 아쉬움

만나자마자 "저희 미션 요구사항부터 확인해볼까요?" 라고 말을 꺼냈던 점이 굉장히 아쉬운 부분으로 다가왔다. 페어와 좀더 친해지는 시간을 가지고 미션을 진행했다면 보다 편한 분위기에서 자유로운 토론이 가능했을지도 모르겠다.

하드스킬

💡 하드스킬?
하드 스킬은 특정 훈련을 통해 개발할 수 있는 스킬을 의미한다.

좋았던 점

제네릭 인터페이스

어떤 랜덤한 값을 만드는 일을 수행하는 인터페이스 RandomGenerator를 만든 뒤 이를 구현하는 RandomBooleanGenerator를 만들어 랜덤한 Boolean값을 생성하는 로직을 구성했다.

Generics를 사용한 이유에 대한 질문을 받았는데 다음과 같은 답변을 했다.

확장성을 고려한 설계와 현재 구현에 최적화된 설계 사이의 적절한 트레이드 오프를 생각해볼 필요가 있을 것 같다.

View를 static으로 사용하는 이유

InputView, OutputView의 메소드를 static으로 구성했다.
리뷰어 토미가 이 부분에 왜? 라는 질문을 주었을 때 다음과 같은 답변을 했다.

스스로의 생각을 주장해보는 좋은 경험을 할 수 있던 것 같다.

해당 내용에 대해서는 토미와 데일리때 직접 만나서 이야기를 나눴는데 static 필드는 전역으로 관리되기 때문에 프로그램 전체에서 이 필드에 접근할 수 있고 변경할 수 있으므로 해당 필드를 추론하기 어려워 테스트하기가 까다롭다는 의견을 받을 수 있었다.

이 과정에서 나왔던 토미의 질문 하나가 뇌리를 계속 맴돈다.

여러분이 static을 사용하는 이유를 말 할때 메모리를 항상 이야기하는데, 실제로 객체의 과도한 생성으로 인해 메모리가 부족했던 경험이 있을까요?

음.. 한번도 생각해보지 못한 내용이였다.
그동안 static을 "남들이 다 그렇다고하니까 메모리아껴야지~" 하면서 사용했던 것 같아 깊이 고민해볼 내용이라고 생각했다.
static을 사용할 때 jvm 동작과정에 대한 깊은 이해를 기반으로 보다 설득력있는 근거를 제시할 수 있도록 하드 스킬을 다져두는 것이 좋겠다. (기술부채 : static method를 사용했을 때의 장,단점)

현재로서 내가 가지고있는 근거를 비교해보았을 때 토미의 설명이 더 합당하다고 생각하여 View의 메소드를 non-static으로 변경했다.

근거를 확실히 하기위한 동기부여가 있었기에 좋았던 점으로 분류하고싶다.

아쉬웠던 점

스스로 알고리즘이 부족함을 느낌

진행 과정에서 사다리 생성 규칙(true 뒤에는 true가 나올 수 없음)과 관련된 로직을 구성하는 데 뭔가 로직을 더 깔끔하게 짤 수 있을 것 같은 느낌만 들고 이에 대한 해결책은 생각나지 않아 굉장히 답답했다.

추후에 리팩터링을 하면서 확인한 부분이지만 설계구조상 특정 행위에 대한 책임을 명확히 하지 않아 생겼던 문제였던 것을 알았다.

보다 유연한 사고를 위해 알고리즘 공부도 어느정도 해야할 것 같다.

느린 학습속도

학습속도가 느려 기술부채로 남겨두고 넘어가는 부분이 상당 수 있었다.
즉시 해당 기술을 학습하고 적용하고 싶었지만 페어프로그래밍을 하면서 이러한 기술부채를 즉각 해결하지 못한부분이 조금은 아쉬웠다.

개인적으로 저녁에 남아서 기술부채를 해결하는 시간을 가져도 괜찮을 것 같다.

설계의 아쉬움

TDD를 진행하고 이후 클래스 래핑에 대해 집중하다보니 큰 설계를 놓치고 중복되는 역할을 가진 객체를 만들었다. 객체에 보다 명확한 책임을 주는 연습을 할 필요가 있다.
설계도를 직접 그려보는 방식으로 이를 해소할 수 있다는 생각이 든다.

페어프로그래밍

페어에게 좋았던 점과 아쉬웠던 점을 정리해보려고한다.

좋았던 점

새로운 시도방식을 제안하는 것이 좋았다.

git commit을 할때 공동 작성자를 등록할 수 있다고 알려줘서 더 즐겁게 페어프로그래밍을 진행할 수 있었다.
블로그로 글을 따로 정리해둘 정도로 해당 방식이 너무 마음에 들었다.
페어프로그래밍인데 커밋은 한명이?

~ 해보면 어떨까요? 제안형태의 대화방식

상충되는 의견이 있을 때 정답이 있는 방식이 아닐 때마다 ~한 방식을 사용해보는건 어떨까요? 라는 말이 도전해보고싶게 만드는 마법의 말이였던 것 같다.

대표적으로 페어의 코드를 가져오는 과정에서 원래 알고있던 방식은
(작업 X 컴퓨터) 페어의 레포지토리로 remote 연결 -> git pull로 로컬로 가져오기 -> remote를 나의 레포지토리로 변경하여 push 하는 방식만 알고있었는데, 페어가 다음과 같은 방식을 제시해주었다.
(작업 O 컴퓨터) 페어의 레포지토리로 remote 연결 -> git push로 내용 넘겨주기

위와 같은 방식을 적용하기 위해 git repository의 contributor를 지정해야한다는 사실도 알게 되었다.

예상외의 방향으로도 진행할 수 있는 부분을 보고 정말 정답은 없다는 말이 와닿았다.

아쉬웠던 점

특별히 아쉬웠던 점은 없었다

한가지 굳이 꼽자면 약간 반대되는 의견에 대한 불꽃튀는 충돌이 없었다는 부분...?
서로 설득을 너무 잘해서 의견 차이는 있어도 충돌은 없었던 것 같아 약~~~간 아쉬운 부분이 있기는 하다.

조금 더 설득하기 어려운 페어를 만난다면 깊이있는 근거를 충분히 고민해볼 수 있는 좋은 표본이 될 것 같다.

지나가는 아무 크루나 붙들고 설득해봐야하나 😅
설득하기 어려운 크루를 원한다는거 보고 무작정 싫은데요? 라고 하지말아주세요 ㅠㅠ

정리

좋은 피드백을 받고싶다면 내가 먼저 그러한 피드백을 해주는 것이 옳게된 피드백이라는 포비의 말을 들었다.
아직은 페어에 대해 아쉬운 점을 말하는 것이 어색하긴 하지만 피드백을 받는 입장에서는 큰 도움이 될 것을 인지하고 익숙해지는 시간을 가져보자.

피드백을 회피하면 돌아오는것은 아무것도 없지만, 피드백을 수용하면 더욱 성장한 나의 모습이 기다리고있다는 점을 항상 마음속 깊이 새겨두자.

서로 해결해줄 수 있는 부분은 공유하고, 서로 모르는 부분은 함께 채워가는
기술부채를 해결하는 토론스터디? 구상을 해보는것도 나쁘지 않을 것 같다

아직 스터디를 하고싶은 마음은 없지만 일단 생각만 해두는걸루...

페어와 함께 지키면 좋을 점에 대한 간략한 정리를 하고 마치려고한다.

이 글을 보는 사람중 페어프로그래밍을 진행할 사람들은 아래 내용을 가지고 몇가지 추려 사용해도 괜찮을 것 같다.

다음은 우테코 5기 페어프로그래밍 수업을 통해 설정한 10계명(?)이다.

짝 프로그래밍의 장점은 ‘빈번한 교대’를 통한 ‘발견’이다
코드의 소유와 책임은 개인이 아닌 팀이다. 실수에 대해 개인을 비난하지 않는다
코드에 대한 지적이 내 인격에 대한 지적이 아니란 걸 잊지 않는다
침묵은 금이 아니다
중간에 휴식 시간을 가지거나 간식을 나눠 먹으며 우애를 다지자
나에게 당연하다고 페어에게도 당연한 것이 아니다
내가 알고 있는 것을 상대방이 모를 수도 있고, 내가 모르는 것을 상대방이 알 수도 있다
이해 못했을 때 이해한 척하지 말자
때론 고집을 버리고 짝을 통해 내가 전에 하지 않았던 걸 시도해보자
절대적으로 옳은 생각은 존재하지 않는다

위 내용을 포함하여 다음과 같은 페어룰을 정할 수도 있을 것 같다.

도메인 설계내용 도식화해보기 ex) draw.io, keynote, ppt 등
5분마다 드라이버-네비게이터 교체하기
8번 교체마다(한사람이 4번 드라이빙하면) 5~10분 휴식하기
궁금하거나 의견차이로 인한 토론이 필요한 경우 시간을 멈추고 토론하기
TDD를 진행한다면 네비게이터는 의식의 흐름을 경계한다! (테스트 작성 이전 선 구현 방지)
페어와 처음 만나고 10분동안은 미션 이야기 하지않기! (서로에 대해 알아가는 시간을 가집시다!)
페어와 같이 밥먹기! (페어를 만난 날 혹은 다음날에는 꼭 한번 밥을 같이 먹읍시다!)

🪜 사다리타기 - 1단계 PR

Step2

기존에 사다리의 모양만 만들었다면 step2에서는 사다리 게임을 구현하는 시간을 가졌다.

소프트스킬

step2의 진행과정은 페어프로그래밍이 아니였지만 다양한 크루들과 소통하면서 소프트스킬을 어느정도 익힐 수 있었다.

💡 소프트스킬?
소프트 스킬이란 다른 사람과 함께 일하고 상호작용하는 방식을 나타내는 대인관계 스킬을 의미한다.

좋았던 점

🦻 다양한 의견 들어보기

다양한 크루들이 각자 다른방식으로 사다리 게임을 구현하는 모습에서 다양한 관점을 얻을 수 있었다.

크게 두가지 방식으로 갈렸는데 각각의 장단점이 있다고 생각했다.

사다리 자체의 역할에 집중

사다리 자체가 시작점을 주면 결과지점을 반환하는 역할을 부여하는 방식이 있었다.

이 경우 로직을 구성하는데 있어 도메인간 의존도를 크게 신경쓰지 않아도 된다는 장점이 있다고 생각했고, 반대로 요구사항이 깊어질수록 수정에 어려울 수도 있다는 단점이 생각났다.

ex) 사다리 게임이 진행되는 단계를 각각 출력하여 표현해주세요.

참여자의 역할에 집중

참여자가 한단계씩 움직이는 단계에 집중하는 방식이 있었고, 나 또한 이 방식을 채택하여 생각했다.

해당 방식은 참여자의 입장에서 게임을 진행한다는 과정을 TDD로 표현하기가 수월하다는 장점이 다가왔고, 도메인의 분리과정에서 자칫하면 도메인간 의존이 쉽게 생길 수 있다는 단점이 존재했다.

이게 단점이 맞나..? 아직 숙련도가 부족하기 때문에 단점으로 다가오는 내용일 수도 있다.
오히려 객체간 의존도를 경계를 연습할 수 있어서 더 좋았다.

동일하게 참여자의 움직임에 집중한 사람이여도 세부적인 구현에 따라서도 진행방식이 모두 다른 모습을 보고 굉장히 신기했다.

학습로그 말하기

학교 동아리에서 교육을 맡았을 시절 그때만큼 학습 및 학업에 가장 즐겁게 임하던 때가 없었다.
공부를 하면서 누군가에게 내가 학습한 내용을 설명하는 일 만큼 즐거운일이 없다고 생각하면 나만의 학습 방법을 터득한 날이였다.

군대를 갔다오며 한동안 이러한 학습방식을 적용할 환경이 되지 않았던 나는 아마 이러한 즐거움을 잠시 잊었던것 같다.

학습로그 말하기 활동을 통해 블로그로 작성했던 내용을 페어에게 말로 다시 설명하면서 지식을 체화할 수 있는 시간을 가졌다.

누군가에게 내가 알게된 무언가를 알려줄 때 비로소 지식이 체화된다는 말이 생각나는 좋은 활동이였다.

아쉬웠던 점

미션의 집중도

개인적으로 테코톡 발표준비를 하느라 미션에 온전히 집중하지 못한점이 아쉽다.
개인 컨디션관리도 잘 못한부분도 있다.
매일같이 11시까지 캠퍼스에 남아서 집에 도착하고 씻고 자기전에 정리하고 자면 새벽 1시...
아침 6시반에 칼기상하고 하다보니 몸살이 도진것같다.

주말에는 감기까지 이어져서 몸상태로는 굉장히 아쉬운 한주였다.

아프다고 봐주는 세상이아니다.. 컨디션 관리도 능력이라고 생각되는 요즘이다.

소프트스킬이라고 보기엔 조금 엇나가는 측면이 있지만 그래도 개인의 몸상태가 협업과도 연관은 있을것이라고 생각한다.

도식화 능력

도식화를 시도해본 것은 굉장히 긍정적으로 다가왔지만...

다양한 크루들에게 눈뽕, 독개구리색깔같다는 의견을 들었다.
막상 만들때는 오.. 구분이 된다! 정도로 만족했었는데 다시 보니 정말 눈이 아픈 색깔들의 부조화가 가득했다 😂

여러분의 눈을 지켜드리기위해 사진은 첨부하지 않았습니다만 굳이 보고싶다면...
주노의 눈부신 도식화 보러가기

다음에는 🌱허브가 추천해준 mermaid를 사용해봐야겠다.

하드스킬

💡 하드스킬?
하드 스킬은 특정 훈련을 통해 개발할 수 있는 스킬을 의미한다.

좋았던 점

원시값 포장

왜 원시값을 포장해야하지? 라는 의문점에 스스로의 답변을 할 수 있을 정도의 주장을 잡을 수 있었다.

기존에는 단순히 로직을 함께 포장하여 상위 도메인의 로직이 간단해진다는 단순한 이유를 생각하고있었는데,
리뷰어에게 다른 객체들과 메시지를 주고받으며 협력할 수 있는 역할이 필요할때 라는 좋은 기준을 얻을 수 있었다.

아쉬웠던 점

구체적인 근거 부족

public void run() {
    Players players = repeat(() -> initializePlayers(inputView.askPlayerNames()));
    Products products = repeat(() -> {
			Products result = initializeProducts(inputView.askResultProducts());
			new Results(players, result);
			return result;
    	});
    Results results = new Results(players, products);
    int height = repeat(inputView::askLadderHeight);

    LadderGame game = new LadderGame(players, height);

    List<Line> lines = game.getUnmodifiableLines();
    outputView.showLadderGame(players, lines, products);
    game.play();
    checkResult(results);
}

위와 같이 Controller 단에서 함수형 인터페이스를 이용해 Lazy Evaluation을 통해 재입력을 제어하고자 구성했다.

이중 Products를 정의할 때 한가지 고민이 생긴다.

// 1번 방식
Products products = repeat(() -> {
	Products result = initializeProducts(inputView.askResultProducts());
	new Results(players, result);
	return result;
});
        
// 2번 방식
Products products = repeat(() -> initializeProducts(inputView.askResultProducts(), players.size()));

Results 객체는 생성될 때 players, products 두 객체의 size를 비교하여 올바르지 않을 경우 예외를 반환한다.

1번 방식의 경우 players, products를 모두 알고있는 Results의 검증방식을 이용하여 재입력과정을 진행한다.
위 방식의 경우 의미 없는 Results 객체를 생성하기 때문에 되려 복잡한 코드가 될 것이라고 생각했다.

2번 방식의 경우 initializeProducts() 메소드에 players에 대한 검증을 추가한 방식이다.
해당 검증방식을 이용하면 검증이 Controller, Results 객체에서 중복된 검증이 일어나며, Controller에서 도메인에 대한 검증 로직이 생기는 어색한 상황이 생긴다.

생각 나는 방식 중 2번의 경우가 읽기는 더 편할 것 같아 채택했지만 정작 어색한 문장을 만들고 나니 스스로 조차 설득하기 어려운, 아쉬운 상황만 있었다.

미션을 진행하다 보면서 스스로를 설득할 만한 코드를 작성해보도록 노력해야겠다.

🪜 사다리타기 - 2단계 PR