카카오 테크 캠퍼스 3단계 3주차 회고

카카오 테크 캠퍼스 3단계 3주차 회고

벌써 일주일이 다 지나가고 있습니다 시간이 참 빠릅니다 어느새 가을도 찾아왔구요
처음으로 페어 프로그래밍도 하고, 본격적으로 개발 시작하기기 전 정책이나 프로젝트 세팅을 하는데 주로 시간을 보냈습니다

지식 공유 : Kako Tech Campus

이번주에는 GitHub Action CI 적용하는 방법과 Custom Instruction으로 Commit Convention을 지키는 방법을 공유했습니다

나름 1단계부터 꾸준히 꿀팁을 공유하는 이유는 정말 재밌습니다
제가 머무는 공동체가 성장하는데에 기여하는 느낌이랄까?

이렇게 꿀팁 하나씩 공유하는게 쌓이면 우리 카카오 쿠키즈들 간 긍정적인 자극을 일으킨다 믿습니다

마지막으로 스스로 선한 개발자가 되고 싶었기 때문입니다
이런 맥락에서 카카오의 세상을 선하게 바꾸는 노력을 합니다라는 문구가 와닿더라구요

제게 누군가에게 도움을 주고, 건강한 피드백을 받는 경험이 쌓인다면 충분히 그런 개발자가 될 수 있지 않을까요? 하핳

Gitihub Action CI 적용하는 방법 공유

Custom Instruction으로 코드 컨벤션 지키기

프로젝트 환경 세팅

먼저 프로젝트 기본 환경 셋업 끝냈고,린트 문제로 골치 아픈 일 없도록 Google Java Style로 코드 스타일 맞췄습니다

• Spring Boot 2.7.15와 Java 17을 사용하여 프로젝트의 기본 구조를 설정
• build.gradle 파일에 필요한 의존성과 설정을 추가

카카오 테크 캠퍼스의 경우, Weekly 브랜치에서 일주일 동안의 코드 모아서, develop 거쳐master로 올립니다
근데 이게 많은 사람이 접근하다보니 문제가 발생 할 수 있어 2가지 절차를 추가하였습니다

1. 코드 리뷰 필수
   • Weekly 브랜치로 PR 날릴 때는 코드 리뷰 하나씩은 꼭 받아야 머지 되게 정책 바꿨습니다
2. 자동 테스트
   • GitHub Actions 써서 Weekly 브랜치로 PR이 날라오면, Build Test가 실행 되도록하였습니다

절차 도입 후, 팀원들이랑 코드 리뷰 연습하는 시간도 가졌습니다

Github 코드 리뷰는 처음이라 Comment만 달면 Approve될 줄 착각해서 이슈가 있었지만 친절한 유선님이 알려주셔서 다행히 해결하였습니다

결론적으로, 프로젝트를 더 안정적이고 효율적으로 진행하기 위해 노력 중입니다! 🚀

Github Action CI 구성

Github Action에서 빌드가 실패할 경우 PR에 표시 되도록하였습니다
러프한 CI이지만, 최소한 빌드 되지 않는 프로젝트가 메인 브랜치에 합쳐지지 않도록하는 것을 목적으로 합니다

• GitHub Actions를 사용하여 Continuous Integration (CI) 워크플로우를 구성했습니다.
• weekly 브랜치로 Pull Request가 생성될 때마다 CI가 실행됩니다.
• JDK 17을 사용하고, Gradle 의존성을 캐시하여 빌드 속도를 향상시켰습니다.
• 프로젝트 빌드가 실패하면 워크플로우가 중단되고 알림이 발송됩니다.

.gitignore && Code Style - .editorconfig 추가

.gitignore 파일을 설정하여 불필요한 파일과 폴더가 Git에 포함되지 않도록 했습니다

.editorconfig 파일을 추가하여 코드 스타일을 일관되게 관리합니다.

.editorconfig를 프로젝트 루트에 위치시키면 IntelliJ IDEA는 이 설정에 따라 코드 스타일을 자동으로 적용합니다
이 설정은 IDE에서 자동으로 적용되므로, 팀원 간의 코드 스타일 차이를 최소화합니다.

페어 프로그래밍 with Sonny

Sonny에게 연락이 와서 페어 프로그래밍 하자 제안을 받아 오후 5시부터 12시까지 낭만 가득한 페어를 했습니다
이전에 페어 프로그래밍? 비스무리한 것을 했는데 원활히 되지 않아 아쉬웠던 부분을 어떻게 해결 할지도 배우는 시간이었습니다

그리구, 친구와 함께하는 코딩하는 낭만, 최고,

클린 아키텍처란 무엇일까

전 지금까지 일반적인 Controller - Service - Repository - Entity 등의 계층형 구조로 개발해왔습니다
하지만, 이번 프로젝트에서는 클린 아키텍처의 개념을 녹여보고 싶었습니다

왜냐하면, 관심사의 분리 및 테스트에 대한 요구가 커지고 있는 지금, 클린 아키텍처는 기존에 제가 경험했던 아키텍처에서 이러한 요구사항에 대응 할 실력을 함양 시킬거라 생각했기 때문입니다

Sonny의 경우, 이전 프로젝트에서 “핸들러” 개념을 도입해서 클린 아키텍처에 도전했었습니다
즉 컨트롤러 - 핸들러 - 서비스 1+ 서비스 2 형태로, 서비스 간에 의존 관계가 생길 경우 핸들러를 만드는 것이었죠

하지만, 이 경우에 핸들러 또한 과다하게 의존 관계를 가질 수 있게 됩니다

Sonny와 대화하며 여러 글들을 읽은 결과는 아래와 같습니다

나름 클린 아키텍처 이해

예를 들어, 엔티티가 쪼개야하는 상황을 떠올려봅시다

우리 서비스가 너무나 성공했고, 기존의 User 테이블을 분리해서 User와 User Login으로 분리하는게 좋겠다 판단을 했습니다

보수적으로 생각한다면, 기존의 레이어드 아키텍처에서는 왠지 엔티티-서비스가 1:1 매칭이 되어야 하니까, UserLogin을 위한 서비스와 entity를 만들고 폴더도 나눠야 합니다

핵심은 서비스 계층에서 접근해야 하는 Entity가 분리 되었고, 개발자는 이 부분을 고려하며 유지보수에 돌입해야 합니다

이 때, 엔티티와 서비스 사이에 어댑터(Usecase)가 있다면 상황이 달라집니다
불쌍한 백엔드 개발자는 수정해야하는 범위가 줄어듭니다.
원래 있던 어댑터에서 쪼개진 엔티티에서 각자 데이터를 가져오도록 수정하면 되기 때문입니다
서비스 계층은 대신 수정할 필요가 없어지겠죠! 유지보수의 난이도가 낮아지는 것입니다

또한, 반대로 서비스의 구현도 자유로워지는 것이죠

최종적으로 어떻게 했는가

Entity - Repository - Usecase - Service - Controller 구조와 어댑터를 사용합니다
이 때 Service 계층은 트랜잭션 등을 관리하고, Usecase가 좀 더 잘게 쪼개진 기존의 Service 역할을 수행하게 됩니다

폴더 구조도 이를 위해, Inner와 Outer로 변경하였습니다
굳이 폴더까지 2개로 나눈 이유는 해당 아키텍처를 처음 접하는 저나 팀원들이 개발을 함에 있어 계층이 어떻게 분리 되어 있는지 명시적으로 알기 위함입니다

아래는 Usecase인데, 실제 Service에서 가져가서 사용 할 때는 excute만 사용하면 됩니다

브랜치 전략 선정

브랜치 전략의 경우, weekly에만 팀원들이 접근하고, 흐름상 develop과 master에는 접근하지 않음을 고려했습니다
브랜치 네이밍을 #[Issue 번호]/기능로 가져가는 이유는 기능 개발상 Issue 작성을 잊지 않고, 명확하게 진행 상황을 확인하고 싶었기 때문입니다

전략 개요

• 브랜치 전략은 주로 개발자들이 weekly 브랜치까지만 접근하며, 그 이상의 레벨은 테크리더나 프로젝트 오너가 처리합니다.
• weekly 브랜치에서의 머지는 코드 리뷰가 완료되어야 가능하며, CI (Continuous Integration) 프로세스가 연결되어 있습니다.

브랜치 네이밍 규칙

• 브랜치는 #[Issue 번호]/기능의 형태로 생성합니다.
  • 예: #32/featImageUpload

브랜치 작업 플로우

1. 브랜치 생성: 위의 브랜치 네이밍 규칙에 따라 새 브랜치를 생성합니다.
2. 기능 구현: 생성한 브랜치에서 기능을 구현합니다.
3. 코드 리뷰: 구현이 완료되면 weekly 브랜치로 Pull Request (PR)을 생성합니다. 코드 리뷰가 필수입니다.
4. 머지 및 브랜치 삭제: 코드 리뷰가 완료되고 문제가 없다면 weekly 브랜치에 머지합니다. 머지 후에는 작업 브랜치를 삭제합니다.

반복

• 위의 플로우를 필요한 만큼 반복하여 프로젝트를 진행합니다.

기획안 고도화 : 설문 조사

🐥 카카오테크캠퍼스 3단계 3주차는 기획안 고도화 주간입니다
저희 서비스의 페르소나 검증 및 서비스의 필요 분석을 위해서 설문 조사를 하였습니다

설문 조사를 하면서 느꼈던 것은 생각보다 어렵다입니다
서비스에 대한 이해와 유효한 질문을 얻기 위해 질문을 수정한다던가, 말의 어감을 다듬는다던가
개발 그 자체를 할 때 느끼지 못했던 어려움들이었습니다

폼 유입은 지인들에게 공유하거나, 각자의 인스타 스토리를 통해 공유하였습니다
특강에서 배운 엄지 존이나 UI/UX도 슬쩍 고려해서 배치했습니다!

마치며,

처음 페어프로그래밍도 해보고, 컨벤션이나 프로젝트 준비를 하면서 전반적인 서비스 개발에 대해 고민하는 시간이었습니다

카카오 테크 캠퍼스의 목적도 서비스 개발 경험과 협업 능력인거 같구요!

또한, 제 부족함을 많이 느꼈습니다. 페어 프로그래밍을 하며 얻은 점은 갈 길이 멀다 입니다
프레임워크와 언어에 대한 이해가 부족하다 싶었습니다

언능 강해져서 감자를 탈출해야겠습니다