🎯 이번주 Action Plan 회고하기

• 페어 프로그래밍을 진행하며 페어에게 배울 점과 아쉬운 점을 찾는다. (진행 중)
• 레벨 1에서 미션 뿐만 아니라 개념까지 얻기 위한 플랜을 생각해본다. (완료)

1. 이번 주는 페어 프로그래밍이 없어서 아직 첫 번째 플랜은 시도하지 못했다.
2. 미션을 진행면서 생기는 모르는 것을 채우는 방식으로는 '질문으로 남겨 놓기'를 선택했다.

아래처럼 스프레트 시트에 모르는 부분을 질문으로 남겨놓고 나중에 시간이 날 때 틈틈히 답장하기로 했다.
velog에 하려고 했는데, '남들이 본다는 부담감 + 완벽주의 성향' 발동으로 시트에 가볍게 적기로 했다.
지금까지는 나쁘지 않는 것 같다. 정리했는데 개념을 또 까먹었을 때, 다시 보기 용으로도 좋은 지는 좀 더 지켜봐야할 것 같다.

🍵 이번주의 생각 1

공원에게 워노원을 신청했다. 코치는 회고를 어떻게 쓰는 지 궁금했기 때문이다.

그리고 DM으로 이런 질문을 받았다. 회고를 작성해봐야겠다고 생각한 이유가 있나요? 회고를 잘 써야겠다는 생각만 했지, 왜 쓰고 싶은 지는 생각해보지 않았다. 막상 질문을 받으니까 이유가 떠오르지 않았다. 나는 왜 회고를 쓰고 싶을까?

곰곰히 생각해보니, 나의 성향과 관련이 있었다.
나는 생각이 많고, 불안과 걱정이 많은 사람이다. 이를 인지한 것은 1, 2년 정도 됐다. 처음에 이 사실을 알고 단점 같아서 부정했지만, 이것은 고칠 수 없는 나의 성향이었다. 없앨 수 없으니 관리해야 했다.

일상에서 불안함을 잠재우는 방법은 여러 가지가 있는데, 매일 아침에는 이불을 개고, 지하철에서는 영어 공부를 하고, 하루 끝에는 일기를 쓰고 있다. 작은 일을 매일 한다는 게 안정감을 주었다.

무의식적으로 우테코를 진행하면서는 회고를 통해 불안함을 죽이려 했던 것 같다.

우테코를 진행하면서 불안함이 왜 생기나면, 미션을 정말 다양한 방법으로 진행할 수 있는데 잘하는 크루 옆에 있으면, 계속 그 크루가 진행한 방법의 장점을 듣게 되면서 그 방법에 넘어가게 되기 때문이다. 그 방법이 좋은 방법이라도 나에게 맞지 않을 수도 있는데 판단력이 흐려진다. 어떠한 기준이 있다면 맞지 않은 방법에는 그럴 수도 있구나~ 하고 넘어 갈 수 있는데 없으니, 시간이 없지만 나도 하고 싶다 와 나는 왜 그 방법을 잘 해내지 못할까? 라는 생각이 반복되며 불안함이 생겨난다.

회고가 있으면 미션을 시작하기 전에, 객관적인 시각에서 해당 미션을 준 의도를 파악하는 시간을 가질 수 있다. 그리고 미션을 진행하면서는 정말 의도된 학습을 하고 있는 지를 회고를 통해 돌아볼 수 있다. 이게 내가 회고를 쓰는 이유이다.

알게 된 점을 정리하면서 나아가고 있다는 느낌을 받는 것도 중요한 이유이다.

+) 앞으로 회고에 적고 싶은 내용은 다음과 같다.

• 이번 미션을 내준 이유는 무엇일까?
• 이번 미션에서 꼭 얻어갈 것은 무엇일까?
• 저번 미션에서 무엇을 배웠을까?
• 아는 것과 모르는 것을 확실히 경계할 수 있나?

🍵 이번주의 생각 2

다른 크루가 이번 미션을 React처럼 짠 것을 보고 놀랐다. 나는 상태를 전역으로 관리하고 있고, 모달 창을 브라우저에 띄워주려면 createElement와 appendChild을 남발해야 됐기 때문이다. React처럼 구현하면 이 두 가지 문제를 해소할 수 있다고 했다. 그 방법을 해낸 크루가 대단해 보였다. 하지만 따라하지는 않았다. 나는 불편함을 100% 느끼고 나중에 React를 할 때 감사함을 200% 느낄 것이기 때문이다. JavaScript로 React를 구현하는 것은 아직 때가 아닌 것 같다. 지금은 UI를 갈아끼우면서 도메인과 관심사 분리를 해보는 것, CSS를 모듈화해보는 것, button, input 같은 작은 단위부터 틀을 만들어서 bottom up 방식으로 구현하는 것에 집중하기로 했다.

뭐든 때가 있겠지..^^ 🥲

나중에 리뷰어 분께서 이런 조언을 주셨다.

특정 프레임워크에서 제공하는 문법, api를 표방하기보다는 우선 알고 있는 범위 내에서 코드를 주욱 작성해보시고 그 코드에서 반복되는 부분을 조금씩 엮어보면 좋을 것 같아요. 그렇게 개선이 된 코드를 한번씩 더 살펴보면서 개선하는 과정을 반복해보시길 바랍니다. 이렇게 권장드리는 이유는, 해결하고자하는 문제가 무엇인지 정확히 모르는 상태로 특정 도구 or 구조를 먼저 도입해버리게 되면, 거기에 갇히게 되어 추가 확장이나 대응이 어려워지기 때문이에요.

☕️ 배운 점

• 서비스를 만들면서 1순위로 챙겨야 하는 마인드는?

  • 서비스는 사용자에게 제공하려고 있는 것이다. 그러니 당연히 동작 가능해야 한다. 객체 지향, 클린 코드 등등으로 난리쳤는데 동작 안하면 소용이 없다.

• 기술적인 부분에 대한 직업을 가진 사람으로서, 사소한 부분도 챙길 줄 알아야 한다.

  • 예를 들면, 도메인에서 던지는 에러를 그대로 보여주는 것이 아니라 사용자에게 좀 더 친화적인 말투로 보여줄 수 있다. 텍스트가 엄청 길어지면 디자인을 조금 바꾸는 걸 생각해볼 수 있다. 꼭 기획/디자이너의 책임만은 아니다.

• 시퀀스 다이어그램을 그려보면서 필요한 게 어떤 게 있는 지 파악하는 것도 방법이다.

  • 프로그래밍 하기 전에 생각하는 시간이 필요한데 시퀀스 다이어그램이 시각적으로 이해하기 좋은 수단 같다.
    나중에 프로젝트를 할 때는 서버까지 그려보면 좋을 것 같다.

• 일정이 밀리면 항상 우선순위는 새로운 미션으로 잡아야 한다.

  • 페어 프로그래밍도 있으니까 일정이 밀려도 페어에게 피해를 주지 말자.

• 그래서 유효성 검사는 어디서 하는 게 좋다고?

  • 도메인? UI? 어디서 하는 게 좋을까? 예들 들어, 금액을 입력 받는 부분에 대한 유효성 검사는 어디서 하는 게 좋을까?
  • UI를 갈아끼우는 걸 생각하면 도메인에서 하는 게 좋다. 그러면 UI를 갈아끼워도 유효성 검증을 도메인 안에서 하기 때문에 바뀐 UI의 입력 로직에 유효성 검증을 추가로 호출할 필요가 없다.
  • 어떤 상황에서든 값이 바뀔 수 있다는 걸 생각하면 도메인에서 하는 게 좋다. 실수로 값이 바뀐다면 그냥 값이 바뀌게 된다. 왜냐하면 입력 때 유효성 검증을 하고 나면 입력 이후에는 검증을 안하기 때문이다. 하지만 도메인에서 하게 되면 저장될 때마다 하니까 이상하게 바뀐 값에 대해서도 하게 된다.
  • 하지만 꼭 도메인에서 하는 게 좋은 건 아니다. 예를 들어, 회원가입할 때 입력을 하면서 유효성 검증을 받을 때도 있다 비밀번호에는 대소문자가 들어가야 합니다 같은 문구이다. 도메인에서 하게 되면 값이 저장된 이후에 하게 된다. 하지만 실시간으로 받고 싶다면 때로는 UI에서 검증을 할 수도 있다.
  • 결국 좋은 건 도메인과 UI 둘다에서 하는 게 아닐까.

🔮 궁금한 점...

• 상태를 전역으로 관리하지 않고 클래스로 관리할 수 있을까?

🎯 다음주 Action Plan 은?

• 나를 포장하려고 하지 말기. (우테코는 나를 인정하고 그냥 자신의 모습대로 살아가도 괜찮다는 걸 실험해볼 수 있는 공간이니까)
• 누군가 물어봤을 때 제대로 설명 못하면 온전히 내 것이 아니다. 👉 설명하다가 막히는 개념 최소 1개는 개념 리스트에 넣고 정리하기.
• 헷갈리는 개념이 있을 때 코치에게 최소 1번 이상 물어봐서 내 생각을 견고히하기.