알고리즘 고수가 되기까지

1. K : Keep, 현재 만족하고 있는 부분 또는 계속 이어갔으면 하는 부분
2. P : Problem, 개선이 필요한 부분
3. T : Try, 문제에 대한 해결책 또는 다음에 시도해 볼 것

1. K

   (1) 프로젝트의 결과를 위해 목적지향적으로 개발했던 점을 가장 칭찬하고 싶다. 일정 테이블을 타이트하게 만들어서 개발할 때는 힘들었지만, 마지막에는 오히려 수월하게 마무리할 수 있어서 좋았다. 힘든 2주였지만, 많은 것을 배우고 느끼게 돼서 뿌듯하다.

   (2) 이전 토이프로젝트에서 QueryDSL을 한번 사용해보았던 경험을 바탕으로 이번 프로젝트에서는 보다 복잡한 쿼리를 QueryDSL로 성공적으로 작성하였다. 야놀자 현업에 계신 분께서 실제 현업에서도 이렇게 작성한다는 말에 뿌듯했다. 한번에 바로 짠하고 작성된 것은 아니지만, 이것저것 찾아보고 시행착오도 겪어보면서 QueryDSL에 대해 좀 더 깊게 이해하게 되었다.

   (3) 동시성 처리에 도전해 보았다. 이전 토이프로젝트에서는 QueryDSL이었다면, 이번에는 동시성처리에 도전해보았다. 처음에는 데이터소스를 분리해서 MySQL의 named lock을 이용해서 구현했지만, 이후에 KPT기간에 실제 현업에서 많이 사용하는 Redis의 redisson을 적용하는 것으로 리팩토링 함으로써 커머스 서비스의 구조를 엿볼 수 있었다. 사실, 야놀자 멘토님께서는 모든 객실을 야놀자에서 관리하지 않기 때문에 실제 야놀자는 동시성 처리는 하지 않는다고 들었습니다...

2. P

   (1) 테스트 코드 작성을 소홀히 하였다. 핑계겠지만, 타이트한 일정에 기능 구현하기 바빴던 터라 테스트 코드 작성을 소홀히 했다. 중간중간에 테스트 코드 작성이 미흡했을 때의 한계를 느꼈다. 당연히 될 거라고 생각해서 테스트 코드를 작성안했는데, 그 부분에서 오류가 나자 테스트 코드의 중요성을 다시 한번 느낄 수 있었다.

   (2) 코드 리뷰를 소홀히 했다. 개인적으로 코드 리뷰 하는 것을 재밌어 하는데, 시간이 부족했다(핑계다ㅜㅜ). 그래도 KPT 기간에 팀원들과 제대로 해보자고 해서, 조금이라도 맛을 보며 재밌게 해볼 수 있었다.

3. T

   (1) 파이널 프로젝트도 성공적으로 마무리 하자!

   (2) 테스트 코드 작성과 코드 리뷰를 꼼꼼히 해보자!

   (3) 파이널 프로젝트 하면서 새로운 기술을 도입하게 되더라도, 겁먹지 말고 도전적으로 공부하자!

 미니도 성공적으로 완료했다ㅎㅎㅎ. 그리고 무엇보다 지금 팀원들과 2주간 하면서 정들었는데, 바뀌어야 한다는 것이 너무 아쉽다...ㅜㅜ 덕분에 너무너무 즐겁게 프로젝트하게 되어서 팀원들 모두에게 감사하다. 마지막 파이널 프로젝트도 화이팅해서 마무리 잘 해보자!!!

1. K : Keep, 현재 만족하고 있는 부분 또는 계속 이어갔으면 하는 부분
2. P : Problem, 개선이 필요한 부분
3. T : Try, 문제에 대한 해결책 또는 다음에 시도해 볼 것

1. K

   (1) 모르는 기술에 대해 두려워하지 말자. 이번 프로젝트에 처음으로 Spring Security와 QueryDSL을 써보았다. 처음하다보니 두렵고 막막했는데, 하나하나씩 천천히 배우다 보면 별 것 없다는 것을 깨달았다. 새로운 것에 두려움을 버리자.

   (2) 2차때 가장 많이 들었던 생각은 '서비스도 생각하자' 였다. 기획서대로 구현이 아닌, 서비스적으로 고민해보고 설계를 진행했다. Entity 설계를 많이 바꿔서 나름 서비스 답게 구현했다. 내가 만드는 기능이 서비스에 어떻게 사용될지를 생각해보면서 구현하니 더 재밌었다.

   (3) 팀원들에게 도움이 되는 팀원이 되자. 팀원들이 물어볼 때, 친절하고 자세히 알려주자. 팀원과의 좋은 관계는 팀의 힘과 직결된다.

   (4) 다른 사람 코드를 보며 배우자. 더 깔끔하고 좋은 코드를 보며 따라하고 성장하자.

   (5) 2회차 이후에 적용해보려했던 Issue와 Code Review를 적용했다!

2. P

   (1) 핑계겠지만... 시간이 부족해서 Swagger를 사용해보지 못했다. 3차 끝나고도 바로 미니라 다음 프로젝트에 Swagger를 적용해볼 수 있을지는 모르겠지만, 이후에 습득해보자

   (2) Security에서 refreshToken을 적용하지 못했다. Redis를 이용해서 구현하고 싶었는데, 시간이 부족해서 적용하지 못했다. 보안이 취약한 서비스임.

   (3) Github commit을 좀 더 체계적으로 할 필요가 있다. commit 관리는 변경 관리이다. 지금은 필요성을 못느끼더라도 나중을 위해서 commit 관리를 하자.

3. T

   (1) Github Project를 사용해서 프로젝트 관리를 해보고 싶다. 미니프로젝트가 프론트엔드 사람과 같이하는 나름 중형의 프로젝트이므로 적용하면 좋을 것 같다!

   (2) Code Review를 좀 더 적극적으로 해보고 싶다. 같은 팀원들이 소극적으로 하기에 같이 소극적으로 되는 것 같다. 팀원들과 같이 얘기해서 적극적으로 하고 싶다.

작성하면서 보니까, 잘한점이 많아서 뿌듯했다!!! 미니 프로젝트도 화이팅!!!

1. K : Keep, 현재 만족하고 있는 부분 또는 계속 이어갔으면 하는 부분
2. P : Problem, 개선이 필요한 부분
3. T : Try, 문제에 대한 해결책 또는 다음에 시도해 볼 것

1. K

   (1) 이전 프로젝트를 진행한 후에 개선해야 할 점을 미리 문서로 정리한 후, 프로젝트 시작하기 전에 팀원들과 다같이 공유한 부분이 좋았다.

   (2) Java 및 Git commit 컨벤션 등 룰을 정해서, 마치 '한 사람'이 프로젝트를 구현한 것 처럼 보이게 해서 프로젝트에 짜임새를 더하였다.

   (3) RFP를 보고 구현 전에 사전 설계를 진행해서, 프로젝트의 변경 가능성을 최소화 하였습니다.

2. P

   (1) RFP에만 충실하기 위해 구현을 하였다. 물론 기획자가 아닌 개발자지만, '서비스가 어떻게 흘러갈까?' '다른 서비스는 어떻게 제공될까?' 등 구현하려는 서비스 자체의 흐름을 더 꼼꼼하게 파악할 필요가 있었다고 생각한다. 우리 팀은 서비스 자체에 집중하기 보다는 RFP에 나와있는 사항들을 빠짐없이 구현하는데에 더 초점을 두었던 것 같다. 다음 프로젝트 때는 서비스 자체부터 꼼꼼하게 파악하기 시작함으로써 더 완성도 있는 서비스를 구현하고 싶다.

   (2) 구현한 API를 github의 wiki에 저장해두었다. 그런데 만약 api가 조금 바뀐다던가 응답 구조가 바뀔 경우, 이 wiki를 모두 수정해야한다는 단점이 있었다. 이후에 알아보니 스웨거라는 툴을 이용해서 자동으로 api 명세서를 만들어주는 툴이 있었다. 다음에는 이를 적용시키면 더 좋을 것 같다.

3. T

   (1) Github의 issue를 사용해보고 싶다 issue를 통해 feature 브랜치를 만들어서 관리하고 싶다. PR을 보내면 자동으로 이슈와 브랜치가 닫히는 기능을 추가하면 프로젝트 작업 관리에 더 도움이 될 것 같다.

   (2) Github에서 코드리뷰를 더 꼼꼼하게 하면 좋을 것 같다. 지금까지는 merge하기 전에 줌에서 간단히 자기가 구현하거나 수정한 부분을 화면 공유해서 보여주고, merge를 했다. 그런데, 이렇게 화면 공유로 빠르게 지나가는 것보다 github에서 코드를 꼼꼼히 보면서 코드리뷰를 하면 더 좋을 것 같다.

이전 프로젝트보다 더 체계적으로 진행한 것 같아서 좋다. 이 다음 3차 프로젝트에서도 이 회고를 바탕으로 더욱 체계적인 프로젝트를 만들고 싶다.

1. 프로젝트 전체 구조
2. 내가 맡은 역할
3. 새롭게 알게된 점
4. 보완할 점

1. 프로젝트 전체 구조

   - MVC 패턴 : 요구 사항에 맞게 MVC 패턴으로 분리했다. Java 프로젝트지만, Spring에서 처럼 도메인에 따라 controller, service, repository와 dto, domain 패키지를 두어서 분리함.

2. 내가 맡은 역할

   - 여행 입력 기능 구현 : 여행(여행지 이름, 시작 날짜, 끝 날짜)를 입력받고 저장하는 기능을 구현하는 역할. 사용자에게 입력받은 dto를 서비스에서 받고, repository에서 파일로 저장하는 흐름을 구현하는 것.

   - 객체를 JSON or CSV 파일로 저장하는 기능과 JSON or CSV 파일을 객체로 바꾸는 기능 구현 : jackson과 opencsv 라이브러리를 이용해서 구현.

3. 새롭게 알게된 점

   - builder 패턴 : 이전에는 알고만 있었고 직접 사용해본적은 없었는데, 이번 프로젝트 때 처음으로 적용해보았음. 유연성과 가독성을 확보할 수 있는 장점이 있음

4. 보완할 점

   - 첫 팀 프로젝트이다 보니, 어색하기도 하고 진행이 매끄럽지만은 않았던 것 같다. 그래도, 이제는 소통이 원할히 되는만큼 다음 프로젝트가 더 기대가 된다.

   - Git과 Github를 잘 알고 다룰줄 알아야 한다. 지금은 기본적인 명령만 쓰지만, 다음 프로젝트에서는 단 하나라도 다른 명령문을 써보자.

   - Github 커밋 메시지를 컨벤션에 따라 통일하는 것이 좋을 것 같다.

   - Java 코드 스타일 또한 컨벤션에 따라 통일하는 것이 좋을 것 같다.

한 주 동안 프로젝트하느라 고생 많았다!!!

프로젝트 구조를 세워 구현하자

프로젝트 구조를 세우고 구현하려 합니다

1. 구조

   - api : api(ex. kakao)를 핸들링하는 클래스를 모아놓은 패키지

   - config : api 및 DB 연결에 필요한 key를 모아놓은 패키지

   - constant : 프로그램에 필요한 상수를 모아놓은 패키지

   - domain : 서비스에 필요한 개체를 모아놓은 패키지

   - repository : DB 커넥션과 repository를 모아놓은 패키지

   - service : 핵심 비즈니스 로직 클래스를 모아놓은 패키지

   - view : 콘솔에 입력과 출력을 담당하는 클래스를 모아놓은 패키지

2. 구현

프로젝트 종료!!!

1차 프로젝트 후 멘토님께 코드 리뷰를 받았는데... 오버 엔지니어링이라는 소리를 들었다. 확정성있는 프로젝트를 만들고 싶어서 그랬지만, 다음 프로젝트부터는 조금 더 가볍게 만들어 봐야겠다.

과제의 핵심을 구현하자

이번 과제의 핵심은 Database 연동이라고 생각합니다. 본격적으로 과제 수행 전에 이를 확실히 파악하려고 합니다.

1. Database 연동

   (1) DB 커넥션 얻기

      - 드라이버매니저를 이용해서 DB url, username, password를 전달해서 connection을 얻는다

   (2) SQL 수행

      - connection에서 statement를 세팅해서 실행

   (3) 사용한 커넥션 닫기

프로젝트 핵심 기능 파악 완료!!!

시작이 반이다

이전 심화과제1 프로젝트와 동일하게 초기 세팅을 완료하면 절반은 완료했다고 생각합니다.

1. Github Repository에서 클론 후 프로젝트 열기

   - git clone <repository 주소>

   - IntelliJ에서 프로젝트 열기

   - git checkout -b <브랜치 이름> -> 브랜치 생성

2. JDK 세팅

   - JDK 17로 세팅

3. 프로젝트에 필요한 Library 다운로드

   - json, httpcomponents, mysql드라이버 라이브러리 다운로드

   - pom.xml에 다음과 같이 추가

4. commit

   - git commit convention에 맞춰서 작성

   - git commit -m "chore : JDK 및 Library 세팅 완료"

프로젝트 절반 완료!!!

프로젝트 구조를 세우자

프로젝트 큰 구조를 세우고 본격적인 구현에 들어가려 합니다.

1. 구조

   - 흐름 : 입력 -> 장소 찾기 -> 장소 출력 -> URL 띄우기

   - 도메인 : 사용자 입력 쿼리, 장소

   - 기타 : 예외처리

2. 흐름

   (1) 입출력 분리

      - 입력과 출력을 따로 처리하는 클래스를 만들고, 오로지 여기에서만 입출력이 진행됩니다.

      - 입력 -> 장소 찾기 -> 장소 출력 -> URL 띄우기

   (2) 장소 찾기 분리

      - 장소 찾기 흐름 : 키워드로 좌표 찾기 -> 좌표로 장소 찾기

      - 위 두가지 모두 Kakao API를 통해 얻어와야하므로, Kakao API 클래스로 분리

      - 이 후, Kakao API 모두 HTTP 통신을 거쳐야하므로, HTTP 통신만을 담당하는 Http 클래스 분리

      - 입력 -> 장소 찾기 -> 장소 출력 -> URL 띄우기

   (3) URL 띄우기

      - Desktop 클래스를 이용

      - 메서드로 분리해서 사용

3. 도메인

   (1) 사용자 쿼리

      - 필드 : 키워드, 반경(m)

   (2) 장소

      - 필드 : 상호명, 주소, 전화번호, URL ...

4. 예외처리

   - 각 예외 상황에 맞는 메시지를 같이 던지도록 구현

   - Message는 따로 constant로 분리

5. 구현

구현을 완료하여 프로젝트 종료!!!

단순히 구현뿐만 아니라, 구조에 대해서 고민하며 확장성 있는 프로젝트를 만들고 싶었다. 사소한 것까지 많이 고민하다보니 시간은 오래걸렸지만, 나중에 다 자산이 될 것이라고 생각한다.