코드스쿼드 FE 4주차 회고(+ 프로젝트 설계)

이번주는 페어프로그래밍으로 사각형을 화면에 랜덤 배치하고 DOM을 직접 탐색하는 프로그램을 구현하였다. 페어로 하는것 자체가 체력 소모가 컸지만 의사소통하는 과정이 즐거웠다.

전반적으로 앞단위의 작은 부분부터 뒤에까지 순차적으로 진행하는데 설계-구현을 반복하였다. 설계에 얘기를 더 해봐야한다면 navigator, driver역할을 중단하고 설계에 대하여 어떤것이 나을지 토론하였다. 한 사람이 생각한 설계가 채택되면 그 이후에 설계에도 그 설계와 가장 흐름이 자연스러운것이 채택되었다. 하지만 그 과정에서 폐기하더라도 서로 다양한 아이디어를 냈다. 이러한 과정에서 다른 설계대로 했으면 더 좋았을것이라는 생각이 들었지만 마감기한이 있기 때문에 기존 설계와 흐름이 맞는것을 채택하였다.

하지만 폐기된 설계들을 생각하면서 다음과 같은 궁금증이 생겨서 PR에 남겼다.

설계, 구현을 반복하면서 더 나은 설계가 떠올랐는데 그 설계로 하면 기존 구현을 다 수정해야해서 기존 로직과 가장 잘 맞는 로직을 선택하였다. 현업에서도 마감기한에 맞는 설계대로 진행할 수 밖에 없는것인지 궁금합니다.

namse 리뷰어님의 답변은 다음과 같았다.

더 나은 설계로 했을 때, 우리가 얻을 수 있는게 무엇이고, 잃을 것은 무엇입니까?
그것은 마감기한을 변경하는 것보다 값어치가 있습니까?
변경하지 않고서는 큰 문제가 생길 수 있습니까? 당장 생깁니까, 아니면 우리가 다음에 변경할 수 있는 여유가 생깁니까?

현업이라고 하여서 엄청나게 특이한 결론이 있는것도 어떠한 기준으로 정한다는것을 알 수 있었다. 프로젝트 담당자분이나 개발자분의 생각에 따라 결론이 달라질 수 있는것이다.

그렇다면 질문보다 나의 기준을 설정하는게 나았을것이다.

절대 좌표 대로 하지않고 css요소로 position이 absolute인 부모와 자식의 성질을 이용하였으면 코드도 더 깔끔해지졌을것이다. 하지만 이미 절대 좌표로 논리를 짰기 때문에 전체적인 코드 수정이 있어서 시간을 더 소모할 것이다. 그리고 페어로 진행하기때문에 체력소모가 더 커서 마감기한을 놓칠 수 있다. 마감기한을 변경하는것보다 그대로 진행하면서 페어와 의사소통하면서 다양한 생각을 공유하는것이 값지다고 생각한다.
당장 변경하지 않고서는 구현에 큰 문제가 생기지 않고 프로젝트 규모가 크지 않아서 이후에 변경할 여유는 있을것이라고 판단한다.

페어를 하면서도 사람의 성향이 드러나는것 같다. 어느 쪽의 주장이 더 효율적이거나 보기 좋은 코드인지 명확하게 들어나지 않는이상 어느 쪽으로 선택하게 된다. 여기서 자신의 주장을 지속적으로 하는 편이나 큰 문제가 없는 경우 수용하는 쪽이 있을 수 있다. 자신만의 주장도 하되 크게 문제 될것이 없다면 수용하는 쪽이었는데 그것이 빈번해지고 특정 상황에서 주장이 충분히 고려되지 못한다는 생각이 들었다. 그래서 잠시 이에 대하여 얘기하는 시간을 가지고 다음을 진행하였다.

만약 주장을 더 강하게 하는 편이었더라면 상대편의 주장을 최대한 끝까지 듣고 driver일때에는 상대편의 주장에 따르도록 하여야겠다.

실시간으로 빠르게 자신의 생각을 정리하고 내뱉는게 상대적으로 빠른편이 아니었다. 마스터즈 하면서 짠 코드를 설명하거나 공부한 내용을 설명할때에 이러한 점이 더 길러졌다고 생각하였는데 속도를 늘려야겠다. 알고리즘 문제를 풀고 스스로 한번 설명해보는것도 좋은 방법일것이다.

페어와 설계한것들을 피그마로 정리해보았다.