2단계 회고

1단계 회고의 회고

우아한 테크 코스에서는 회고의 회고를 하는 시간을 가지는 데 이 과정에서 다음 미션 페어 프로그래밍 에서는 어떤 식으로 진행할 것인지 이야기 한 것이 있어서 적어 두고 가려고 한다.

우리 시간 좀 가지자

예전 미션 페어와 함께 이번 미션과 저번 미션 두 가지의 진행방식을 비교하게 되면서, 스스로 느꼈던 것인데 나는 너무 급하게 미션을 진행하지 않았나였다.

현재까지 페어와 함께 미션을 진행한 것이 3번째인데, 앞의 두번의 경우 어떻게 진행 할 것인지 서로 문제를 어떻게 이해 하였는지 충분한 이야기 없이 기능 구현 부터 들어갔다. 그러다 보니 때로는 문제를 제대로 이해 하지 못해서 문제 좀 이해하고 가자 라는 시간을 따로 가지고도 하였다.

그런데도 그때에는 딱히 문제점을 느끼지 못하고 진행하였다!😱
아마 기능 자체가 많지 않아서 그랬을 거라 짐작하는데, 이번 미션을 진행하고 보니 단점이 뚜렷히 보였다.

우선 기능 구현하는데 집중하다 보니 빨리 끝낼 수 있다는 장점은 있었지만 리팩토링 과정에서 시간이 더 오래 소모되었다. 그리고 기능만 구현 해 놓게 되면 다음 단계에 혼자서 구조를 변환 시킬 때에는 쉬울 수 있지만 나의 경우에는 맞지 않았다.
기존의 코드를 활용해서 구조를 다시 만들어야 돼! 라는 생각에 박혀버려 2단계를 마무리할 때 쯤이면 복잡한 코드가 하나 완성되어 있다.

그런데 이번 미션에서는 페어분의 제안으로 문제에 들어가기에 앞서 문제를 이해하고 가는 시간을 가졌는데 이것이 꽤나 도움이 됐다. 저번 미션들에서도 미션을 안 읽고 들어가거나 한 것은 아니였지만, 이번 미션 때에 페어분들을 만나기 직전에 읽는 것이라 내가 이해한 것을 설명해야 하지 않을까? 라는 지레짐작으로 어떻게 설명하지? 라는 것을 생각하고 읽게 되어서 문제의 이해도가 다른 미션들 보다는 높은 상태에서 시작할 수 있었다.

그리고 이러한 경험을 저번 페어분께도 말하니, 어느 정도 공감을 하였다.
그래서 다음 미션때에는 (현재 시점에서는 당장 내일이지만!) 페어 분과 이번 미션의 요구사항들을 어떻게 이해했는지 이번 미션에서 하고 싶은 것 등을 서로 이야기를 해보고 들어가는 시간을 만들어 보고 싶다.

아직 시도해본적이 없어서 장단점을 잘 모르겠지만 성공적으로 시도해 본다면 블로그에 적을 예정이다.

피드백 내용들

내가 받은 피드백과 추후에 다른 사람들이 받은 피드백 들 중 기록하고 싶은 것들을 추가할 예정이다

구조도를 그려보자

민망하지만, 우테코를 진행하면서 이번 미션에서 구조도를 처음 그려보았다! 예전에 전공시간에 그려본 기억이 날듯 말듯 뇌속 어딘가에 박혀있는데 사실 거의 그릴지 모른다고 보면 된다 그래서 더 안 그린 것도 있는데, 이번에 리뷰어 님께서 폴더 스트럭쳐와 SoC 두가지로 구조도를 그려보라고 제안을 하셨다.

폴더 스트럭쳐까지는 어느정도 알고있었지만
SoC는 정말 처음 들어보았기에 열심히 구글링을 해보니 👩🏻‍💻
Seperation of Concerns 라는 관심사 분리 라는 것의 약자였다. 시간이 촉박하기도 하여 뜻을 열심히 이해해본다음에 빠르게 그려서 내긴 냈는데 맞게 한 건지는 모르겠다.😢

구조도를 그리면서 리뷰어님께서 왜 구조도를 그려 보라고 하였는지 알 수 있었다. 코드를 짜면서 얽혀있던 구조들을 구조도를 그리면서 명쾌하게 정리할 수 있었다. (아직 경험하지는 않았지만 구조도를 보면 리팩토링도 쉬워질 것 같은 느낌적인 느낌?🤔)
이번에 필요성을 느꼈으니 다음 미션때부터는 구조도를 그리는 것을 꼭 잊지 말아야겠다

사용자의 편의성을 챙기자

요구사항에는 searchModal을 닫는 것은 dimmer라는 외부 창을 클릭한다는 것 만이 있어서 그렇게만 구현을 진행하였는데
거의 당연하게도 유저에게는 매우 불친절한 ui였다.
그냥 개발한 사람만이 어떻게 작동하는지 알 수 있는..

이번에도 그 부분을 언급해주셨는데,
시간 부족하니깐 그냥 기능 요구사항만 빨리 구현해서 내야지 라는 생각으로 이번 미션도 제출하게 됐는데, 다른 크루원들 중 몇분은 구현하시는 분들은 구현 하는 것을 보고 반성하게 된다.
누군가 사용할 서비스를 개발하기 위해서 개발 공부를 한다는 점에서 항상 염두에 두어야 하는 것인데 말이다.

alert 창의 경우에도
이전 미션에서는 사용자에게 알림을 줄 때에 alert창을 띄워주고 끝냈었는데 이제는 그렇게 하면 안된다는 것을 알았으니, 이제는 하지 말아야한다. 잊지말자! 🙅🏻‍♀️

빠질 수 없지 네이밍

네이밍 관련 피드백은 이번에도 받을 수 있었다.
네이밍은 항상 어려운게 코드는 영어로 짜야 하다보니, 내가 지금 담고 싶은 이 코드의 내용을 적절하게 담을 수 있는 영단어들도 알고 있어야한다.

추가로 컴퓨터 전공 관련 용어들도 뜻을 파악하고 있어야 다른 사람들이 봤을 때 해당 코드가 어떤 일을 하고 있는지 이해하기 쉬운 네이밍을 할 수 있다.

탑다운 바텀 업

리뷰어 분께서 2단계 마지막 피드백으로 탑 다운과 바텀업의 방식을 번갈아 가면서 진행해보라는 말을 해주셨다. 실제 코드를 작성하는 것을 바텀 업, 설계하는 것을 탑 다운이이다.

사실 지금까지 미션을 진행할때에는 시간이 없어!!! 라는 생각에 기능 구현에 집중을 하여 코드를 짜게 되었는데 아무래도 점점 갈 수록 구조가 엉성해지는 것이 보여지는 것 같다.

앞으로 미션을 진행할때에는, 문제에 맞게 설계도를 러프하게 그리고 코드를 작성하고 다시 설계도를 그리는 방식으로 진행해야겠다.