본문 바로가기

분류 전체보기

 (35)
스탬프크러쉬 테이블 구조 개선기 레벨 3 때 우리 팀은 테이블 구조를 바탕으로 엔티티를 만들기 위해 테이블 설계부터 먼저 진행했다. 구현할 기능이 많았고 다들 프로젝트가 처음이었기에 여러 의견을 나누면서 테이블을 설계했었다. 그렇게 총 20개의 테이블이 나오게 되었다. 더보기 그리고 기능을 구현하면서 테이블 구조를 변경할 필요성을 느끼게 되었다. 구조 상 큰 변경이 있던 두가지 경우에 대해서 이전의 테이블 구조가 나오게 된 배경과 왜 바꾸게 되었는지의 내용을 정리해보았다. Customer 테이블 상속 구조 제거 우리 서비스는 고객의 편리한 적립을 위해 전화번호만으로 임시 회원으로 가입이 되어 스탬프 적립이 가능한 기능을 제공하기 때문에 Customer 테이블을 Register 와 Temporary 로 나눌 필요성이 있었다. 그때 한창 ..
롬복(lombok) 의 @EqualsAndHashCode 는 필드로 비교할까 getter 로 비교할까 팀 프로젝트에서 롬복을 사용하기로 하면서 @Getter, @RequiredArgsConstructor, @NoArgsConstructor 등의 어노테이션을 많은 엔티티에 붙이게 되었다. 롬복은 Equals, HashCode 를 재정의해주는 @EqualsAndHashCode 도 지원해주기에 별다른 생각 없이 해당 메서드들의 재정의가 필요한 엔티티에 어노테이션을 붙이게 되었다. 그리고 코드 리뷰를 받았는데 롬복에서 제공해주는 @EqualsAndHashCode 는 값을 필드로 비교하는지 getter 로 비교하는지를 묻는 리뷰였다. 왜냐면 JPA 를 사용하게 되면서 지연 로딩과 프록시 객체의 개념을 학습하게 되었는데, 지연 로딩을 하면 연관 객체를 실제로 사용하는 시점(get() 을 해오는 시점) 에 데이터베이..
5차 데모데이 회고 짧았던 일주일 간의 방학이 끝나고 레벨 4가 시작이 되었다 레벨 4 부터는 강의와 미션이 추가되기 때문에 프로젝트에 좀 소홀해질수밖에 없다는 이야기를 들었다. 그래서 스프린트 미팅때 각자 프로젝트, 미션, 개인 공부의 비율을 어떻게 가져갈지 논의하는 시간을 가졌다. 다들 생각이 비슷비슷했는데 아무래도 우리의 포트폴리오 중에 가장 중점이 되는 부분이 프로젝트일 것이기에, 프로젝트의 완성도를 높이고 실제 사용자를 유치하고 싶어했다. 그래서 다들 평균 40 정도는 프로젝트에 투자하는 방향으로 의견을 냈고, 우테코가 끝나고나서도 취준을 하지 않고 학교로 돌아가는 크루들은 유지보수를 계속해서 하기로 했다 (취준 하는 크루들도 여력이 닿으면 하는걸로. 서버비는 그때가서 생각!) 이번 데모데이에서 가장 중요 이슈였던..
Tomcat 구현하기 (1) - Servlet 우아한테크코스 레벨 4 첫번째 미션을 진행하면서 정리하는 내용 Servlet Java 기반의 웹 기반의 요청에 대해 동적으로 처리해주는 역할(WAS) 웹 서버가 동적인 페이지를 제공할 수 있도록 도와준다 클라이언트의 요청을 처리하고 그 결과를 반환한다 html 을 사용해서 요청에 응답한다 Java Thread 를 이용해서 동작한다 Servlet Container 서블릿을 관리해주는 컨테이너 대표적으로 톰캣 서블릿 웹서버간 통신을 도와준다. (소켓 사용) 서블릿 생명 주기 관리 멀티쓰레드 지원 1. 톰캣의 Connector 중 하나를 통해 request 를 전달받음 2. 요청을 받으면 HttpServletRequest 와 HttpServletResponse 객체를 생성한다 3. Engine 에서 적절한 서..
API 문서화에 RestDocs + Swagger UI 적용하기 API 문서 자동화를 해야 할 필요성을 느끼면서 알게 된 방법은 2가지가 있었다. 1. Swagger 2. RestDocs 처음에는 사용이 간편한 Swagger를 사용했었다. build.gradle 에 implementation 'org.springdoc:springdoc-openapi-ui:1.6.6' 위의 의존성 하나만 추가해주고 코드에 @Configuration public class SwaggerConfig { @Bean public OpenAPI customOpenAPI() { return new OpenAPI(); } } 이 Config 클래스만 등록해주면 간편하게 API 문서가 자동화가 되는 것을 확인할 수 있었다. 하지만 API 가 어떤 동작을 하는 API 인지, URI의 쿼리 파라미터나 ..
런칭 페스티벌 회고 레벨 3 의 마무리인 런칭 페스티벌을 잘 끝마쳐서 기분이 매우 좋은 상태로 회고를 작성한다. 마지막 스프린트에서 가장 중점을 두고 구현했어야 하는 부분들은 그동안 미룰 수 밖에 없었던 회원가입/로그인과 우리의 숙원사업이었던 쿠폰 커스텀 기능(이미지 저장) 이었다. 스프린트의 첫 날은 같은 코치들 아래 있는 두 팀(펀잇, 슉) 과 함께 하는 버그리포팅 데이였다. 사실 버그리포팅을 할때는 딱 보이는 것이 프론트 화면이어서 UI 관련 버그 리포팅이 많았다. 그래서 스프린트 첫주차에 우리 프론트엔드 크루들은 가득 쌓인 버그 이슈들을 수정하면서 디자인까지 엄청난 변화를 주었는데.. 정말 고생이 많았을 거였다😢 스프린트의 첫 주차에 백엔드는 추가 구현해야 할 간단한 API (스탬프 적립내역 조회, 리워드 사용 내역..
3차 데모데이 회고 3차 데모데이는 아쉬움 그 자체다.... 코로나 유행이 다시 왔는지 몰랐는데 면역력이 떨어져 있는 사이 어디서 감염이 된 건지 코로나에 걸려버렸다.. 하필 월요일에 확진 판정을 받는 바람에 데모데이가 있는 주를 통째로 결석하고 말았다 😭 데모데이까지 참여하지 못하게 되어서 너무 아쉽지만 우리 팀이 3차 데모데이까지 잘 마치고 점점 서비스가 완성이 돼 가고 있는 거 같아서(아직 할 일이 많지만...!) 좋다. 이번 스프린트의 목표는 고객 - 사장 간 한 사이클을 돌 수 있게 해서 서비스를 사용할 수 있도록 하는 것이었다. 2차 때는 사장 모드만 구현했었기 때문에 사장이 발급해 준 쿠폰을 확인할 수 있는 방법이 없었다. 그래서 이번 스프린트 때는 고객 모드에서 쿠폰 조회 해오는 기능과, 사장 모드에서 쿠폰 ..
git fetch, rebase, merge, pull 명령어 확실히 알아보기 Git을 1년 이상 사용하고 있지만 아직도 확실히 알지 못해서 사용할 때마다 미심쩍은 부분을 가진 명령어들에 대해 확실하게 정리하기 위해서 글을 작성한다. 사실 나 혼자 하는 프로젝트라면 Git 명령어들을 막 사용해도 별 상관이 없었다. 혹시나 잘못 사용해서 커밋 이력이 다 날아가더라도 내가 다 알고 있는 코드들이니까 다시 복구하면 된다. 그런데 이제 협업 프로젝트를 진행하다 보니 Git 명령어들을 잘못 사용해서 다른 사람의 작업 내역을 날아가게 할까 봐, 커밋 이력이 꼬이게 될까 봐 걱정이 되었다. git push 하려니까 git pull 하라고 경고창이 뜨고 그래서 git pull 을 입력했더니 warning: Pulling without specifying how to reconcile diverg..

티스토리툴바