[지하철 노선도 미션] 신세희 미션 제출합니다.

[shinsehantan]

[지하철 노선도 미션] 신세희 미션 제출합니다.

아쉬운 점
1.
2차 미션을 거치며 초기에 모델을 잘 설계하는 것이 가장 중요하다고 판단했지만, 3차 미션때에도 모델 설계 부분이 미흡하였고 그것이 여러가지 문제를 야기하였습니다.

제 프로젝트에서는 사용자단에서 이벤트가 발생하면 로컬 스토리지에 그것을 반영하여 저장하고, 사용자단에서 다시 로컬스토리지에서 변경된 데이터를 가져와서 사용하였는데

사용자단에서 이벤트가 생기면 모델을 변화시키고, 모델의 상태가 업데이트 되면 자동으로 사용자단에 변화된 내용이 렌더링되는 로직이 더욱 이상적이었을 것이라는 생각이 듭니다.

또, 이러한 구조때문에 로컬 스토리지에서 항상 데이터를 받아와야 했는데, 동시에 전역 객체를 쓰지 않기 위해서 각 함수 내에서 계속 객체를 정의하여 사용해야했습니다.
이 방법은 전역객체를 사용하지 않기 위한 미봉책에 불과하였고, 매 함수마다 로컬스토리지를 참조하는 것은 효율성 면에서도 크게 떨어지는 부분이라 아쉬움이 남습니다.

이번 프로젝트에서는 비슷한 변수명, 함수명이 반복적으로 사용될 경우가 많았는데 제 디렉토리 구조에서는 특히 예외 상황 검증을 역, 노선, 구간 별로 나누지 않고 1개의 통합된 validation파일로 사용했기 때문에 이해가 더 쉽지 않았던 것 같습니다.
모듈화를 조금 더 직관적으로 했다면 변수명이 애매하더라도 구조 내에서 문맥상으로 이해가 더 잘 되었을텐데 이 부분에 시간을 더 투자하지 못해 아쉼습니다.

예외상황을 어디까지 체크해야하는지 판단하는 것이 어려웠습니다. 명확하게 에러가 날 수 있는 상황은 체크하였으나,
사용자단에서는 에러가 생길 상황은 아니지만 논리적으로 혼란을 줄 수 있는 상황들도 체크해야 하는지 고민하다가 실제 유저가 있는 어플리케이션이라고 가정하고, 에러뿐만 아니라 혼란을 야기할 수 있는 부분까지 추가적으로 체크하였습니다.

디렉토리 구조를 크게 보면 components에 역 관리 페이지, 노선 관리 페이지, 구간 관리 페이지, 노선 출력 페이지가 있고
managers에서 역 관리 핸들러 페이지, 노선 관리 핸들러 페이지, 구간 관리 핸들러 페이지, 노선 출력 핸들 페이지가 있는데
후반부에 코드를 전체적으로 검토하면서 계속 components - managers 사이를 반복해서 이동하다보니 지금의 구조보다는
역 관리 페이지 - 역 관리 핸들러 페이지 - 역 관리 검증 페이지’ 처럼 페이지의 성격에 따라 구조화를 하는 것이 더욱 좋지 않았을까 하는 생각이 듭니다.

dataset을 어떤 상황에 사용해야하는지 파악이 덜 되어 이번 프로젝트에 적용하지 못한 점이 아쉽습니다.

느낀점

저는 여태까지 map과 forEach를 사용할 때, 그 명확한 차이를 구분하며 쓸 생각을 하지 못하고 혼용하며 사용하고 있었습니다. 그러다 크리티컬한 에러가 생겼고, 도큐먼트를 읽으며 다시 학습하여 return값이 있는 경우에는 map을, 그렇지 않은 상황에는 forEach를 사용해야 한다는 사실을 알게되었습니다. 앞으로도 애매하게 아는 메소드는 항상 도큐먼트로 명확하게 개념을 익힌 뒤 사용해야겠다는 생각이 들었습니다.

1차, 2차, 3차 미션을 진행하며 가장 큰 도움이 된 것은 다른 참가자들의 코드였습니다.
다른 참가자들의 코드를 보며 크게는 구조, 로직, 모델부터 작게는 폴더명, 변수명, 리드미 작성법까지 제가 부족했던 부분을 체크하고, 고민했던 부분을 해결할 수 있는 아이디어도 얻으면서 짧은 시간 내에 많이 성장하게 된 것 같습니다. 또 우아한테크코스 프리코스 과정을 통해 처음으로 기한이 있는 프로젝트를 경험해보았는데, 주어진 시간 내에 조건에 맞추어 가장 효율적인 결과물을 만들어내는 과정에서 정말 많이 성장할 수 있었습니다.