Seok.LE

문득 진행했던 프로젝트명이 TDD인데 테스트 커버리지 0%인 걸 보고 그래도 이름에 맞게 커버리지 80%까지는 올려보자 라는 생각으로 작성을 시작했다.하지만..테스트 코드를 작성하다 보면 자주 겪는 문제 중 하나는 바로 시간 관련 로직을 처리할 때 발생합니다. 특히, LocalDate.now()와 같은 시간을 직접적으로 로직 내에서 사용하면 테스트 코드가 실행되는 날마다 값이 달라져 테스트가 실패하는 문제가 발생합니다.시간에 의존적인 테스트 예를 들어 다음과 같은 코드가 있습니다:if (LocalDate.now() == todo.deadline) { // 특정 로직 수행}이 코드의 문제점은 테스트가 실행되는 날짜가 매번 바뀌기 때문에, 실행하는 날에 따라 테스트 결과가 달라질 수 있다는 것입니다.처..

저는 최근 Spring RestDocs를 활용하여 REST API를 문서화하는 작업을 했습니다. 하지만 RestDocs를 기본적인 형태로 사용하면 다음과 같은 코드가 만들어지곤 합니다.requestFields( fieldWithPath("username") .type(JsonFieldType.STRING) .description("회원 이름"), fieldWithPath("avatarUrl") .type(JsonFieldType.STRING) .description("GitHub 프로필 URL"), fieldWithPath("gitUrl") .type(JsonFieldType.STRING) .description(..

Distance서비스를 운영하면서 사실 마냥 순탄치는 않았습니다.서비스를 운영하면서 겪었던 문제 중 하나인 "Postman을 통한 무한 API요청"을 효과적으로 차단한 경험을 공유하려 합니다. 저희 서비스는 축제 시즌에 배포된 서비스인데 00대학교에 배포 중 갑자기 오후 11시쯤에 Slack으로 알림하나가 날라왔습니다.이 에러는 저희 서비스에 굉장한 크리티컬한 에러였습니다.사용자가 Distance서비스에 신규 가입을 하려면 반드시 SMS인증을 통해 가입을 할 수 있는데 그 인증 API가 일일 사용량 초과가 된 것입니다.분명 일일 한도가 약 390건 정도가 남아있었는데 이게 한 순간에 사라진게 이상하게 생각해 발송내역을 보니 한 번호가 391건의 요청을 했던 것을 확인할 수 있었습니다. 알고보니 Postm..

위의 화면은 사용자가 distance를 들어왔을 때 가장 먼저 볼 수 있는 화면이다.저 화면에 보이는 유저 4명은 총 3가지(비로그인 유저, 로그인한 유저, 로그인은 했지만 GPS추적을 거부한 사람)유형으로 구분하여 DB에서 불러오는 방식을 사용했다. 오늘 개선할 부분은 바로 로그인한 유저의 매칭 부분을 개선할 것입니다. public MatchResponseDto getNotFoundPositionMatchList(Member centerUser) { List userDtoList = memberReader.findMemberList().stream() ... .collect(Collectors.toList()); return getMatc..

우리 서비스의 MVP기능을 뽑으라하면 위치기반을 통한 매칭과 채팅이라고 할 수 있다.우리가 원하는 채팅의 수준은 카카오톡과 비슷했다. 1. 1대1 채팅이 가능하여야 한다.2. 채팅방 내에서 사진을 보낼 수 있어야한다.3. 채팅방안에서 실시간으로 읽음표시가 사라져야 한다.4. 채팅 목록에서 실시간으로 메시지의 변화를 감지해서 보여주어야한다.총 이렇게 3가지였다. 다른 건 사실 크게 어렵지 않았고, 1, 2번은 굳이 없어도? 크게 불편하지 않았다. 하지만 3, 4번 같은 경우는 없으면 불편하고 사용자에게 버그처럼 느껴질 수도 있을 거 같았다. 우선 3번 같은 경우는 사용자가 방에 들어오면 Event를 감지하여서 Session Table에 값이 들어옴으로써 방에 있는지 없는지를 확인할 수 있었고, 덕분에 읽음..

지금 프로젝트를 진행한지 어엿 반년이 지나고 800명의 유저와 3만건에 가까운 채팅을 많은 사용자들이 이용을 주었다..ㅎㅎ근데 가장 많이 들었던 아쉬운 점 중 하나가 "알림이 고장난거 아니에요?" 라는 피드백이었다. 왜 그럴까? 원래 초창기에 저희가 사용했던 알림 방식은 FCM을 통해서 채팅이 오면 바로 채팅내용을 카0오톡 처럼 바로 바로 보내주는 형식이었다.하지만 이렇게 하다보니 FCM자체가 동작을 안할 때가 있었고, 순서도 뒤죽박죽에 이미 갔던 문자알림이 또 가는 버그가 있었고, 무엇보다이렇게 했을 때 채팅하나 보내는데도 많은 쿼리가 나가는데 이에 FCM까지 전달하려고 하는게 아닌 거 같아 방식을 바꾸게 되었다. 그럼 어떻게 보냈냐?!특정 유저에게 메시지가 오면 FCM Table에 저장을 하고 스케줄..

구름톤에서 시작한 Distance프로젝트는 어느덧 순천향대, 경희대, 동국대, 서울여대, 한국외대를 지나 저희 팀의 리더분 학교인 전남대에도 배포를 하게 되었다. 저희가 이 프로젝트를 구현하고 순천향대에 첫 배포를 할 때 목표가 "서버를 터트릴때까지 해보자!" 였다.사실 ec2유형이 t2.micro여도 지금까진 단 한번도 서버가 터지지 않고 사용률이 70%이상만 가보기만 했다. 그리고 나름 채팅이 MVP이다보니 I/O가 많을 거 같아 미리 분산을 시켜두면서 나름 준비를 많이 해두었다.지금 현재 저는 판교에 있는 회사 인턴으로 하고 있는 중 2024/09/12에 전남대 단과대 축제에 맞춰 distance서비스를 배포를 하였다.오랜만에 배포라서 귀하디귀한(?) 점심시간도 자진 반납을 하고 서버 모니터링을 하..

TDD프로젝트의 구현을 마치고 앱스토어에 무려 1트만에 배포가 성공되어서 너무 기뻤다..ㅎㅎㅎㅎㅎ 이제 배포를 하고 문제점을 찾아가던 중 생각보다 치명적인 버그가 있었다.우리 서비스는 Todo를 등록하면 자동으로 사용자가 등록한 github repo의 README와 issue에 등록이 되는 서비스인데 만약 사용자가 깃허브에서 repo를 삭제하면 바로 버그가 생기는 것이다... 왜냐면 DB에는 사용자의 repo정보가 남아있는데 정작 깃허브에는 해당 레포가 없기 때문에 깃허브 repo READMD와 issue를 등록할 수 없기 때문이다..(물론 저 부분도 분리를 해야하는데 추후에 작업을 해보자,,,) 그래서 저 문제를 해결하기 위해 우선 webhook을 등록해서 사용자가 깃허브에서 repo를 삭제하면 자동으..

TDD프로젝트를 진행하면서 우연히 프론트분에게 todo를 불러오는데 로딩이 좀 있는거 같다 라는 연락을 받게 되었다.. 문제(?)의 동영상저걸 보고 전 어라? 저 부분은 데이터도 적은 부분인데 왜 로딩이 되지...? 라는 불안감이 생겼고, API테스터로 response time을측정해보니,,,,,,보자마자 와 뭐지,,API호출하는데 1.5초가 걸린다고? 라는 생각이 들면서 뭐가 문제인지 고민을 해보았습니다. 우선 제가 생각한 문제는 일자별로 DB에서 검색하는게 오래걸렸나..? 라는 생각을 하였습니다..그래서 cache를 적용해야하나? 라는 고민을 하며 우선 로그를 찍어서 한번 확인해보기로 했습니다. 우선 문제의(?) API의 Service를 보면fun findTodoLists(todoDateRequest..

이번에 제가 필요해서 시작한 프로젝트인 TDD 프로젝트의 코드 개선 과정에 대해 포스팅을 하겠습니다. 우선 TDD프로젝트는 개발자를 위한 TodoList서비스이고, 사용자가 TodoList에 할 일을 추가하면 깃허브 레포에 자동으로 이슈와 리드미가 생기게 되는 서비스입니다. (취준생은 잔디도 관리를 해줘야되기 때문에,,ㅎ) 그래서 이번 프로젝트에서는 대부분 Git API를 사용하는 코드가 많기 때문에 최대한 간결하게 정리를 해보고 싶었다.우선 처음 시도했던 코드를 보겠습니다. fun createTodoList( todoRequest: TodoRequest, username: String ): Long? { val member = memberReader.getMe..