서론

페어 저문과 함께 체스미션을 진행했다.
이전에 이야기를 많이 나눴고 많이 친해졌던 크루였기에 초기에 보다 수월한 진행을 할 수 있었다.

미션이 진행될수록 방대해지는 도메인의 크기에 지레 겁먹고 제 시간내로 구현하지 못할 것이라는 생각에 조급함을 느끼기 시작했다.

블랙잭 미션을 수행할때도 마찬가지였지만 스스로의 조급함을 통제하는 연습이 아직은 많이 부족한 것 같다.

이러한 부분이 페어의 진행상황에도 영향을 미쳤던 것 같아 미안한 마음이 많이 든다 🥲

체스 미션은 여지껏 미션중 스스로의 부족함을 가장 많이 깨달았던 시간이였다.

소프트스킬

💡 소프트스킬?
소프트 스킬이란 다른 사람과 함께 일하고 다른 사람들과 교류하는지를 설명하는 대인관계 기술로 충돌 해결, 비판적 사고, 공감, 조직, 리더십, 팀워크, 시간관리 등을 포함한다.

좋았던 점

페어프로그래밍 준비

사다리 미션부터 준비하고있던 페어프로그래밍 규칙을 사용했을 때 함께 작업한다는 느낌을 받을 수 있었다.

페어프로그래밍 10계명(?)과 함께 정해둔 규칙을 리마인드 해보자.

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

페어프로그래밍 체크리스트!

• 페어와 같이 밥먹기!
  • 페어와 말 편하게 하면 더 좋음!
• 페어와 처음 만나고 10분동안은 미션 이야기 하지않기!
• TDD를 진행한다면 네비게이터는 의식의 흐름을 경계한다!
  • 네비게이터는 드라이버가 클래스 생성 시 저희 TDD 해야죠! 라는 말 해주기
• 궁금하거나 의견차이로 인한 토론이 필요한 경우 시간을 멈추고 토론하기
  • 주관적인 생각 및 기준이 있다면 굽히지 않고 서로 어필하며 토론을 진행하기!
  • 설득 하는쪽이 이기는걸로!
  • 서로 설득이 안된다면 일단 드라이버의 의견을 따른 뒤 추후 토론으로 이어가기!
• 50분 마다 5~10분 휴식하기
• 5분마다 드라이버-네비게이터 교체하기

네오와 페어프로그래밍

체스미션 1,2단계가 끝나고 수업시간에 네오와 페어프로그래밍을 할 수 있는 기회를 가졌다.

내 코드를 가지고 4단계 DB 연결하기 작업을 진행했다.

많은 사람들 앞에서 내 코드를 보여주는것이 조금은 부끄러웠지만 언제 또 이런 기회를 얻을 수 있을까 싶은 마음에 최대한 집중해서 수업(코딩?)을 진행했다.

주어진 문제를 시간 내로 빠르게 해결하는 방법에 익숙해지는 시간을 가질 수 있었다.

아쉬웠던 점

기술부채의 부재

시간에 쫓기듯이 작업을 수행하다보니 천천히 생각하면서 기술부채를 쌓는 시간이 부족했다.
리팩터링을 진행하면서라도 몰랐던 부분을 인지하기 시작했지만 처음 코드를 작성하면서 내가 정말 알고쓰는것인지 의심하는 시간이 부족했던 부분이 아쉬웠다.

학습을 중심으로 미션이 진행되었을때의 성취감이 더 높다는것을 다시금 생각했다.

하드스킬

💡 하드스킬?
특별하게 훈련할 수 있는 기술로 각 분야별로 해당하는 요소가 다르다.
엔지니어링의 경우 프로그래밍언어(Java, Python 등), 클라우드 컴퓨팅, 서버 유지보수 등을 포함한다.

좋았던 점

함수형 인터페이스

낯선 문법이였던 함수형 인터페이스를 직접 사용해보면서 어떻게 읽을 수 있고, 언제 사용할 수 있는지를 직접 체감할 수 있는 시간이였다.

대표적으로 Command를 입력받고 어떤 행위를 수행한다는 점에서 함수가 공통되는 행위를 수행한다는 것을 볼 수 있었다.

최근에 모던 자바 인 액션을 읽기 시작했는데 책의 앞장에서 서술되었던 동작의 파라미터화라는 문구가 생각났다.
함수의 행위를 파라미터로 인지하고 함수형 인터페이스를 사용해 코드를 보다 간략하게 표현할 수 있었다.

책만 봤을때는 잘 와닿지 않았던 내용인데 직접 겪어보면서 이해하는 과정이 즐거웠다.

캡슐화의 기준?

중간에 다른 크루들과 토론한 내용 중 상속은 캡슐화를 깨는 구조다라는 말이 있었다.

부모의 생성자를 호출해야만 하기 때문에 상속을 받는 자식클래스에서 부모의 구조를 알 수 밖에 없기 때문에 상속은 캡슐화를 깰 수 밖에 없는 구조라는 이야기가 나왔다.

// 예시
public abstract class Parent {

	private final String name;
    
    Parent(String name) {
    	this.name = name;
    }

	...
}

public class Child extends Parent {
	
    Child() {
    	// 이 시점에서 부모의 필드에 무엇이 있는지 알게 된다
	    super("이름");
    }
    
	...
}

그렇다면 몇가지 의문이 생길 수 있다.

• 상속은 안티패턴인가?
• 상속은 무조건 피해야만 하는걸까?
• 객체지향적이지 못한 구조라면 왜 상속이 생겼는가?
• 캡슐화는 왜 지켜야하는가?

위와 같은 질문들이 들어왔을 때 아직 명확한 답변은 하지 못할 것 같다...

객체지향의 기본 원칙에 대해 다시 한 번 정리할 필요성을 느꼈다.

객제 지향 프로그래밍의 4가지 특징

아쉬웠던 점

디자인패턴 이해도

다른 크루들이 상태패턴, Command 패턴 등 다양한 디자인패턴을 가지고 자신의 프로젝트에 적용하는 모습을 봤다.

나는 디자인패턴을 봤을 때 어떤 방식으로 적용해야할지 감을 잘 잡지 못하기 때문에 디자인패턴에 대한 이해를 포기하고 구현에 집중했다.

구현을 하다보면 디자인패턴이 자연스럽게 나온다고 생각했기 때문이다.

디자인 패턴이 정답은 아니나 빠른 해결책 제시에 도움을 줄 수 있다. 라는 입장에서 빠른 해결책 제시를 경험하지 못한 부분에서 아쉬움을 느꼈다.

DB 적용과정

이전에 개발을 진행하면서 테이블 구조를 먼저 구성한 뒤 프로젝트를 시작하는 경우가 빈번했다.
PK, FK 등 테이블의 연관관계를 중요시하고 정규화도 전부는 아니지만 어느정도는 적용시켜 DB구조가 항상 1순위였다.

JDBC를 사용하면서 값을 불러오는 방식도 너무 어색했고, 이미 만들어둔 객체에 어떻게 id를 Mapping할지 조차 잘 떠오르지 않았다.

게다가 객체간 연관관계가 존재했을 때는 어떻게 풀어나갈지 막막했다.

결국 데이터의 중복을 허용해가면서 테이블 하나에 모든 값을 넣었다.

작성한 구조의 문제인지, 테이블 설계의 문제인지, 단순히 생각을 못하고있는것인지...

모든 미션을 통틀어 가장 아쉽고, 가장 부족했던 부분이다.

정리

미션을 진행하면서 많은것을 배울 수 있었지만 그만큼 실제로 얻은 내용이 많지 않은 것 같다.

모두가 같은 미션을 진행하면서 다른 내용을 알아간다는 것은 알고있지만 그래도 아쉬운건 어쩔수 없나보다. 😂

가장 어려운 미션을 함께해준 페어 저문에게 다시한번 감사인사를..🙇‍♂️

다른 누군가와 협업할 때 부끄럽지 않은 사람이 되기 위해 하드 스킬도 열심히 익혀두자 🔥