Today I Learned
-
두 가지의 서로 다른 영역이 충돌해 만들어내는 문제 해결하기 (navigate, react-modal)Today I Learned 2022. 12. 4. 23:58
오늘은 대부분의 작업을 예외적인 상황을 처리하거나 자잘한 오류들을 추적해 해결하는 위주로 진행했다. 기억에 남는 작업 중 하나로 사용자에게 특정 동작을 수행했음을 시각적으로 확인시켜주기 위한 Modal 출력이 의도와 다르게 작동하던 문제를 해결했던 것이 있었다. '게시글 작성하기' 기능에는 작성 페이지에서 게시글 작성을 마치고 게시글 목록 페이지로 이동했을 때 '게시글 작성이 완료되었습니다.' Modal을 출력해주는 동작이 있다. React-Modal 라이브러리를 이용해 구현한 Modal은 각 Modal 별로 별도의 컴포넌트로 정의되어 있으며, 각 페이지에서 useState로 Modal의 출력 상태를 관리하도록 구현한 상태이다. 게시글 작성 완료 Modal은 게시글 목록 페이지에서 출력되어야 하기 때문에..
-
간단한 알림 기능 구현하기Today I Learned 2022. 12. 4. 00:00
현재 앱에서는 사용자가 운동에 참가를 신청하거나, 작성자가 사용자의 운동 참가 신청을 수락하는 등의 행동을 했을 때, 각 사용자가 그런 동작이 일어난 사실을 알기 위해서는 게시글을 직접 찾아가 확인해야 한다. 지금까지 구현된 수준의 기능에서 어떻게 하면 사용자의 사용 편의성을 늘려줄 수 있을까 고민한 끝에 '알림' 기능을 추가해보기로 결정했다. 현재 앱에서 발생하는 가장 주요한 이벤트인 '운동 참가 신청'과 '신청 수락'을 타겟으로 잡아 다음의 기능을 구현했다. 운동 참가 희망자가 운동 모집 게시글에 참가를 신청했을 때, 게시글 작성자에게 '특정 사용자가 참가를 신청했다는' 알림이 전달된다. 운동 모집 게시글 작성자가 특정 사용자의 참가 신청을 수락했을 때, 해당 사용자에게 '작성자가 참가 신청을 수락했..
-
책임감Today I Learned 2022. 12. 2. 20:56
프로젝트를 하면서 크게 느끼고 있는 점을 조금 다르게 이야기를 해 볼까 한다. 나에게 책임감이란 얼마나 되는 무게였을까. (6 +) 23주 동안 끊임없는 마감과의 싸움을 해 왔다. 매 주마다 강의 노트, 개념 노트 정리와의 싸움을 했고, 코딩 도장, 강의 반복 과제, 퀘스트 과제와의 싸움을 했다. 세 번의 레벨 테스트 중 한 번은 마감과의 싸움에서 이기지 못했고, 두 번은 이겨내기는 했지만, 깔끔하게 마감을 지켜냈다는 생각은 들지 않았다. 지금은 눈 앞에 포트폴리오 과제 마감이라는 거대한 존재가 있다. 지금 내게서 볼 수 있는 모습은 아직까지는 과정을 놓고 볼 때 지금까지 내가 살아왔던 길에서 보여줬던 모습들보다 크게 나아졌거나 달라졌다고 말하기는 어려운 것 같다. 다만 한 가지 차이는 확실하게 말할 수..
-
사용성을 고려해 기능을 수정하다Today I Learned 2022. 12. 1. 23:58
조금씩 커져가기 시작했던 고민을 아샬님께서 짚어주셨다. 최소한의 기능을 가진 상태의 앱부터 다시 만들기 시작했었을 때, '참가 상태'를 가장 빠르게 나타내기 위해 게시글 목록에서 바로 참가신청을 할 수 있도록 기능을 구현했었다. 그때는 기능이 정말 최소한이었기 때문에 게시글 상세 내용조차도 볼 수 없었고, 신청을 할 수 있는 방법은 게시글 목록을 조회하면서 하는 것뿐이었다. 꼭 그런 이유 외에도 '내가 하고 싶은 운동에 바로바로 신청할 수 있다'는 점이 개인적으로 나쁘지 않게 여겨졌다. 그래서 기능이 조금씩 추가되고 복잡해지는 중에도 기능 자체는 유지한 채로 가져왔다. 작업이 진행되어 가면서 신청 기능을 게시글 상세 내용 조회 화면에서도 할 수 있게 되고, 게시글 상세 내용 조회에서는 게임의 참가자 목록..
-
우리 가게 다시 영업합니다Today I Learned 2022. 11. 30. 21:57
다행스럽게도 오늘 오후에 리팩터링이 일차적으로는 끝나 가게 문을 다시 열 수는 있게 되었다. 언제 다시 닫게 될지는 모르지만 가게를 열 수 있다는 것에 감사하면서 열심히 장사하도록 하자. 남아있던 리팩터링 작업 중 꽤나 신경써야 했던 부분 중의 하나는 예외처리 방식을 바꾸는 것이었다. 사용자가 게임에 참가를 신청하는 동작을 받는 Application Layer의 JoinGameService가 RegisterToGameService였던 시절의 예외처리 방식은 다음과 같이 하나의 예외에 메세지를 다르게 해서 예외를 발생시키는 식이었다. // services/RegisterToGameService.java Game game = gameRepository.findById(gameId) .orElseThrow((..
-
우리 가게 영업 안합니다Today I Learned 2022. 11. 29. 23:26
백엔드 애플리케이션의 거의 전체를 리팩터링하고 있다. 처음에는 아샬님께서 리팩터링해주신 부분 위주로 수정하고 작업을 진행하면서 다른 부분들도 하나씩 수정해나가는 것이 목표였지만, 테스트를 작동시키기 위해서는 수정된 부분이 사용되고 있는 다른 Service 로직들도 수정해줘야 했다. 문제는 그 Service 로직들에는 여전히 모든 작업이 몰려 있었기 때문에 그 부분들의 인터페이스만 맞춰준다고 해결될 문제들이 아니었다. 결국 오늘 하루는 깔끔하게 리팩터링에만 투자하기로 했다. 아직 모든 리팩터링 과정이 끝나지 않았다. 일부 Controller 테스트, Exception Hander 리팩터링, 예외 메세지를 프론트엔드에서 받아서 처리하는 방식을 마저 손봐야 한다. 일단 지금까지 리팩터링한 것들 중 인상 깊었던..
-
잘못된 부분들 하나씩 추적하기Today I Learned 2022. 11. 28. 23:57
아샬님으로부터 프로젝트에 존재하는 소스코드 중 게임에 참가를 신청하는 소스코드의 많은 부분을 리뷰받았다. 디스코드에 올려주신 리뷰와 Pull Request로 보내주신 리뷰를 하나씩 추적하면서 고쳐야 할 점들을 정리했다. 에러 메시지를 이용해 어떤 처리를 하지 않는다. // Anti-pattern @ExceptionHandler(RegisterGameFailed.class) @ResponseStatus(HttpStatus.BAD_REQUEST) public RegisterGameFailedErrorDto registerGameFailed(RegisterGameFailed exception) { Integer errorCode = setCodeFromMessage(exception.getMessage());..
-
자리가 없는데 신청이 되면 안 되지Today I Learned 2022. 11. 27. 23:59
오늘 진행했던 작업 중의 하나는 기존의 신청 기능에 디테일을 더하기 위한 작업이었다. 특정 게시물을 조회할 때 이런 상황이 있을 수 있다. 작성자가 글을 작성하면서 설정한 모집 인원이 5명이고, 4명이 참가자로 들어간 상태에서 어떤 사용자가 게시글의 상세 내용을 확인한다. 사용자의 화면에는 잔여석이 1석 남았기 때문에, 신청하기 버튼이 화면에 나타난다. 사용자는 신청하기 버튼을 누른다. 그러나 사용자가 신청하기 버튼을 누르려는 사이에 작성자가 다른 신청자의 신청을 수락해 참가 상태로 전환한다. 이제는 잔여석이 없는 상황이기 때문에, 사용자가 신청하기 버튼을 누를 수는 있겠지만 눌러도 신청이 생성되지 않아야 한다. (사실 신청과 참가는 다르기 때문에 신청이 생성되어도 오류가 발생하는 것은 아니지만, 정원이..