한결과 레지아이스

42GG 백엔드 시퀀스 다이어그램 2부입니다. 이번 글은 정보 전달이라기보다는 기록에 의미를 두고 작성하게 되었습니다. 백엔드에서 사용한 컨트롤러가 이것뿐이지는 않지만, 구현할 때 애를 먹거나 단순 조회가 아니고 무언가 로직이 들어간 부분들에 대해서 정리해 보았습니다. 개인적으로는 로직도 중요하지만 어떤 예외 처리를 어떤 이유로 했는지도 꽤나 많이 배우게 된 부분입니다. 로직을 만드는 것은 누구나 고생한다면(혹은 하지 않아도) 만들 수 있지만, 서비스로서 원활히 돌아가게 하기 위해선 수많은 예외 상황들을 생각하고 이에 대해 적절한 처리를 해줘야 한다고 느꼈습니다. 사실 저희 서비스에서 로직은 어려운 부분도 아니고 누구나 비슷하거나 어쩌면 다른 더 나은 방식으로도 비슷한 결과를 낳도록 구현하는게 어렵지 않..

42GG 서비스를 개발하며 스케쥴러를 사용하고, 그 과정에서 추상 클래스를 처음 만들어본 경험을 적은 글입니다. 우리 서비스엔 총 4개의 스케쥴러가 존재한다. 우리 서비스를 제공하는 2시에서 5시 사이에 각 5분, 10분 간격으로 돌아가는 스케쥴러 하나씩, 그리고 매일 한 번씩 실행되는 스케쥴러가 두 개 해서 총 네 개이다. 이런 스케쥴러를 어떤 방법으로 만들었는지, 그리고 처음에는 하나였던 스케쥴러가 네 개로 늘어나며 어떻게 추상 클래스를 구성하게 되었는지 설명해보려 한다. 스케쥴러 우리 서비스는 매일 일정 숫자의 게임 슬롯을 생성한다. 그리고 매 5분 간격으로 슬롯이 꽉 찼는지 여부에 따라 잠시후 매치가 시작된다는 알림을 보낸다. 10분 간격으로는 게임이 성사되었는지 여부에 따라 취소되었다는 알림, ..

우리 프로젝트에 정식으로 멘토님이 배정되거나 한 것은 아니었지만, 오며가며 많은 조언을 주시고 도움을 아끼지 않아주신 이호준 멘토님이 계십니다. 저희 프로젝트 팀에 관심을 많이 가져주시고 도와주셔서, 그리고 좋은 기회까지 주셔서 이 자리를 빌어 크게 감사의 마음을 전하고 싶습니다. 이호준 멘토님 왕감사합니다! 시퀀스 다이어그램은 전적으로 멘토님께서 제안해주셔서 그려본 것입니다. 설계 단계에서 미리 그리고 시작했다면 더 좋았겠지만, 개발 단계에서 그렸는데도 큰 도움이 되었기에 포스팅을 하게 되었습니다. 로그인 시퀀스 우여곡절 끝에 개발된 로그인 시퀀스이다. 42서울 내부에서만 사용할 계획이었고, 구성원들만 이용할 수 있는 탁구대에 대한 서비스였기 때문에 42OAuth를 통한 로그인만 구현했다. 아직 구현되..

기존의 42GG DB 설계를 박정규 멘토님께 조언을 구해 수정했습니다. 원래는 어땠고, 우리끼리 어떻게 고민했으며, 결국 어떻게 바꿀 지에 대해 적었습니다. 0. DB 설계도 변천사 a. 기존 설계 b. 멘토링 이후 기존 설계에 관계성 추가 c. 매핑 테이블을 이용해 수정한 결과 42GG 서비스는 처음에 어떤 종류의 게임이든, 팀이 몇 개 존재하든, 각 팀에 몇 유저가 존재하든 상관없이 대전 서비스를 제공할 수 있도록 확장성을 염두에 두고 설계를 했다. 이 과정에서 어려움을 겪어 기존의 형태로 설계했는데, 먼저 어떤 시행착오를 겪었는지 설명해보려고 한다. 1. 태초의 설계 DB설계를 처음 해봤고, 팀원들도 함께 미숙하던 시절이라 최대한 확장성을 염두에 두고 만드려면 어떻게 해야 할까 고민을 많이 했다. ..