전체 글

Contents 시작하기 Part 1. 요구사항 정의하기 Part 2. 워크플로우 정리하기 Part 3. 위치정보 저장 (Write Operation) 워크플로우 구성 Part 4. 클래스별 구현 및 설명 Part 5. Integration 테스트 작성 테스트를 위한 테스트 환경 셋업 테스트 셋업 코드 테스트 케이스 1 테스트 케이스 2 테스트 케이스 3 Part 6. 마치며 시작하기 오늘은 우아한 중계서비스 프로젝트 진행과정에서 요구사항/추가기능 발생시 어떻게 구현하는지를 예제를 통해 소개하려고합니다. 이번 블로그는 리액티브한 코드작성과 테스트 작성에 무게를 두고 작성해보겠습니다. Part 1. 요구사항 정의하기 기능 소개 : 라이더 위치 기능? 라이더 위치 기능을 하이레벨 뷰로 한번 보겠습니다. 라이..

Contents 시작하며 IntelliJ에 적용하기 1. 아래 링크에 플러그인을 설치하세요. 2. IntelliJ 에서 설정을 활성화해줍니다 3. 끝입니다. 사용하세요 GitHub 프로젝트 레벨에서 적용하기 1. 프로세스 이해하기 2. 워크플로우 파일 생성하기 3. 워크플로우 작성하기 4. Push 하기 5. 결과 확인하기 추가 적용 가능 사항 1. google-java-format 워크플로우 다른 옵션들도 확인해보기 2. 워크플로우 고도화하기 정리하기 시작하며 팀 단위 프로젝트에서는 코딩 컨벤션을 정하고 준수해야 합니다. 단편적인 이유로 참여자 모두 포맷팅을 제외한 실제 변경사항만 볼 수 있기 때문입니다. 분명 제각기 다른 개성을 가진 코드 스타일들이 있을 테니 코딩 컨벤션을 모두 지키며 개발하기란 쉽..

오늘은 테스트메소드 템플릿 수정 방법에 대해 소개해보려합니다. IntelliJ (Ultimate & Community) 에서 테스트 작성시 상당히 편리한 기능이라서 공유하게 되었습니다. IntelliJ 를 사용하며 테스트코드를 작성한다면 Arrange-Act-Asesrt 혹은 Given-When-Then 패턴 등을 사용합니다. 여러 테스트 검증 패턴을 아래사진 처럼 주석으로 달아 테스트 메소드를 분할하는 분들이 많을것이라고 생각합니다. 만약 저 주석들을 일일이 타이핑 하고 계시다면 잘 찾아오셨습니다. 이제 순서대로 설명드리겠습니다. 1. 테스트 클래스로 이동하기 IntelliJ에서 제공하는 기능이니 IntelliJ 가 테스트 소스로 인식하는 클래스에서만 사용이 가능합니다. ApplicationTest 클..

Contents # 시작하며 # G o o d : 용어의 선 # B a d : 용어의 악 # DTO-VO-Entity-Dao 1. Good : DTO-VO-Entity 들은 "왜" 필요할까? 2. Bad : DTO-VO-Entity 와 같은 정의들은 "꼭" 필요한가? # 결론은 # 시작하며.... 최근 멘토링을 진행하며 DTO, VO, Entity , Domain 등의 단어를 정말 많이 사용한 것 같다. 멘토님이 몇번 들으시더니 위 용어들의 정의를 찾아보고 공유해달라고 하셨다. 예리했다. 내가 생각하는 의도가 맞다면 프로젝트 과정에서 꼭 필요한 작업이라고 생각한다. 나는 가족과 회의나 토론을 정~말 많이한다. 그렇게 살다보니 커뮤니케이션 과정에서 공통된 정의를 가지고 있지 않은 용어들과 암묵적인 전제는 ..

이번 포스팅은 혹시나 다른 방법을 찾으신 분은 댓글로 공유 부탁드립니다! Contents 0. "중계 서비스" 관점에서 API 문서화가 필요한 이유 1. Swagger 채택 이유 1-a. 적용을 위한 비용이 상대적으로 낮습니다. 1-b. Swagger에서 Spring Rest docs로 전환하는 케이스가 많습니다. 1-c. 저렴한 전환 비용 2. Swagger : 단점과 보완 전략 2-a. 검증이 되지 않은API의 노출 2-b. 서비스를 위한 코드와 문서화 코드의 결합 3. 서비스 코드와 문서화 코드의 분리 방법 3-a. Swagger의 동작 원리 3-b. 적용 순서 3. 마치며... 0. "중계 서비스" 관점에서 API 문서화가 필요한 이유 최근 프로젝트에 문서화 툴을 적용하자는 제안을 받았습니다. 물..

Contents 시작하며 Level 1. 이벤트 순서대로 나열하기 갑자기 Bonus? 중개와 중계 차이점 Level 2. 역할 관점으로 분리하기 Level 3. 결과 반환시점을 기준으로 기준으로 분리 Level 4. 커뮤니케이션 역할에 따른 서비스 분리 Level 5. 동기-비동기로 분리 Level 6. 초기세부구현 : 시작점 Level 7. 추후 고민이 필요한 부분들 1. 주문상태확인 기능 2. 중개 기능 (요청 전달) 3. 라이더의 위치정보 오늘은 여기까지 시작하며 지난번 블로그에서 프로젝트 주제선정 과정과 기초 유저 플로우(위 사진)를 소개해드렸습니다. 이후 저는 상세 구현 목록과 서비스 아키텍처를 도출하기 위해 로버트 마틴 "클린 아키텍처"를 옆에 펼쳐놓고 서비스를 디테일하게 분석하기 시작했습니다..

Contents 0. 시작하기 앞서 1. 주제 범위 좁히기 2. 주제는 "배달의민족 중계 서비스"로 정했습니다. 3. 유저 플로우를 정의했습니다. 4. 마치며.... 5. 참고 자료들 0. 시작하기 앞서 팀프로젝트 주제 선정은 왜 중요하고, 왜 어려울까요? 우선 주제는 명확할수록 개발 과정에서 협의가 순조롭게 진행될 수 있기 때문입니다. 또한 주제는 프로젝트 이름에 반영되고 프로젝트 이름은 git repo와 소스 코드에 조금이라도 반영되기 때문입니다. 저는 과거 여러 프로젝트들을 거치면서 나름의 주제 선정 전략을 다듬어왔고 이번 프로젝트 주제를 기대 이상으로 순조롭게 정할 수 있었습니다. 주제도 팀 전체가 만족하는 것으로 보입니다. (please!) 그래서 오늘은 이번에 적용해본 주제 선정 과정을 여러 ..

Contents 프로젝트를 시작합니다 프로젝트를 통해 목표하는 우리의 경험 마치며 프로젝트를 시작합니다 프로젝트를 싫어하는 사람이 있을까요? 드디어, 제가 참여하고 있는 F-Lab 멘토링에서 팀 프로젝트를 시작하게 되었습니다! (참고로 이론 공부도 재밌습니다) 저는 프로젝트라면 다 좋은데요 그중 팀 프로젝트에서 재밌는 부분은 커뮤니케이션 때문인 것 같습니다. 정말 열심히 연구해서 공유한 솔루션이 반영돼도 좋고, 그 내용보다 더 효과적인 솔루션을 찾으면 하나 배우게 돼서 좋고, 그렇습니다. 이번 프로젝트는 전반적인 프로젝트 진행 과정을 저와 멘티님 한분이 주도하게 되서 더 의미 있을 것 같네요. 오늘은 F-Lab 에서 제안하고, 멘토님도 제안하시고 제가 배우는 입장에서 생각해보는! 프로젝트를 통해 목표하는..