코드메모장

1. 문제

• Layered Architecture + Clean Architecture를 잘 지키면서 개발을 하고 있는지..?

• Facade 패턴을 활용

2. 시도

• 아키텍처 관련 매니저님께 문의

• 다른 팀원과 각자 개발한 아키텍처 구조 설명 및 논의

• 구글링

3. 해결 / 알게된 것

• 아키텍처도 어느정도 기준은 있지만 명확한 정답이 없으며 각 클래스의 역할에 대한 관점을 어떻게 보냐에따라 다르게 생각할 수 있다고 판단되었습니다.

• 내가 활용한 Facade패턴

  1) domain에 있는 Respoitory를 참고하는 Service를 만들고, 해당 Service에서 비지니스 로직을 전부 구현

  2) 다른 서비스를 참고해야 하는 경우 Facade를 만든 후 해당 Facade에서는 각 서비스의 로직을 호출만 하여 원하는결과를 출력할 수 있도록 구현

  3) Controller는 Service를 모르며, Facade만을 호출할 수 있도록 구현

Keep : 현재 만족하고 계속 유지할 부분

1. TDD

2. 아키텍처 구조

Problem : 개선이 필요하다고 생각하는 문제점

• 이번에도 과제 제출 전날인 목요일날 밤샘작업을 진행했다.... 뭐든 미리미리 하는것이 중요한데, 분발하여 미리끝낼 수 있도록 해보자!

• 내가 생각했던 범위보다 과제의 양이 많았다. 그래도 일정에 맞춰 작업물을 제출할 수 있어서 다행이지만.. 개선이 필요하다!

Try : 문제점을 해결하기 위해 시도해야 할 것

• 상대적으로 안정적인 월 ~ 수 시간을 많이 활용하여 작업을 진행하자!

1. 문제 (과제, 프로젝트를 진행하면서 부딪혔던 기술적인 문제)

• 시퀀스 다이어그램 작성하는것에 익숙하지 않은 문제점이 있었습니다.
• Mock API 작성을 실제로 해본 경험이 없어 어떻게 작성을 해야하는지 학습이 필요했습니다.

2. 시도

• 시퀀스 다이어그램 학습
  • 구글링 및 Chat GPT를 통해 다른 서비스에 대해 어떤식으로 시퀀스 다이어그램을 작성하는지 학습 및 작성
  • 개인적으로 시퀀스 다이어그램 작성 및 조원분들과 공유 하여 서로에게 피드백 진행
• Mock API 학습
  • 구글링을 통해 Mock API 작성방법에 대한 학습 및 작성

3. 해결

• 시퀀스 다이어그램
  • API 별로 나누어 각각의 시퀀스 다이어그램을 작성하니 정리도 편하고 보기에도 깔끔하게 잘 작성되었습니다.
• Mock API
  • API 명세와 MockAPI를 한번에 처리하기 위해 Swagger를 사용하였습니다. (오히려 독이 되어.. Fail로 돌아옴 ㅜㅜ)

4. 알게된 것

• 시퀀스 다이어그램을 작성할때 DB, Service와 같이 상세하게 처리하게 되면 오히려, 개발하는데 있어 제한을 두게될 수 있으므로 추상적으로 작성하는것이 좋다.
• MockAPI를 만들때는 실패 케이스는 처리하지 않아도 된다(?). 라고 김종협 코치님께 피드백을 받았습니다.

Keep : 현재 만족하고 계속 유지할 부분

• 팀원들과 소통을 통해 각자의 과제 진행상태에 대한 피드백을 진행하는것을 계속 유지하면 좋을듯 합니다.

Problem : 개선이 필요하다고 생각하는 문제점

• 이번주차가 설계 주차이기에, 긴장감이 조금 풀어졌던것 같습니다. (노력해야지....)
• 더 하려고 하지 말고, 기본을 잘 지키며 과제를 진행하자! (다음주차에 swagger 적용이 있는지 모르고... 미리 작성을 해버림...)

Try : 문제점을 해결하기 위해 시도해야 할 것

• 10주차 중 이제 3주차가 지났으며, 마지막까지 긴장을 하며 열심히 달리겠습니다!!

1. 문제 (과제, 프로젝트를 진행하면서 부딪혔던 기술적인문제)

• 동시성 이슈를 해결하기 위해 DB Lock을 공부가 필요했습니다.
• 동시성 이슈 테스트과정에서, Thread와 DB connection pool의 관계로 인하여 문제가 발생하였습니다.

2. 시도

• DB Lock에 대한 학습을 진행하였습니다.
  • 구글링, Chat GPT를 통해 낙관적 락, 비관적 락 에 대해 차이점을 공부 하여 어떤 Lock을 적용해야할지 고민하였습니다.
• Spring Boot 설정값을 변경하였습니다.

3. 해결

• 데이터 충돌이 많이 발생할 것으로 예상되어 데이터를 읽는 시점부터 Lock이 되는 비관적 락을 선택하였으며, 코드로 적용하는것은 생각보다 간단했습니다.
  • 비관적락 - @Lock(LockModeType.PERSSIMISTIC_WRITE)
• Spring Boot 설정시 hikair 설정을 변경하여 connection pool의 크기를 늘렸으며, 해당 크기에 맞게 Thread의 개수 제한도 설정하였습니다.
• 동시성 테스트 코드에서 Semaphore 를 사용하여 전체 Thread가 50개를 실행할 예정이어도 10개씩 나누어서 동작할 수 있도록 처리하였습니다.
  • ex) 50개 실행 → 10개만 우선 동작 → 1개 완료 → 남은 40개의 스레드 중 1개 동작 → …. → 50개 완료

4. 알게된 것

• DB Lock을 어떤 기준으로 선택해야하는지 알게되었습니다.
• 웹서버의 Thread수와 DB connection pool에 대한 설정을 서비스에 맞게 설정해주어야 사이드이펙트를 피할 수 있다는것을 깨달았습니다.

5. 지난 목표 회고

• TDD를 작성하며 개발하는것이 목표였으며, 잘 이루어지고 있어 뿌듯합니다.

6. 다음 목표 설정

• 이전 목표들은 유지하면서 다음 목표는 내가 학습한 내용들에 대한 문서화를 열심히 진행하고 싶습니다.

1. 문제 (과제, 프로젝트를 진행하면서 부딪혔던 기술적인문제)

• 테스트 코드 작성은 익숙한 상태이나, TDD 방법론에 맞게 개발을 진행한 경험이 없어 초반에 어려움을 겪었습니다.
• 코틀린 코드에 아직 익숙하지 않아 코틀린스러운 코드를 작성하는데 어려움을 겪었습니다.

2. 시도

• 항해99 플러스에서 제공한 open Q&A를 참여하였습니다.
• Git Commit을 최대한 분리하여 작성하면서 TDD 방법론에 맞도록 구현 시도 했습니다.
• 스파르타 코딩클럽에서 제공해준 코틀린강의를 우선적으로 학습하였습니다.

3. 해결

• 코틀린 코드를 작성하기 위해 ChatGPT를 사용하며 우선적으로 문제를 해결하였습니다.

4. 알게된 것

• EndToEnd 테스트, 통합 테스트, 유닛 테스트의 차이점
  • EtoE 테스트
    • 사용자가 요청을 보내고 응답을 받는 전체적인 테스트 (api 테스트)
  • 통합 테스트
    • 하나의 컴포넌트가 다른 하나 이상의 컴포넌트를 참조 및 호출하여 정상적으로 동작하는지에 대한 테스트
  • 유닛 테스트
    • 하나의 컴포넌트가 다른 컴포넌트를 참조하지 않고 가짜 객체(Mock or Stub)를 활용하여 정상적으로 동작하는지에 대한 테스트
• Test Double 개념에 대한 이해
  • 테스트를 진행하기 어려운 경우 이를 대신해 테스트를 진행할 수 있도록 만들어주는 객체
    • Dummy: 아무 기능도 하지 않는 객체로, 보통 메서드 호출이 필요하지만 실제로 그 결과가 테스트에 중요하지 않은 경우에 사용됩니다.
    • Fake: 실제 동작을 흉내내는 객체로, 보통 간단한 구현을 통해 실제 객체를 대체합니다. 예를 들어, 인메모리 데이터베이스를 사용할 수 있습니다.
    • Stub: 사전 정의된 응답을 반환하는 객체로, 특정 메서드 호출에 대해 고정된 결과를 제공하여 테스트의 예측성을 높입니다.
    • Spy: 호출된 메서드와 전달된 인자를 기록하는 객체로, 호출 여부나 호출된 횟수 등을 검증하는 데 사용됩니다.
    • Mock: 사전 정의된 기대값과 행동을 갖는 객체로, 특정 메서드 호출이 특정 조건을 만족하는지 검증하고, 그에 따라 예외를 던지거나 다른 동작을 수행할 수 있습니다.

Keep : 현재 만족하고 계속 유지할 부분

• 프로젝트를 진행하면서 앞으로 TDD 방법론을 지키면서 작업을 진행 할 예정입니다.
  • 테스트 코드를 작성함으로써 각 함수들의 기능이 정상적으로 잘 돌아가고있다는 확신이 들며 편안하게 리펙토링을 할 수 있어 좋았습니다.

Problem : 개선이 필요하다고 생각하는 문제점

• 개발을 들어가기 이전 테스트 테스트 케이스들을 먼저 작성 후 작업을 진행해야 하지만, 그렇게 진행하지 못한부분이 조금 아쉽고 개선해야하는 점으로 생각합니다.

Try : 문제점을 해결하기 위해 시도해야 할 것

• 개발을 진행하기 이전에 어떻게 작업을 진행할지 노션 혹은 다른 문서에 작성을 우선적으로 진행하도록 시도해 볼 예정입니다.

과제 제출 링크

• https://github.com/Loafly/hhp_week_01

항해 플러스 참여 계기

23년 12월 회사를 그만둔 후 외주 작업 및 처음 코딩을 배우는 사람들에게 도움을 주며(기술매니저 및 강의 진행) 나름 자기계발을 진행하면서 생활을 하고 있었습니다. 하지만 이러한 생활이 생각보다 점점 길어짐에 따라 현업자가 아닌 기간이 증가로 인한 이직에 대한 걱정과 기술적으로 빠르게 변화되어지고 있지만 나는 현재 멈춰있다는 생각이 들었으며 이대로 유지하면 안된다는 생각으로 변화를 주기 위한 마음을 가지고 항해 플러스를 참여하였습니다.

10주간의 목표

• 내가 원하는 회사 들어갈 수 있는 실력 만들기 및 이직 성공하기
• 사소한 것들이더라도 기술블로그 작성하기
• 과제 100% 통과 하기
• 10주가 지나도 후회하지 않도록 시간 투자하기

최종 목표 배지

당연히 최종 목표 배지는 블랙 배지입니다. 현재 쉬는상태이기때문에 다른 분들보다 시간적으로 여유가 있으며 더욱 집중할 수 있는 시간이 많기에 과제를 통과하지 못하는 경우는 있어서는 안되며 100% 과제를 통과하는것을 목표로 진행할 것 입니다.

(1) WIL(Weekly I Learned) - 14마지막 주차

• 모든 일정을 끝내고 이력서, 포트폴리오, 자기소개서를 작성하는 주차가 되었습니다.
• 기본적인 포맷은 주어지며 항해99를 하면서 또는 개인적인 경력을 개개인이 작성하는 방식으로 진행됩니다.

(2) 일정

• 5/29 ~ 6/4 - 이력서, 포트폴리오 작성 및 모의면접 자기소개서 작성
• 6/3 ~ 4 - 협력사(일부) 모의면접 
• 6/4 18:00 - 항해99 수료식
• 6/5 제출마감, 6/7 ~ 6/9 오후 예정 - 이력서/포트폴리오/자소서 리뷰(제출인원 한에서 3개씩 뽑아 전체적인 피드백 할 예정)
• 6/9 19:00 ~ 20:00 - 김병욱 멘토님 취업꿀팀 특강
• 6/9 - 모의면접 서면 피드백 공유
• 6/14 18:00 까지 - 3차 협력사 라인 지원
• 6/21 18:00 까지 - 2차 협력사 라인 지원
• 6/28 18:00 까지 - 1차 협력사 라인 지원

(3) 수료증 및 상장

(4) 느낀점

• 모의면접을 한번 경험함으로써 '아직 부족한 점이 많구나'라는 것을 깨달았습니다. 지금까지 프로젝트를 진행하면서 만드는것에는 익숙해져 있지만, 이론적으로 어떻게 돌아가는지에대해 공부해야할 필요성을 느꼇으며 항해99가 끝나더라도 열심히하는 항해99 멤버들과 이어서 공부를 하기로 하였습니다.
• 수료식 당일 항해99 크루원 분들의 투표를 통해 여러 분야의 상장받을 분들이 선정되었습니다. 그중에 하나의 상을 받아 지금까지 열심히 했구나 느낄수 있어 좋았고 알아주신분들이 있다니 너무 감사드립니다.
• 이력서, 포트폴리오, 자기소개서도 중요하지만 코딩테스트, 기술면접도 매우 중요하기에 앞으로 원하는 곳을 위해 열심히 노력하겠습니다.

(1) WIL(Weekly I Learned) - 13주차

• 이전 9주차 ~ 13주차 까지는 최종 프로젝트를 이어 진행합니다.
• 프론트(React) 3분 백엔드(Spring) 3분 디자이너 1분으로 최종 프로젝트를 진행합니다.
• MVP가 완성되어 배포 후 유저 피드백을 받고 유지보수를 하고있습니다.

(2) 일정

• 5/25 4조(10:45 ~ 11:00) - 1차 리허설 
• 5/26 19:00 ~ 20:00 - 핵클 협력사 발표
• 5/26 20:00 ~ 21:00 - 이큐브랩 협력사 발표
• 5/28 14:00 ~ 14:30 - 자가리허설
• 5/28 15:00 ~ 17:00 - 협력사 초청 발표회

(3) 배운점

• 최종 프로젝트 유지보수(크롤링 수정)
• Traivs CI(개인공부)
• AWS CodeDeploy(개인공부)

(4) 최종 프로젝트

• 주제 - 퇴근하고 뭐하지?
  • 퇴근 후 취미를 찾을 수 있는 사이트 들을 한번에 보고 필터처리 할 수 있도록 도와주는 사이트입니다.
• 사이트
  • 퇴근하고 뭐하지 - https://afterwork.co.kr/
• Git
  • 프론트 엔드 - github.com/greedysiru/gaemangtalk_frontend
  • 백엔드 - github.com/seongbinko/afterwork
  • 백엔드 크롤링 - github.com/seongbinko/afterwork-scheduler
• 영상
  • 중간점검 시연 영상 - https://www.youtube.com/watch?v=WeymerrTyMw
  • 시연 최종 영상 - https://www.youtube.com/watch?v=pW9s6w0tXzg

(5) 느낀점

• 드디어 최종 프로젝트까지 잘 마무리되었습니다. 여러 피드백이 있었고, 크롤링 대상인 사이트 UI가 바뀌는 등 생각지도 못한 부분에서 코드 수정이 필요하여 당황하였습니다. 그래도 처음 크롤링을 만들때 처럼 하나하나 로그를 찍어가며 문제 없이 수정하여 이런게 유지보수인가? 라는 생각이 들었습니다.
• 개발자 6명, 디자이너 1명을 이루어져 앞으로 경험하기 힘든 너무 값진 경험이였고, 좋게 마무리가 되어 안심이되었습니다.
• 다음주엔 협력사들과의 모의면접 및 이력서 제출만 남았습니다. 마지막 주차인만큼 더 열심히 하여 마무리를 열심히하겠습니다.

(1) WIL(Weekly I Learned) - 12주차

• 이전 9주차 ~ 13주차 까지는 최종 프로젝트를 이어 진행합니다.
• 프론트(React) 3분 백엔드(Spring) 3분 디자이너 1분으로 최종 프로젝트를 진행합니다.
• MVP가 완성되어 배포 후 유저 피드백을 받고 유지보수를 하고있습니다.

(2) 일정

• 5/13 자정까지 - 팀 별 중간 결과물 제출
• 5/15 18:00 ~ 19:00 - 마케팅 특강
• 5/19 19:00 ~ 20:00 - 데이터라이즈 협력사 발표
• 5/19 20:00 ~ 21:00 - 스토리시티 협력사 발표
• 5/21 - 팀별 면담
• 5/26 - 1차 모의발표
• 5/27 - 2차 모의발표 및 녹화

(3) 배운점

• SonarLint 정적 분석도구 사용법
• jacoco(java code coverage tools) 사용법
• 쓰레드 관리
  • ExecutorService
  • Executors
  • Future
  • Runnable

(4) 최종 프로젝트

• 주제 - 퇴근하고 뭐하지?
  • 퇴근 후 취미를 찾을 수 있는 사이트 들을 한번에 보고 필터처리 할 수 있도록 도와주는 사이트입니다.
• 사이트
  • 퇴근하고 뭐하지 - https://afterwork.co.kr/
• Git
  • 프론트 엔드 - github.com/greedysiru/gaemangtalk_frontend
  • 백엔드 - github.com/seongbinko/afterwork
  • 백엔드 크롤링 - github.com/seongbinko/afterwork-scheduler
• 영상
  • 중간점검 시연 영상 - https://www.youtube.com/watch?v=WeymerrTyMw

(5) 느낀점

• 피드백을 받으면서 사람마다 보는 눈, 원하는 느낌이 많이 다르다는 것을 느꼇습니다.
• 마케팅을 하면서 유저개입이 어렵게 되는것을 많이 느꼇으며 유저들이 들어오더라도 설문참여율이 엄청나게 저조한것을 보고 서비스를 운영하는것이 힘든거구나 다시한번 깨달았습니다.
• SonarLint를 사용하면서 내 코드내에서 불필요한 부분을 많이 알 수 있어 코드를 개선할 수 있어 좋았습니다.
• 매일 크롤링을 돌리는 시간이 100분 정도의 소요되었습니다. 스파르타 코딩클럽 대표님께서 스레드를 사용하여 시간개선을 할 수 있다고 알려주셔서 사용한 결과 20분내에 크롤링이 끝나 놀라운 결과를 얻을 수 있어 만족스러웠습니다.

(1) WIL(Weekly I Learned) - 11주차

• 이전 9주차 ~ 13주차 까지는 최종 프로젝트를 이어 진행합니다.
• 프론트(React) 3분 백엔드(Spring) 3분 디자이너 1분으로 최종 프로젝트를 진행합니다.

(2) 일정

• 5/13 자정까지 - 팀 별 중간 결과물 제출
• 5/15 18:00 ~ 19:00 - 마케팅 특장
• 5/27 자정까지 - 팀 별 최종 결과물 제출

(3) 배운점

• NginX 사용한 무중단 배포 (개인 공부)
• SNS마케팅 방법

(4) 최종 프로젝트

• 주제 - 퇴근하고 뭐하지?
  • 퇴근 후 취미를 찾을 수 있는 사이트 들을 한번에 보고 필터처리 할 수 있도록 도와주는 사이트입니다.
• 사이트
  • 퇴근하고 뭐하지 - https://afterwork.co.kr/
• Git
  • 프론트 엔드 - github.com/greedysiru/gaemangtalk_frontend
  • 백엔드 - github.com/seongbinko/afterwork
  • 백엔드 크롤링 - github.com/seongbinko/afterwork-scheduler
• 영상
  • 중간점검 시연 영상 - https://www.youtube.com/watch?v=WeymerrTyMw

(5) 느낀점

• 11주차 중간점검 MVP가 나왔습니다. 지인, SNS 등을 통하여 홍보를 하며 생각지도 못햇던 오류, 불편사항 등을 피드백 받아 유지보수 및 기능 개선을 할 예정입니다.
• 좋은 팀원들을 만나 저번주차에서 예상했던 대로 실제 서비스를 배포하여 만족스러웠습니다.
• 많은 조에서 MVP단계를 진행 중이여서 항해99에서 마케팅 홍보하는 강의를 해주셨는데 몰랐던 접근을 어떻게 해야하는지 예시까지 들어가며 설명 해 주셔서 이해도 잘 되고 도움이 많이 됬습니다.

(1) WIL(Weekly I Learned) - 9~10주차

• 4/23일 드디어 기다리던 마지막 주차인 최종 프로젝트가 시작되었습니다.
• 팀은 총 7인 백엔드(Spring) 3분(저 포함), 프론트엔드(React) 3분으로 구성되었으며 최종프로젝트 인 만큼 디자이너 1분도 포함되어 프로젝트를 진행하였습니다.

(2) 일정

• 4/25 - S.A 제출
• 4/26 12:00 ~ 17:00 - 팀 별 시작 면담
• 4/30 10:00 ~ 15:00 - 팀 별 1차 면담
• 5/5 19:00 ~ 20:00 - 미소 협력사 발표
• 5/8 17:30 ~ 18:30 - 미니프로젝트 코드기반 코드리뷰 (이태훈 튜터님)
• 5/13 자정까지 - 팀 별 중간 결과물 제출
• 5/27 자정까지 - 팀 별 최종 결과물 제출

(3) 배운점

• WebDriver를 이용한 크롤링
• JPA와 Pageable을 이용한 페이징 처리
• nativeQuery
• JPQL
• Junit5 TestCode 작성
• @Scheduler

(4) 최종 프로젝트

• 주제 - 퇴근하고 뭐하지?
  • 퇴근 후 취미를 찾을 수 있는 사이트 들을 한번에 보고 필터처리 할 수 있도록 도와주는 사이트입니다.
• Git
  • 프론트 엔드 - github.com/greedysiru/gaemangtalk_frontend
  • 백엔드 - github.com/seongbinko/afterwork
  • 백엔드 크롤링 - github.com/seongbinko/afterwork-scheduler

(5) 느낀점

• 최근 항해99에서 만난 사람들과 오프라인에서 만났다. 다들 시간이 없어 일요일에 약속을 잡아 오랜만에 회고록을 쓰게 되었습니다... 반성하는 시간이 되네요.
• 최종 프로젝트는 미니 프로젝트가 끝나기 전에 얘기를 맞췄던 분들과 팀이 구성이 되었고 거기에 더해 프론트 한분, 백엔드 한분이 추가되어 팀이 결정 되었습니다.(디자이너분은 팀 결정과 함께 스파르타에서 연결 시켜주셨습니다.)
• 최종프로젝트가 진행되면서 이전에 신경쓰지 않았던 보안부분에 대해 http -> https로 변경하는 등 많은 신경을 쓰게 되었습니다. 또한 무중단 배포를 통하여 서비스가 끊기지 않고 업데이트를 할 수 있도록 설계를 하였습니다. 어려운 기능보다는 사용자 경험, 완벽한 기능을 만드는 것에 초점을 두고 만들어 이전 프로젝트에 비해 적은 스코프를 가지고 만들었지만 시간은 더 들었습니다.
• 다음주가 되면 실제 서비스를 배포할 가능성이 높아 많은 기대를 하고있습니다.