22.09월 1번째 WIL 실전프로젝트 1주차 회고 (기획과 도전..?)

 

 😓이번주의 고민들 

1) 아키텍쳐 패턴 고민(개발 시간 단축, 품질 향상, 검증 편리, 소통 원활, 이해 용이, 예측 가능을 위해)

결과 부터 말을 들이자면 Layered Architecture을 사용하기로 결정하였습니다.

 

- 쉬운테스트 구조를 가지자( 단위 및 유닛 테스트를 통해 확실한 코드 구현을 위해)

- 러닝커브가 짧은 프로젝트인만큼 논리가 복잡하지 않은 패턴을 선택하자(코드 품질 올리기위해서)

우선 저희가 추구하는 바는 위와 같은 사항들이 있었기 때문입니다.

 

그리고 그에 가장 적합한 아키텍쳐 패턴이 Layered Architecture이라 생각하였습니다.

 

다만, Layered Architecture에 대해 파악해 본결과 아래와 같은 단점이있다는 것을 알게되었습니다.

개발코스트가 증가하게된다.

 

하지만,  개발코스트가 위 장점을 엎을 만큼 중요하지않다 판단하였고

또한 저희 프로젝트 범위 내에서는 개발 스코프가 크지 않은 서비스인만큼 큰 단점으로 다가오지 않았습니다.

그러하여 Layered Architecture 패턴을 사용하기로 결정하게 되었습니다.

 

 

부연설명사항(Layered Architecture장점/단점)

• -Layered Architecture장점
  • 각 계층은 어플리케이션 내에서의 특정 역할과 관심사(화면 표시, 비즈니스 로직 수행, DB 작업 등)별로 구분된다.
  •  '관심사의 분리 (Separation of Concern)' 
  • 특정 계층의 구성요소는 해당 계층에 관련된 기능만 수행한다.
  • 이런 특징은 높은 유지보수성과 쉬운 테스트라는 장점이 존재한다.
  • 비즈니스 논리가 복잡하지 않다. 그렇기에 잘못 적용할경우가 내려가 적절한 코드 품질을 챙길수있다.
• -Layered Architecture단점
  • 개발코스트가 증가하게된다.

2) 이메일  인증 방식 DB 처리법에 대한 고민(redis사용여부)

이메일 인증번호에 대한  key value 값을 보관하고 처리하기위해서 DB를 사용하을 해야했는데

임시적인 데이터인 만큼 굳이 mysql에 저장을 하고 보관을 해야 하나 고민을 했었습니다.

 

그 고민을 하던중 redis라는 데이터 스토어를  알게되었고 쓰이는 곳에 대해 파악을 해보았습니다.

 

사용하면 좋을곳

-운영중인 웹사이트에서  key value 데이터 타입을 처리 해야하고

-I/O가 빈번히 발생하여 다른 저장 방식 사용시 효율이 떨어지는곳

-사용자의 세션 관리

-API 캐싱

 

물론  key value 데이터 타입을 처리하는것은 맞지만 단순히 이 이유 1가지 때문에

redis를 억지로 사용하는건 오버스펙이라 판단하였습니다.

 

그러하여 2차 대안으로 DB에 저장하데 임시적인 데이터인 만큼 자동으로 데이터 관리를

해줄수있는 방안을 고려해보기로 하였고  현재 까지 고민에서 진행된 사항은 아래와같습니다.

 

1)nosql에서  ttl 을 사용하거나  

2)mysql event_scheduler을 이용하거나 

 

아직 결정이 나지 않았고 좀더 자세한 공부를 한 후에 위 기능중 어떤 것이 현 프로젝트와

우리의 기준에 맞는지 판단하여 진행 할 예정입니다.

 

 

🧑🏻‍💻지난주 배운 것들,  한 것들그리고  깨달은 것들

• 실전프로젝트 기획 1차안 부정적 피드백(기술적 +서비스적 아쉬운)으로 2차 기획진행후 승인 후 프로젝트 돌입
  • 깨달은점:어떠한 기술을 사용하여 어떠한 서비스를 구현할 것이며 과연  이 서비스가 필요할까등??? 이러한 각각에 요소에 대해 고민이 끝없이 생기고 이를 계획을 한다는 것이 어렵다고 느꼈음)
• service레이어 단에서 sequlize query보다 SQL 사용
  • 이유:sequlize query사용 하고 있는데 DB를 읽고 쓰고 수정하는데 불편함을 느껴 SQL언어 공부 후 일부적용
  • SQL을 사용함으로써 느낀점 명령어가 상당히 직관적이어서 배움에 재미를 느꼈음(명확한 명렁어가 좋음을 느꼈음)
• 카카오 소셜 로그인 구현 성공
  • 깨달은점:실질적으로 적용함을써 outh개념에 대해 좀더 잘 이해 할 수있었음 + passport 미들웨어 공부까지 진행
• 실전프로젝트에 들어가는 기본적인 기능들 구현 완료(팔로우/팔로워/ 로그인부분/Todo관련 등)
• 더 나은 좋은 서비스를 만들기 위해서는 통일성이 필요하기에 코드컨벤션, gitflow등 많은것들을 고민하고 결정
  • 깨달은점:아직 코드가 많이 진행되지 않아 같은 팀원의 코드를 보면서도 나도 바로 이해가 잘되는과정을 진행해봐야 겠다 생각함
• API 명세서 부분에서 프론트와 의 협업에 상충된 이해로 개발에 어려움을 느꼈고 설계가 뒤틀렸음
  • 깨달은점:협업할때는 각자의 의견을 구체적이고 명확하게 전달해야함 이를 위한 도구나 수단에 대해서도 고민을 해봐야한다 느꼈음 swagger 공부해봐야겠다 생각함

 

⭐️이번 주 이루고 싶은 것들

• morgan + winston으로 로깅 환경 조성(더나은 서버관리를 위해)
• input data 관리를 위해 joi 공부 후 적용
• 웹푸쉬 기능 실시간 채팅기능 구현에 대해 공부 후 프로젝트 적용
• CI/CD를 위해 젠킨스 혹은 git action에 대해 파악해보고 1가지 선정후 프로젝트에 도입
• 클린코드를 위해 리펙토리 진(가독성에 중심을!!)
• 프리티어+ESlint 적용

---

📅주간 회고

실전 프로젝트 1주차는 정말 그냥 기획의 지옥이었다. 항상 주어진 틀안에서만 서비스들을 구현을 해왔는데, 

우리가 처음 부터 모든것을 다하려고 하니 이게 생각보다 쉬운것이 아님을 느꼈다.

 

사실 처음에는 그냥 하고 싶은 기능들에 대해 공부 하고 그냥 적용해보면 끝이 아닐까 뭐 크게 문제 있겠냐고 생각하였다.

하지만 어떤 기술로 어떤 서비스를 만들것이며 그것을 3주라는 시간안에 우리가 해낼수 있을 까라는 스코프도 정해야 하니,

정말 고려할 사항도 많았다. 무엇보다도 결국 어떤것이 올바른 것인지 감을 잡기가 매우 어려웠다.

 

위에 과정에서 수많은 의사소통을 통해결국 우리가 진행될 프로젝트가 결정되어졌다.

 

MBTI가 유행하고 있는 지금 어느정도 이 결과값이 사람을 조금은 대변하며 각자의 삶을 보여준다 생각했다.

그러하여 MBTI를 기준으로 다른사람들은 어떤한것들을 하며살아가며 그것들을 보면서

자기의 삶에서도 도전을 해보는 것을 목표로 잡게 되었다.

 

요약하면 다른 사람을 삶을 둘러보고 자기의 삶에도 적용하고 도전해보는 곳이라고 

생각하면 될것같다.

 

이 서비스를 구현하면서 백엔드 개발자를 꿈꾸는 나로써 

추구하는 목표는 아래와 같다.

 

-협업에서 일어나는 일들에 대해 몸소 느끼며 더 잘해가는법들을 찾아보고 공부하며 적용하기

(swagger 코드 컨벤션 git flow 클린코드(가독성올리기:코드에대한 명확한 이해와 적용이 필요하다 생각함)

 

-새로운것을 배우고 적용하는 나의 마음가짐 체크와 빠르게 습득하는법에 대해 탐구 

(끝없이 배우고 적용하며 살아가야하는 만큼 빠르게 습득하고 적용하는법에 대해 나만의방식을 가지는것은 중요하다 생각함)

 

 

위 같은 목표를 우선 달성해보기 위해서 실전에서 노력들을 할 것이며,

추가적으로 생기는 고민들에 대해서도 목표를 설정하고 해결해 나아갈 것이다.

 

---

레퍼런스

 

아키텍쳐 패턴

10 Common Software Architectural Patterns in a nutshell

 

Layered Architecture Deep Dive

 

 

redis 관련글

Why and when to use Redis?

 

 

데이터 일정 기간 지나면 자동 삭제

1)MySql

2)mongoDB

Auto delete Expired Data Row in MySQL

 

Expire Data from Collections by Setting TTL — MongoDB Manual