크게 보면 2가지 기능을 구현했다.
사실 남은 기능은 영상 삭제 기능이였는데, 버그를 발견해서 고치는 데 시간이 오래 걸렸다.
우리가 기획한 코드는
1. 시청 중인 영상 메뉴에서 시청 중인 영상이 비어 있다면 검색 중? 이미지를 띄워준다.
2. 시청 완료 영상 메뉴에서 시청 중인 영상이 비어 있고, 시청 완료 영상도 비어 있으면 검색 중? 이미지를 띄워준다.
3. 시청 완료 영상 메뉴에서 시청 중인 영상이 비어 있지 않고, 시청 완료 영상이 비어 있다면 보는 중? 이미지를 띄워준다.
이렇게 3가지의 경우의 수를 가지고 있었다.
그래서 영상을 이동시킬 때, 메서드 내에서 알아야 하는 것이 이동 후 변경된 count와 현재 어느 위치에서 영상을 이동시켰는지를 알아야 했다.
하지만 잘 생각해보니 영상 이동은 무조건 영상이 1개 이상은 존재하기 때문에 시청 완료 영상 메뉴에서는 검색 중? 이미지를 띄워줄 필요가 없는 것이었다.
결국 기존의 코드를 재사용하지 못한다고 판단했고, 새롭게 만들어주었다.
그 뒤에 영상 삭제 기능을 구현하는데, 영상 삭제에서는 보는 중? 이미지를 띄워주는 경우가 있었기에 다시 기존의 코드를 재사용하는 것이 좋겠다는 생각을 했다.
여기에서 성능 vs 가독성에 대한 고민을 하기 시작했다.
우선 영상 이동 시에는 절대 시청 완료 영상에서는 검색 중? 이미지를 띄워줄 필요가 없기 때문에 성능을 위해서는 검색 중? 이미지를 띄우는 로직을 검사할 필요가 없었다.
하지만 검색 중? 이미지를 띄우는 로직이 들어간 함수를 재사용하게 되면 가독성은 굉장히 좋아지고, 함수의 재사용성도 높다는 것에 대해 토론했다.
우리의 서비스가 크지 않고 리팩토링 2판과 지금까지 리뷰어님들의 피드백을 들었을 때, 살짝 성능이 떨어지더라도 가독성을 챙기는 것이 좋겠다고 판단해 함수를 재사용하기로 했다.
이 과정에서 시간이 많이 소모되었고, cypress를 제외한 나머지 기능을 3시간 정도에 구현한 것 같다.
cypress는 기존에 바꿨던 html을 제대로 반영해주지 않았고, 코드 자체가 잘못 구현된 것이 많아서 통과하기 위해 2시간 정도를 써버렸다.
원래는 cypress로 BDD 주도 개발을 해야하는데 그러지 못한 것이 아쉽고, 이유를 살펴보면 로컬에서 직접 실험해보면서 콘솔로 에러를 보는 것이 더 간편하고 익숙해서인 것 같다.
그래도 BDD 주도 개발을 하는 습관을 들여야 나중에 고생하지 않을 것 같아서 아쉬운 점으로 남아 있다.
2단계 공통 피드백에서 충격적인 것은 동동의 pr이었다.
동동의 pr은 기능을 시각적으로 매우 잘 표현했고, 코드의 구조를 시각화해 정말 열심히 했다는 느낌을 받았다.
저렇게까지는 못하더라도 시각적으로 기능 구현에 관한 것과 코드 구조도정도는 꼭 남겨야겠다고 생각한다.
try...catch문을 사용할 때 finally까지도 생각해보는 것이 좋다는 것과 기본 값을 넣어주는 것에 대한 피드백이 있었는데 finally는 언제 사용하는 것이 좋을지에 대해 공부해봐야 할 것 같다.
기본 값에 대해서는 크루들의 토론의 장이 열렸었다.
기본 값을 넣으면 코드에 인자를 실수로 넣지 않았을 때 오류가 발생하지 않기 때문에 버그를 해결하기 힘들 것 같다.
vs
기본 값을 넣으면 코드에 인자를 실수로 넣지 않았을 때 오류가 발생하지 않도록 하는 것이 목적이다. + 기본 값을 모두 명시하면 처음 코드를 보는 사람이 이정도의 기본 값을 사용하는구나를 파악할 수 있어서 코드를 파악하는 데 유리하다.
결국 결론이 나진 않았지만 코치의 의견은 아래 의견이었다.
괜히 타입 스크립트를 사용하는 것이 아니고, 현업에서는 대부분 모든 파라미터에 기본 값을 넣는다고 한다.
나도 기본 값은 좋다고 생각하지만 위의 의견에도 동의하기 때문에 이 부분에 대해서는 더 고민을 해봐야 할 것 같다.