[20230311] 우아한테크코스 5기 LEVEL 1 - 블랙잭 페어 회고

안녕하세요 ~ 헤나입니다 ! 😁

 

저번 회고는 [20230225] 우아한 테크코스 5기 LEVEL 1 - 사다리 타기 1단계 & 2단계 회고였고

3번째 미션인 "블랙잭" 페어 회고를 진행하려고 합니다 !

 

지금까지 모든 페어와 그림 그리며 설계했습니다.

매번 같은 문제점느껴서 한 번 개선하는 겸 작성했습니다.

 

🥔 : 글쓴이

 

 

 

 

 

 

 

🟧 시간이 부족해지는 설계

베로와 excaildraw 사이트에서 설계를 진행했다.

 

세 번의 미션을 진행하면서 항상 그림을 그렸었고 이번에도 마찬가지였다.

 

그리고 세 번 다 시간이 부족했다. (😕 흠)

 

 

 

 

문제를 해결하기 위해 기본적인 것을 분석해보려고 한다.

• 그림으로 설계할 때 장단점이 뭐였는가 ?
• 어떤 식으로 진행되었는가 ?
• 나의 목적은 무엇이었고 그것을 이뤘는가 ?

 

 

 

 

 

🥔 : 장점이 무엇이었는가 ?

• 구현의 정도를 협의할 수 있다.
• 같은 기능이라도 다르게 해석하는 것을 방지할 수 있다.
• 자세한 도메인 파악이 가능하다.
• 서로의 스타일을 미리 알 수 있어 페어 입장에서 생각하기 쉬워진다.

 

 

 

 

 

🥔 : 단점은 무엇이었는가 ?

• 페어 첫 날 설계에 시간을 많이 쓴다.

 

 

 

 

🥔 : 어떤 식으로 진행됐는가 ?

그날 하루가 어떻게 흘러갔을까 ?

되새김질하며 대략적으로 작성해 봤다.

• 오전 0900 - 출근출근
• 오전 1000 - 데일리 미팅
• 오전 1040 - 블랙잭 설명
• 오후 1230 - 점심 식사
• 오후 1340 - 아무것도 하지 않는다.
• 오후 1400 ~ 1800 - 페어 시작
  
  • 오후 1430 [30분] -  잡담을 나눈다.
  • 오후 1445 [15분] - 현재 페어와 이전 미션 회고를 진행한다.
    • (자신 및 페어) 아쉬웠던 점
    • (자신 및 페어) 좋았던 점
    • (자신) 개선하고 싶은 점
  • 오후 1500 [15분] - 개선할 점을 바탕으로 페어와의 규칙을 작성한다.
  • 오후 1600 [60분] - 도메인 분석, 요구사항(ReadMe)을 정리한다.
  • 오후 1730 [90분] - 그림을 이용한 설계를 진행한다.
  • 오후 1800 [30분] - 설계를 바탕으로 코드를 작성한다.

 

 

 

 

 

🥔 : 그림과 설계, 나의 목적은 무엇이었는가 ?

처음 미션 진행 방식은 크게 세 가지로 나뉘는 거 같다.

1. 요구사항 정리 -> 구현
2. 요구사항 정리 -> 그림 -> 구현
3. 그림 -> 요구사항 정리 -> 구현

 

세 가지 방법 다 좋은 방식이다.

그래도 나는 두 번째 진행 방식을 선호한다.

이유는 다음과 같다.

• 요구사항 정리
  
  • 메인 기능을 파악할 수 있다.
  • 주의해야 할 부분을 알 수 있다.
• 그림, 설계
  • 정리한 기능의 플로우를 파악할 수 있다.
  • 도메인을 제대로 이해했는지 알 수 있다.
  • 서로 다른 그림으로 페어와의 차이점을 파악할 수 있다.
  • 구현이 가능할지 얼마나 걸릴지 가늠할 수 있다.
  • 설계가 기록으로 남아 이후에 용이하다.

 

원하는 흐름을 정리하면

요구사항 정리를 통해 핵심 기능을 파악하고

그림으로 설계하며 기능의 흐름이나 주의할 점을 알 수 있다.

 

또한 페어와의 차이점을 알 수 있기에 

이후에 구현하면서 부딪히거나 서로 다른 방향으로 진행할 확률이 낮아진다.

 

 

 

 

 

 

🥔 : 그림과 설계, 목적이 이루어졌는가 ?

세 번의 미션 동안 페어와 설계, 구현으로 의견 차이로 힘든 일이 없었다.

 

"그림을 이용해서 의견 차이로 힘든 일은 없었다" 라고 확답하기는 어렵다.

 

개인적인 대답이라면 "그렇다"라고 얘기하겠다.

구현하면서 헷갈리거나 방향이 달라진다면 "그림"을 보면서 얘기했다.

중간 지점이 있기에 갑자기 다른 방식의 구현이 될 일은 없었다.

 

물론 다른 방향으로 설득하거나 되기도 했다.

이러한 경우에는 그림을 수정하면서 설득할 수 있다.

협의된 그림이 있으니 어디에 무엇이 추가, 삭제, 수정이 될지 설명하기도 이해하기도 쉽다.

 

아무래도 "그림"을 통한 이점은 꽤나 많았다.

90분 정도 그림에 소비했지만 이후에 일은 순탄해졌다.

 

충분히 의미 있다고 생각한다.

 

 

 

 

 

🥔 : 왜 시간이 부족하다고 생각할까 ? [네 가지 생각]

페어와 나 둘 다 시간이 부족하다고 느껴졌다. 계산해 보면 90분 정도만 더 설계에 투자했을 뿐이다.

 

90분이 없어졌어도 충분히 미션을 제출할 수 있다. 결국 그림 그리는 것 자체의 문제가 아니었다.

 

그렇다면 그림을 그리는 것 자체에서 애매한 느낌이 있어서 그런 거 아닐까 ? 🧐

일단 생각나는 것을 적어보자.

• 규칙이 없다. (시간 제한, 그림 그리는 방식, ...)
• 결단이 필요할 때 서로 양보한다.
• 개선할 수 있는 부분을 깊게 생각한다.
• 사실 미션이 어렵다.

 

나름 그럴듯하다.

 

코드 이외의 것을 뜯어보는 것을 좋아하지는 않지만 생각을 더 뜯어봐야 한다. (💆‍♂️ 주물럭)

 

 

 

 

 

 

 

첫 번째, "규칙이 없다."

 

그림 제안은 내가 했다.

정확히 "제안"만 했다.

 

🥔 :
"나"는 이런 식으로 했었다.
"나"는 이런 생각을 한다.
"나"는 이걸 추천한다.

 

 

아무런 생각 없이 단순히 "좋다"라는 말로 판단을 맡겼다.

 

😊 (페어) :
그래서 좋은 점이 뭔가요 ?
그래서 규칙이 있나요 ?
그래서 그림 어떻게 그리나요 ?

🥔 (헤나) :

그냥 좋던데..?

 

 

 

 

 

 

 

 

장난하나

 

 

 

 

 

 

 

그러면 어떻게 해야 할까?

 

먼저 내 규칙을 정해야 한다.

 

페어 시간이 적기 때문에 너무 많은 시간 투자할 수는 없을 거 같다. (칼퇴 기준)

미션이 어려울수록 설계에 시간 투자를 더 하겠지만 자세한 설계가 되지 않도록 주의하자.

대략 60-90분 정도 생각하고 있다.

 

기존에 하던 나만의 규칙은 다음과 같다.

• 그림을 그릴 수 있는 도구를 이용한다.
  • 인피니티 캔버스 (excaildraw, ...)
  • 코드 다이어그램 (mermaid.js, ...)
• UML은 어떤 거로 할 것인가 ?
  
  • 클래스 다이어그램 (+ 관계 UML 표기)
• 얼마나 자세하게 그리는가 ?
  • 어떤 책임을 지니는가만 판단할 수 있게 그린다.
  • 어떤 데이터를 갖는지는 표시하지 않는다.
• 책임을 지니는지 판단은 어떻게 하는가 ?
  • 도메인 흐름을 보면서 필요한 클래스가 있다고 느껴질 때 책임을 부여한다.
• 원시값 포장, 불변 객체, 일급 컬렉션 등을 생각하는가 ?
  • 빠른 진행을 위해서 기본적으로 뭉쳐서 생각하고 복잡해서 보기 힘들 때 분리하자.
• 시간제한은 어떻게 두는가 ?
  • 60분 이내로 애플리케이션 한 플로우가 돌아갈 수 있도록 그림을 그린다.
• 개선할 수 있을 법한데 시간이 없다면 어떻게 할까 ?
  • 바로 적용할 수 있다면 진행하되 그렇지 않다면 구현하면서 리팩터링 하자.

 

 

이 방법이 정답이 아닌 것은 당연하다. (정답이었으면 좋겠지만)

틀린 부분도 있고 맞는 부분도 있을 터이니 페어와 함께 합의점을 도출해 내자.

 

 

 

 

 

두 번째, "결단이 필요할 때 서로서로 양보하지는 말자"
세 번째, "개선할 수 있을 거 같다고 해서 깊게 생각하지 말자"

 

 

설계할 때 서로 의견이 갈리는 부분이 있다.

서로 양보하는 상황인 경우 결정하지 못해서 시간이 오래 걸렸다.

그렇다 해서 서로 의견을 내세우기만 하는 것도 시간이 오래 걸린다.

 

👀 엥 ?

 

결론부터 얘기하면 단순한 코드를 작성하자.

 

클린코드 책에서 나오는 "깔끔한 코드를 구현하기 위한 설계 규칙 네 가지" 를 보면 이유를 알 수 있다.

 

첫 번째, 설계는 의도대로 돌아가야 한다.

이를 간단하게 검증하기 위해서 테스트를 작성한다.

 

두 번째, 우수한 설계는 중복이 없다.

중복은 추가 작업, 추가 위험, 불필요한 복잡도를 의미한다.

 

세 번째, 이해하기 쉬운 코드를 작성한다.

프로젝트 유지보수에 들어가면서 코드를 변경할 때 유지보수하는 개발자가 시스템을 제대로 파악할 수 있도록

의도가 보이는 이해하기 좋은 코드를 작성해야 한다.

 

이 중에서 네 번째,  "클래스와 메서드 수를 최소로 줄여라, 단 실용적 관점에서 타협하라."를 얘기하고 싶다.

 

의도대로 돌아가고

중복을 제거하고

의도를 표현해도

 

조그마하게 클래스와 메서드를 만들면 간단한 애플리케이션을 복잡하게 만들게 된다.

 

Daan의 글에서 나온 주니어, 미드 레벨, 시니어 개발자의 차이점 내용이다.

 

개발자가 주니어인지 어떻게 구분하나요 ? 🤫

Daan : 
주니어 개발자들은 화려하고 복잡하게 짜는 것을 선호합니다.
one-liner들과 복잡한 추상화의 과도한 사용을 보면 주니어 개발자의 코드라고 생각하면 됩니다.

주니어 개발자들이 다른 개발자들에게 자신들이 얼마나 코드를 잘 짜는지 자랑하는 방법입니다.

 

그렇다면 시니어 개발자는 어떤가요 ? 🤔

Daan :
시니어 개발자는 KISS 법칙을 따릅니다. [KISS (Keep It Simple, Stupid)]
단순하고, 단도직입적이며, 멍청해 보이는 코드를 작성합니다.

시니어 개발자는 자신이 짠 코드를 미래에 만질 다른 사람들을 생각하며 작성한다면
주니어 개발자들은 컴퓨터에서 잘 돌아가는 것만 생각합니다.

 

멋진 코드보다 멍청한 코드를 작성하는 게 나을 거 같다.

 

그렇다 해서 시니어도 주니어도 신입조차 아닌

응애 개발자인 내가 단순하게 작성한다고 의도가 명확할 수 있을지 사실 잘 모르겠다. 🤓

 

 

 

 

 

 

네 번째, 사실 미션이 어렵다.

 

 

하하 이건 뭐

 

 

 

 

 

 

 

이번에도 페어 회고를 작성하려 했다.

작성하고 보니 개인 회고 같지만 개인 미션이라면 결코 느끼지 못했을 부분이다.

 

정리하자면

• 설계 때문에 시간이 부족하지는 않다.
• 효율적으로 설계하려면 규칙을 만들고 진행하자.
• 멋진 코드가 아니라 멍청한 코드를 작성하자.

 

👍