Facts
- 내가 구현했던 로또 미션에 대한 피드백을 했다.
- 5시간 동안 회원가입과 로그인을 할 때, 실시간으로 input이 유효한 값인지 알려주도록 구현했다.
Feelings & Findings
내가 구현했던 로또 미션에 대한 피드백을 했다.
자신이 구현했던 로또 미션에 대한 피드백을 하는 시간이 있었다. 리뷰어님의 피드백을 모두 반영한 코드라서 많이 잘못된 부분은 없었다. 웹 접근성에 대한 고려가 살짝 부족했고, elements.js파일에 element들을 모아놓은 것과 try-catch를 사용하지 않은 것이 지금과 달랐다.
웹 접근성은 아직도 잘 모르지만 input은 label과 함께 사용하는 것이 좋고, button은 aria-label을 사용하면 웹 접근성에 좋다고 한다. 몸이 불편한 사람들을 위해 꼭 label과 aria-label을 사용하는 것이 좋다.
로또 미션에서는 element.js파일에 모든 요소를 모아놓고 사용하고 있었는데, MVC패턴의 의미가 사라지는 것 같다고 느껴졌다. MVC패턴에서는 View가 존재하고, 이벤트 리스너를 등록하는 것 외에는 모두 View에서 요소가 사용되기 때문이다. 굳이 파일까지 만들어서 모아둬야 하는가에 대한 의문이 생겼다.
MVC패턴에 대해 공부할 때 어떤 분은 View에서 이벤트리스너까지 등록해서 컨트롤러에게 넘겨주는 것을 보기도 했다. 즉, 요소는 모두 View에서 사용하는 것이다. 그때는 이상하다고 생각했었는데 뷰에서 컨트롤러를 살짝 아는 것도 괜찮을 것 같다는 생각도 든다.
이 부분에 대해서는 아직 잘 모르겠어서 내일 루터회관에 가서 크루들과 토론을 해볼 생각이다.
try-catch는 아예 사용해본 적도 없고, 아무도 사용하지 않는줄 알았다. 하지만 그냥 내가 몰라서 사용하지 않았던 것이었다. 최근에 에러 핸들링을 위해 try-catch를 사용하라는 리뷰어님의 피드백을 듣고, 공부를 해보니까 정말 유용하다는 것을 알게 되었다.
export const getInvalidEmailMessage = (email) => {
if (isInvalidEmailFormat(email)) {
return ERROR_MESSAGE.INVALID_EMAIL_FORMAT;
}
return '';
};기존에 사용하던 코드는 위처럼 유효성을 검사해서 오류가 있으면 메시지를 출력하도록 구현했다.
여기에서 오류가 없을 때 return '';를 해서 암묵적으로 ''가 성공했다는 의미를 나타내도록 구현했다. 게다가 이렇게 되니까 함수명을 짓는 것도 매우 힘들었다.
하지만 현재 try-catch를 사용하기 위해 throw new Error를 던져주면서 다음과 같이 변했다.
export const validateEmail = (email) => {
if (isInvalidEmailFormat(email)) {
throw new Error(ERROR_MESSAGE.INVALID_EMAIL_FORMAT);
}
};이렇게 되니까 밖에서 사용할 때, try-catch로 사용할 수 있고, error.message로 받아 사용할 수 있어서 더 명확해지는 것을 느꼈다. 또한, 함수명도 더 명확해졌다고 생각한다.
여기에서 느낀 것은 나에게 익숙한 것만 사용하지 말고 다른 것들도 도전해보는 것이 필요하다고 생각했다. 페어가 새로운 것을 들고 왔을 때 거부하지 말고 사용해보자.
7시간 동안 회원가입과 로그인을 할 때, 실시간으로 input이 유효한 값인지 알려주도록 구현했다.
솔직히 alert만 띄워줘도 사용자는 어떤 부분이 잘못되었는지 알고 수정할 수 있다. 하지만 input에 대한 에러를 실시간으로 알려주게 되면 애초에 잘못 입력하고 내려갈 일이 없으므로 UX적으로 좋다고 판단해서 구현하기로 했다.
처음에는 어렵지 않을 것이라고 생각했지만 중복을 제거하는 것이 정말 어려웠다. 이메일, 이름, 비밀번호, 비밀번호 확인 이렇게 4개일, 이름, 비밀번호, 비밀번호 확인 이렇게 4개가 중복됐다.
하지만 이메일은 중복 확인을 하는 api를 요청해야 해서 살짝 달랐고, 이들을 추상화하기 위해 3~4시간은 쓴 것 같다.
결국 추상화를 해서 httpClient처럼 추상화를 하긴 했지만 완벽하게 마음에 들진 않는다. 그래도 어느 정도 만족하고 있고, 할 수 있는 최선을 다했다고 생각한다. 공통 피드백 때 안좋은 케이스로 나오지 않으면 좋겠다.
3~4시간을 제외한 나머지 시간은 메소드명을 짓는데 사용한 것 같다. 책임과 역할이 정말 애매한 것 같고, 그래서 네이밍이 너무 어렵다. 영어 공부를 더 해야겠다는 생각이 들기도 하지만, 한글로도 생각이 안나는 경우가 대부분이다. 이런 경우에는 여러 책임을 가지고 있을 수도 있다는 피드백을 들었었는데, 그래도 어려운 경우가 많다...
그래도 우리는 굉장히 만족했고, 발견된 버그는 모두 처리했다. 그냥 무시하고 넘어갈 수도 있었지만 제대로 해보자는 마음에 모든 버그를 찾아냈다. 하지만 keyup을 할 때마다 이벤트가 발생하기 때문에 너무 무거울 것 같다고 생각해서 내일은 디바운스를 걸어보려고 한다. 0.1초정도로...
Plans
- 지하철 노선도 1단계에서 남은 2가지 기능 구현하기
- 지하철 노선도 2단계 시작하기 -> 금요일까지 끝내기 목표!
- 우테코가서 열심히 공부하기
