오늘은 5주차 스프린트 회의가 이루어졌다. 스프린트 회의를 진행하고 나서 노아님이 이야기하신 피드백을 떠올려보자. 우선 노아님이 가장 강조하신것은 작업을 진행하면서 작업 내용이나 배운점 느낀점들을 구체적으로 기록을 해야한다는 것이였다. 그런데 나의 문서에는 과정은 전혀 없고 결과에 대한 기록만 있고 구체적인 내용을 기록한게 없었다. 구체적인 작업 내용을 작업하면서 기록하지 않으면 나중에 필요할때 생각이 나지 않을 수 있기 때문에 힘들더라도 작업하면서 기록하는게 가장 좋다고 말씀해주셨다. 대표적인 예로 내가 구현한 채팅기능도 3일정도 공부하면서 구현을 했었는데 어떻게 구현했는지 어떤 내용들을 배웠었는지 구체적으로 기록을 남긴게 없었다. 이전에 채팅 기능 구현할때 TIL에 기록을 했었다고 생각했었는데 다시 ..
오늘은 경기 일정 페이지를 만들 때 해당 경기의 경기 시간을 보여줘야 하는데 api를 요청해서 받아오는 경기 시간이 영국 시간 기준(UTC)이라 한국 시간으로 계산(+9 시간)을 해줘야 하는 작업이 필요했다. 우선 받아오는 경기 시간의 데이터는 아래와 같다. 이 중 연도는 필요 없고 월, 일만 필요했기 때문에 substring으로 문자열을 잘라 14:00의 시간만 가져와서 시차 계산을 해주는 함수를 만들어서 화면에 보여주도록 했다. 시차 계산하는 함수는 UTC기준으로 가져오는 시간에 +9를 해주는데 24가 넘어가면 00:00부터 계산하는 로직을 작성했다. 위 사진과 같이 원하는 모양으로 만들고 11:00분이 잘 나오는지 테스트를 돌려보는데... 테스트가 통과가 되지 않는 문제가 있었다. 분명 화면에는 1..
이번 주 월요일부터 사용자 스토리, 인수 테스트 재작성, 구조 재 설계로 인한 리팩터링 등등 다른 부가적인 작업들을 하느라 작업 진도를 전혀 못 나가고 있었다. 오늘 오후에 최종적으로 category가 하던 역할을 board가 하도록 위임해주는 작업을 마침으로써 다음 기능을 구현할 수 있게 되었다. 오늘 구현하려 했던 기능은 리그의 경기 일정을 확인하는 것이었다. 리그의 경기 일정은 rapid api를 사용해서 원하는 리그의 경기 일정을 모두 받아올 수 있다는 것을 이전에 확인했었다. RapidApi 사용법 : https://seungjjun.tistory.com/166 근데 param에 입력해준 시즌의 1년 동안 모든 리그의 일정을 받아와서 이미 경기가 끝나서 불필요한 경기 일정도 가져오는 문제가 있었..
어제 협력에 필요한 객체의 종류와 책임, 메시지를 정리했고 오늘은 설계한 것을 바탕으로 어떻게 리팩터링 할지 고민하는데 시간을 많이 사용했다. 우선 카테고리와 게시판 객체 사이의 관계가 애매했었는데 그 이유가 게시판의 이름이 카테고리 이름이랑 동일한 역할을 한다고 생각을 했다. 왜냐하면 카테고리는 어차피 축구라는 카테고리 안에 여러 개의 게시판이 존재할 것이기 때문에 카테고리 객체가 필요한가에 대한 생각을 하게 되었다. 그래서 동료들에게 카테고리와 게시판에 대한 관계(카테고리 안에 여러 개의 게시판, 게시판 안에 여러개의 게시물)를 설명하니 카테고리가 굳이 필요 없을 것 같다는 이야기를 해줬다. 그래서 기존에 카테고리가 하던 역할(카테고리에 맞는 게시글들을 프론트 엔드로 넘겨주는 것)을 게시판이 하도록 ..
어제 했던 협력 설계의 잘못된 부분을 감사하게도 아샬님께서 짚어주셨다. 어제 했던 협력 설계 인데 아샬님께서는 사용자에서 뭔가가 시작되었다는 건 의인화가 충분히 이뤄지지 않았다는 신호라고 말해주셨다. 사실 어제 혼자 설계하면서도 "게시물을 작성하라"메시지를 사용자부터 시작하면 게시물뿐만 아니라 다른 모든 것들도 다 사용자부터 시작하게 될 것 같은 느낌이 들어서 이게 맞나? 라는 생각이 들어 이상함을 느꼈었다. 아샬님께서 일반적인 게시판 서비스는 게시판이 “게시물을 작성해라”를 메시지를 받는다는 말을 해주셨다. 기존에 설계한 객체에서 게시판 객체가 존재하지 않았었는데 게시판 객체를 만들어서 객사오를 참조해 새롭게 처음부터 설계해봤다. 우선 게시판을 구성하는 요소들에 대해서 고민하는 것이 좋다고 책에 나와있..
오늘은 이전에 설계했던 객체가 잘못되었다는 것을 인지하고 객체지향의 사실과 오해를 참고해서 객체를 재설계해봤다. 객사오에서는 객체지향 설계의 첫 번째 목표를 훌륭한 객체를 설계하는 것이 아니라 훌륭한 협력을 설계하는 것이라고 강조하고 있었다. 협력을 설계한다는 것은 객체가 메시지를 선택하는 것이 아닌 메시지가 객체를 선택해야 한다는 것을 의미하기 때문에 메시지를 먼저 선택 후 메시지를 수신하기에 적절한 객체를 선택해야 한다고 한다. 솔직히 글만 봐서는 잘 와닿지 않았었다. 그래서 직접 내 프로젝트에 적용해봤다. 현재 게시판에서 설계하려는 협력은 게시글을 작성하는 것인데 메시지로 작성한다면 "게시글을 작성하라"이다. 객사오에서 나오는 방법처럼 화살표를 이용해서 설계해봤다. "게시글을 작성하라" 메시지 위에..