개발일지

이번주 초까지 급하게 끝내야 하는 일정이 있어서 코드리뷰를 못하다가, 약간 시간이 생긴 오늘 코드리뷰를 했다. 평소에도 궁금한건 물어보면서 진행했지만, 오늘 리뷰하면서 전체적으로 우리 앱의 아키텍처에 대해서도 다시 설명을 해주셨다. 마침 오늘 아침에 서버 연동 부분을 보면서 어떤 레이어 구조로 나눠져 있는지, 각각 어떤 역할을 하는지 다시 살펴보았고, 계속 업무를 하면서 처음보다는 이해가 된 부분도 있고 궁금해진 점도 있어서, 2시간 가까이 얘기하면서 많은 부분이 정리되었다. 최근에 가장 큰 고민은 비즈니스 로직을 어디에 구현해야하는지, 였다. 우리 패키지 구조에서 이미 ui와 feature는 구분을 하고 있고, 위젯을 만들면서도 계속 위젯에는 로직이 들어가지 않게 분리하려고 했다. ui와 비즈니스 로..

처음 업무를 받은 날, 재택을 하다보니 여러가지 궁금한 점이 많았다. 슬렉으로 계속 질문하면서 업무를 했지만, 아직 업무 코드 파악이 덜 된 부분도 많았고 플러터는 처음 하다보니 어떤 방식으로 업무를 해야하는지도 아직 감이 오지 않았다. 우선 비교적 간단한 페이지 UI를 작업하기로 했는데, 위젯(컴포넌트)만 하더라도 새로 만드는게 좋은지, 기존에 만들어진 위젯을 사용하는게 좋은지 판단이 잘 되지 않았다. 출근해서 업무를 하면서 사수와 이런 고민들을 같이 얘기하면서 알고보니 컴포넌트화 되있는 위젯 버튼이 있는 경우도 있었고, 기존에 만들어져있는 컴포넌트에서 required parameter 하나를 그냥 empty string을 넣고 사용하는게 낫겠다고 판단이 되는 경우도 있었다. 또, 기존 컴포넌트를 사용..

지난 주부터 듣던 Flutter 기초 강의를 모두 들었다. 후반에 미세먼지 앱을 만드는 부분이 있었는데 모델링 부분에서 '이렇게 해도 되나?'라는 고민이 많았고, 이전 강의들보다 다루는 데이터도 많고 리팩토링도 계속 하다보니 조금 헷갈리는 부분이 많았다. 특히 상태관리를 StatelessWidget과 StatefulWidget만 사용하다보니 데이터를 전달하고 관리하는게 중요했다. 강의를 다 듣고 나서, 우리 앱에서도 사용하고 있는 상태관리 패키지인 riverpod을 공부하기 시작했는데 정리하면서 생각해보니, 왜 상태관리 패키지를 사용하는지 알 것 같다. 상태관리 패키지를 사용하면 훨씬 더 편하게 데이터들을 관리할 수 있고, 각 위젯에서 필요한 데이터들을 쉽게 접근하고 watch할 수 있을 것 같다. 그리..

이번달은 일단 생각이 많았던 것 같다. 회사와, 업무와, 좋은 코드에 대한 고민이 많았다. 아마 이직을 하게 될 것 같고, 8월에는 새로운 곳에서 시작하게 될 것 같다. 디자인패턴 : 헤드퍼스트 디자인 디자인 패턴을 읽고 있다. 전략패턴을 일부 업무에 적용해봤는데, 팀 맴버 중에 타입별로 해당하는 구현체를 컨트롤러에서 그냥 바로 주입해주는게 낫지 않냐는 의견이 있었다. 나는 해당 인터페이스를 사용하는 것만 알면되지 어떤 구현체가 들어오는지를 컨트롤러에서 알 필요가 있냐는 입장? 또 다른 추가 의견으로 구현체를 불러오는 부분을 팩터리를 하나 만들어서 다 모아 놓는 방법도 추천받았다. 자료구조 : 알고리즘 문제를 가끔 풀고 있고, 쏘카 코테를 보면서 큐를 이용해 BFS를 처음 풀어봤는데 재미있었다! 자료구..

드디어 6주 간의 실전프로젝트가 끝났다. 이번 주 내내 발표자료를 만들고, 깃허브 리드미를 수정하면서 프로젝트를 돌아볼 수 있었다. 6주간 팀원들과 이정도의 성과를 낸 것이 뿌듯하기도 하지만, 아쉬운 점도 많다. 기술적으로는 redis와 같이 프로젝트 중반에 망설이던 부분을 초반에 과감하게 도입했으면 어땠을까, 라는 아쉬움이 있고, 테스트코드나 로그, swagger 같은 것들도 초반에 도입했다면 훨씬 더 좋았을 것 같다. 개인적으로 혹은 팀원을 구해서 프로젝트를 하게 된다면, 컨벤션이나 깃헙 등 초반에 정해놓고 갈 부분들은 확실하게 정하고 진행할 것 같다. 개인적으로 공부하고 싶은건 너무너무 많은데, 우선 취업이 우선이라 당분간은 취업준비 + 코딩테스트 준비에 집중할 것 같다. 프로젝트하면서 스스로 클라..

드디어 배포했다!! 원래 30일에 배포하려고 했는데, 마지막에 테스트하다가 에러를 발견해서 수정 후 31일 새벽 1시쯤에 다시 배포하고 슬렉에 홍보글을 올렸다. 정말정말 놀란게, 새벽임에도 불구하고 엄청나게 많은 분들이 접속해주셨다!!! spring서버는 EC2에서 CPU를 확인했을 때 90%까지 올라갔었고, DB에서 유저 수도 계속 20여명을 유지했다. DB에 유저수는 방을 만들거나 참여한 순간에 생성이 되서 실제 메인페이지에 접속한 수는 구글 애널리틱스를 참고할 때 40명이 넘었던 것 같다(해당 시간 피크가 60명 정도?!) 그리고 오류제보와 만족도 조사도 정말 우르르 들어왔는데 ㅋㅋㅋㅋㅋ 퀴즈를 안풀었는데 스코어가 올라가거나 찬스가 무한으로 사용되는 경우(찬스가 -1이 안되서), 다른 방과 보이스 ..

nodeJS 쪽 CI/CD는 내가 진행을 했는데 설정할 게 많지 않아서 반나절 만에 끝났다! 근데 Spring은 다른 팀원 분이 맡고 계셨는데 HTTPS나 properties 관련해서 설정 파일 문제도 있었고, 특히 nginx를 적용하는 과정이 매우 어려워 보였다... 먼저 성공하신 다른 팀원분이 정말 옆에 완전 붙어서 같이 해결해주셔서 실마리를 좀 찾은 것 같다. 정말정말 너무 감사하다!!! 다행히 주말 사이에 nginx까지 성공하셔서 행복한 월요일을 맞이했다(그런줄 알았다...ㅜㅜ) 지난 주에 spring쪽에 로그를 설정하고, EC2에 배포한 상태에서도 로그 파일이 잘 저장되는 것을 확인했는데, nginx로 돌리고 나서부터는 로그 파일이 저장되지 않았다. 찾아보니 nginx 에서도 PM2처럼 로그파일..

데이터 관리 방식을 변경하면서 관련 로직 수정은 모두 끝났고, 아직 MySql에서 S3로 옮기는 부분은 구현하지 못했다. 그런데 데이터 옮기는 것은 우선 데이터만 잘 쌓아놓으면 나중에 진행해도 될 것 같고, 다음주에 정식 배포하기 전에 배포 쪽 문제를 먼저 마무리해야할 것 같아서 먼저 시작하기로 했다. spring쪽은 다른 팀원이 진행하고 있고, github actions+codedeploy+nginx 조합으로 할 것 같다. nodeJS도 처음에 같은 조합으로 생각하고 github actions을 시작했는데 생각보다 자료가 없었다. 그리고 찾아보다 보니 github actions를 쓰지 않고 codedeploy+codepipeline으로 하는 것도 괜찮은 것 같아서 이렇게 시도했다. 주로 참고한 블로그 ..

데이터 부분은 수정이 끝났다! 생각보다 수정해야 하는 부분이 많았는데, 다행히 오래걸리지는 않았다. 게임 종료 후에 User와 Clue는 삭제하기로 하고, Room과 Quiz만 남기기로 했다. 그리고 Room에는 State와 Pass라는 값을 주어서, 게임이 종료되거나 게임 종료 api가 오기 전에 disconnect로 방이 사라지면 State를 CLOSE로 바꾸어서 비활성화된 정보라는 것을 표시해주고, 메인페이지에서 방을 조회할 때도 데이터가 내려가지 않도록 하였다. 그리고 나중에 S3로 데이터를 옮길 때, CLOSE된 Room과 해당 RoomId를 가지고 있는 Quiz 정보들이 그 대상이 될 것이다. 처음에는 Quiz에도 State를 만들고 게임 종료 시 업데이트를 해주려고 했는데, Room만 sta..

중간발표를 무사히 마쳤다. 지난 주 내내 중간발표때문에 조급했었는데, 다행히 잘 끝났다. 생각하지 못한 부분에서 질문을 많이 받았고, 앞으로 남은 3주 동안 어떻게 할 것인지에 대해서도 얘기해봤다. 백엔드가 비교적 기능 구현이 빨리 끝났고, 이후에 기능 추가나 성능 개선하는 부분에서 선택지가 너무 많아서 어떤 걸 해야할 지 계속 고민이 많았다. 중간발표 때 받은 피드백을 중심으로 기본적인 부분에서 미흡한 부분을 개선하기로 했고, 깃허브의 기능들도 더 적극적으로 써보기로 했다. 그리고 백엔드에서는 다음의 3가지에 초점을 맞추기로 했다. - 배포 자동화와 무중단 배포 - 테스트 코드 작성 - DB 배포 자동화와 무중단 배포는 프로젝트에 도입해보고 싶었던 기능이기도 하고, 정식 배포 전에 기능을 구현해놓으면 ..