오늘은 기업협업을 프로젝트 발표가 있는 날이었습니다.
개인적으로 프로젝트 발표인 만큼 로직이나 아키텍쳐 등과 같은 발표를 할까 했지만, 발표에 그런 내용을 넣는 것은 큰 의미가 없다는 생각이 들어 시각자료만 만들어두었습니다.
또한 네이버 사다리가 저는 발표가 아닌 Refactoring과 시연 준비를 담당하도록 지시했기에 열심히 발표 아이디어를 제공하고, 시연 전까지 부족했던 부분을 채워넣는 역할을 했습니다.
네이버 갓다리..
열심히 만들었던 Architecture 시각화 자료 => ReadMe에 넣을 예정이다.
아무튼 이런저런 일이 있었는데, 오늘은 Fix를 하는 일이 대부분이었기 때문에 로직을 다루는 일이 주류였습니다.
열심히 PR을 올리며 수정했었네요.
역시 되돌아봐도 참 고생 많았던 것 같습니다.
로직을 fix해야 하는 상황들이 많았다는 것은 아무래도 TDD 방식의 개발이 아니어서인가? 하는 생각이 들었습니다.
어떤 문제가 야기될 수 있는지 인지할 수 없는 개발이라고 생각되네요.
당장 View에 보여질 기능들을 빠르게 구현하다보니 놓친 부분이 많기도 한 것 같습니다.
Refactoring 사항을 좀 체크하며 fix를 진행했는데,
Repository에서 데이터를 처리하는 함수들 중에는 중복이 많기도 하고, 또 hooks 내부에서 좀 더 잘 처리하면 될 것 같은 것들도 있었던 것 같습니다.
그리고 무엇보다도 있어서는 안될 일 중 하나인, View에 Data가 잘못 표시되는 상황이 오늘 많았습니다.
그래서 내일은 Jest를 이용한 test file을 좀 추가해볼 생각입니다.
2번의 생각이 왜 들었는지, 오늘 fix된 사항들을 보며 다시 생각해보고자 합니다.
위 리스트를 각 항목에 맞게 재배치하면,
로 분류할 수 있습니다.
이 중 FIX에 해당하는 사항들은 실제 시연 전 UI Test
단계에서 나온 소중한 녀석들인데, 사실 조금 더 신경썼다면 나올 필요 없었던 친구들이기도 합니다.
로직을 짤 때, 단순히 구현에 초점을 맞추기보다는 조금 더 고민하는 시간이 필요하지는 않을까 생각이 들었습니다.
또는 충분한 테스트를 활용한 개발 조건이라면 이런식으로 배포 전에 빨리 알아낼 수 있다는 점이 정말 매력적일 수 밖에 없지 않을까? 하는 생각이 들기도 했습니다.
중구난방식 서술인데, 오늘은 요약이 좀 가능한 것 같습니다.
역할분담은 역시 네이버 사다리다.
View에 기능이 빨리 구현되는 것만이 때로는 정도가 아닐 수 있다.
Fix에 해당하는 사항들을 돌아보고, 다음 로직은 신중히 작성하자.
UI test도 test다. 툴을 알아보고 나중에 사용해보자!
이상입니다. 읽어주셔서 감사합니다.