우아한테크코스35 JPA entity에 validation annotation을 붙인 이유 예시로 사용된 코드는 깃허브를 통해 확인할 수 있습니다. validation annotation을 붙인 이유와 생성자 검증의 맹점에 대해 작성한 글입니다. DB에 있는 데이터들을 100% 신뢰할 수 있다!라고 생각한다면 이 글은 읽지 않으셔도 좋습니다. 모락 프로젝트를 진행하면서, Entity 필드의 검증 로직이 존재해야 하는 곳에 대한 토론을 많이 진행했습니다. 우리는 토론의 결과로 검증을 위해 Entity 필드에 validation annotation을 붙이는 것을 택했습니다. 모락에서 사용되는 Entity에 대한 예시로는 다음과 같습니다. Entity 필드에 대해 올바른 값인지 확인하는 방법은 2가지가 있습니다. 1. 위와 같이 각 필드에 validation annotation을 붙이기 2. Ent.. 2022. 8. 28. 모락의 Git branch 전략 Git branch 전략을 도입한 이유? 프로젝트 이전까지는 혼자서 개발을 진행했기 때문에 하나의 branch에서 편하게 작업할 수 있었다. 모락 프로젝트에서 6명의 개발자가 함께 코드를 공유한다. 6명이 하나의 branch에서 작업을 진행한다면 매우 많은 conflict들이 발생했을 것이다. 따라서 우리는 6명이 동시에 여러 작업을 수월하게 수행하기 위해 Git branch 전략을 도입했다. Git branch 전략 버전 1 다음 그림은 제일 처음으로 생각했던 branch 전략이다. 가장 간단하고 도입하기 쉬운 전략이다. 이 전략은 main branch와 feature branch 2개로 이루어진다. main : 실제 서버에 배포되는 production 코드가 존재하는 branch feature : 기.. 2022. 8. 27. 모락 프로젝트 전체 회고 프로젝트가 끝나고 느낀 점 이전까지 프로젝트를 제대로 해본 경험이 없었다. 앞으로는 제대로 프로젝트를 진행해본 경험이 있다고 말할 수 있게 되어 기쁘다. 프로젝트를 경험해보기 전에는 진정한 협업을 해보지 않았다. 페어프로그래밍이 협업이라고 생각해온 나에게 협업의 기준을 높여준 것 같다. 물론 나중에 실무에서 경험하게될 것에 비하면 이 모락 프로젝트도 애들 장난 수준의 협업일 수도 있다. 그래도 이 경험이 충분히 밑거름이 될 것이라고 생각한다. 매일 팀원들과 함께 하나의 목표를 가지고 고민을 했던 시간들이 굉장히 소중한 경험이었다. 프로젝트를 진행하면서 개발자 진로에 대한 생각도 많이 들었다. 협업하는 과정이 정말 좋은 경험이었지만, 뜻대로 되지 않는 날도 많았다. 예를 들어 팀원들간의 의견 조율이 어려웠.. 2022. 8. 22. 존재하지 않는 API 요청 커스터 마이징하기 존재하지 않는 API 요청을 커스터 마이징을 한 이유 기존에 백엔드 서버로 존재하지 않는 API가 요청되면 다음과 같은 응답을 건내주었다. 존재하지 않는 API가 요청 시 404 NOT FOUND를 응답한다. 모락 프로젝트에서는 이런 상황 뿐만 아니라 리소스가 존재하지 않는 경우에도 NOT FOUND와 error code를 던져준다. 따라서 존재하지 않는 API가 요청 상황에도 error code를 통해 에러 구분을 하고 싶었다. (참고 글) 커스터 마이징 과정 우선 커스터 마이징 이전에 존재하지 않는 API가 요청 시 어떻게 진행되는 지 DispatcherServlet을 확인해보자. 존재하지 않는 API로 요청을 보내보았다. http://localhost:8080/invalid-api 위의 요청을 보내.. 2022. 8. 16. 테스트 코드에 대한 나의 생각 모락 프로젝트를 진행하면서 제일 많이 고민했던 것은 테스트 코드이다. 따라서 테스트 코드에 대해서 내가 느낀 생각들에 대해서 정리해보려고 한다. 테스트 코드는 왜 작성해야 할까? 프로젝트를 하면서 제일 크게 느낀 것은 테스트 코드는 서비스의 품질을 보장한다. 테스트 코드를 이용하여 서비스에서 발생할 수 있는 에러를 미리 방지할 수 있다. 일단 우테코를 진행하면서, 테스트 코드를 작성하지 않는 것을 생각해본 적이 없다. 테스트 코드는 서비스에 생기는 에러를 미리 확인할 수 있게 해 준다. 테스트 코드가 작성되지 않은 서비스가 존재한다고 가정한다면, 개발자는 서비스를 배포하고나서야 서비스에 생기는 에러를 직면할 수 있다. 이러한 상황을 피하고자 우리는 테스트 코드를 작성해야 한다. 그렇다면 테스트 코드는 얼.. 2022. 8. 16. 레벨3 팀 프로젝트 7주차 회고 테스트 추가 이번 스프린트에서는 기능을 추가적으로 구현하기 어렵다고 판단되어 7주차에는 테스트 추가 및 리팩토링만 진행했다. 우리 서비스는 기능이 많을 수록 좋은 서비스이기때문에, 기능이 많아야한다. 그렇지만 이번 스프린트에서는 팀 회의를 통해 양보다 질을 택했다. 하나의 기능이라도 제대로 동작하게 만들자! 라는 취지였다. 테스트를 추가하는 것은 지난 6주간의 내가 원하던 것이었지만 막상 그 많은 테스트에 손을 대려니 오랜 시간이 걸리고 힘든 작업이었다. 그래도 추가적인 테스트를 만들어서 오류를 찾아내었을 때 되게 흐뭇했다. 역시 테스트 코드는 중요하다라고 생각이 들었다. 토미(코치)와의 수다 타임 금요일에 토미와 점심식사를 함께하였다. 토미와의 식사 후 둘만의 대화시간이 잠깐동안 있었다. 그 시간 동안.. 2022. 8. 13. Custom Error Code가 왜 필요했을까? 커스텀 에러 코드를 도입한 이유 이때까지 백엔드에서 예외가 발생하면 프론트엔드로 다음과 같은 응답 메시지를 보내고 있었다. // response { "message": "요청 형식이 잘못되었습니다." } 각 Http Status Code 마다 응답되는 message는 한 가지뿐이었다. 따라서 어떠한 예외가 발생하던 위의 4가지 중 하나의 메시지만 받을 수 있었다. 악의적인 사용자가 악의적인 요청을 보내 예외가 발생하는 경우 어떠한 잘못으로 인해 예외가 발생했는지 알 수 없게 하기 위해서 위처럼 메시지를 추상화하여 응답하였다. 그러나 이런 추상적인 메시지 덕분에 프론트 개발자가 개발하는데에 어려움을 겪게 되었다. 프론트 개발자가 개발 진행 중, 요청을 보냈을 때 예외가 발생하면 응답 메시지를 통해 어떤 예.. 2022. 8. 10. 모락 프로젝트의 서버 구조 (리버스 프록시) 모락 프로젝트 세 번째 스프린트에서 서버 구조를 설계하였습니다. 서버 구조를 설계하기 이전에 우리의 통신 방식은 다음과 같았습니다. 1. 정적 파일을 요청할 때는 정적 파일이 담긴 서버에 요청을 보냅니다. 2. 서버의 API 요청을 할 때는 서버로 요청을 보냅니다. 이러한 구조로 서비스를 실행할 때 문제가 있었습니다. 사용자가 서버 내부의 데이터가 필요하다면 WAS에 직접적으로 요청을 보내야 했습니다. WAS에 사용자가 직접적으로 접근할 수 있게 하였을 때는 여러 문제가 발생할 수 있습니다. 1. 보안 제일 큰 문제는 보안입니다. WAS에 직접적으로 접근이 가능할 경우 데이터베이스가 털릴 가능성이 있습니다. 데이터 베이스에는 우리의 중요한 데이터들이 많이 있기 때문에 항상 조심히 지켜줘야 합니다! 2. .. 2022. 8. 8. 레벨3 팀 프로젝트 6주차 회고 데모데이 이번 스프린트의 데모데이 발표를 맡아서 진행했다. 5분 정도밖에 안 되는 발표였지만, 엄청 떨렸다. 하루정도 준비를 하는 시간을 가졌지만, 막상 발표를 시작하니 다 까먹었다. 그래서 프리스타일로 발표를 진행해버렸고, 뭐라고 발표를 했는 지도 기억이 안 난다. 이렇게 부족한 말하기 능력은 앞으로 내가 극복해야 할 문제인 것 같다. 프로젝트 진행.. 이게 맞나? 데모데이에서 우리 팀이 발표한 것과 다른 팀들이 발표한 것들을 보면 다른 팀들은 이제 거의 마지막을 향해 가고 있는 데, 우리 팀은 이제 시작한 것 같은 느낌이 들었다. 분명 같은 시간 동안 프로젝트를 진행했는데, 왜 차이가 많이 나는 걸까? 이에 대해서 데모데이가 끝난 후 회고를 진행하였다. 우리가 생각한 원인 중 제일 큰 문제는 프로젝트.. 2022. 8. 6. 이전 1 2 3 4 다음
