1차 완성, 코드 리뷰

 

1차적으로 프로젝트가 완성 되었다. 

https://github.com/stophyeon/Darakbang.git

GitHub - stophyeon/Darakbang: 오픈 마켓 서비스

 

우리가 원하던 대로 , Spring Cloud, API GATEWAY 등을 활용하여 
MSA 구조의 마켓의 구축을 성공했다.

 

해당 구축 이후엔 코드 리뷰를 진행했다.

 

사실 코드 리뷰라는 기회 자체가 정말 얻기 쉽지 않은 기회이지만, 다행히도 팀장역할을 하신 분의 지식이 깊어
코드 리뷰를 받을 수 있었다. 

 

코드 리뷰 내용

 

1. 가독성이 너무 떨어진다.

 

 개인적으로도 그렇게 생각해 왔던 부분이다. 

 개발공부를 처음으로 시작할 때 혼자서 코드를 만들고 매일매일 눈뜨자마자 해당 코드를 수정하고 했던
 겨울방학의 루틴이 오히려 독이된 부분이 있는 것 같다.

 

 혼자서 BACKEND 코딩을 진행하고, 그거에 맞는 FRONTEND코드를 받아오거나 간략하게 만들때는 
 변수명 등이 이상하고 의미 없어도 크게 문제가 없었다. 

 하지만 다른 사람들과의 협업 과정에선, 굉장히 중요한 문제가 되었다. 

 

  1. 명확한 기준이 없게 작성했다. 

 Pathvariable에는 일정한 변수를, requestparam 으론 가변적인 값을 넣어주는 형태로 약속하였지만,
 혼자서 그냥 'Pathvariable 이 편하기 때문에' Pathvariable을 사용했다. 
 

2. 변수 명이 내 마음대로다. 

 

좋은 코드, 클린 코드는 높은 가독성과 직결적인 의미를 지닌다. 

다른 개발자가 갑자기 내 코드를 받더라도, 한눈에 이해할 수 있는 것이 좋은 코드이다. 

 

지금은 바뀐 버전이다. 예전엔 updateproduct, changeproductvalue와 같이 작성했었다.

 

Method는 동사로, 카멜 케이스로 작성한다.

변수는 명사로, 상수는 모두 대문자로, 기본적으로 카멜 케이스로 작성한다.

(db와 관련된 사항, 혹은 front와 통신시는 snake 케이스를 사용한다.)

 

솔직히 혼자 공부를 할때, 왜 귀찮게 이름을 바꿔야 하지? 라는 생각을 했었던 것 같다.

그 이유는 바로 기능은 잘 되기 때문이다.

그러나 , 이번 졸업작품을 하면서 혼자서 처음부터 끝까지 할 수 있는 프로젝트는 없다는 생각을 했다.

또한, 앞서 했던 '잘 되는데 이름을 왜 신경써'는 결국 그 변수를 협업때 맞추는 과정에서 많은 시간을 소요하게 했다.

 

이러한 것은 사실, 작성할때 잘 신경쓰는게 최선의 방법이다. 

앞으로는 꼭 이러한 방식을 고려하자.

 

2. 결합도도 너무 높다

 

정보처리기사를 준비하며, 결합도라는 개념을 많이 들었다.

그리고 이번 코드리뷰때 결합도가 너무 높다는 얘기를 들었다.

 

그 이유는, 내가 공부를 하며 들었던 '비지니스적 서비스의 단위를 잘게 분할하라' 라는 개념을 혼동했기 때문이다. 

이처럼, 결제 -> 검증 -> 구매 반영으로 이루어지는 복잡하지 않은 구조임에도 불구하고.

너무 많은 service로의 분할을 하였다.

'비지니스적 서비스를 잘게 분할하라' 라는 것은, 기능을 묶을때 최대한 세밀하게 묶으라는 뜻이지,

SERVICE LAYER를 잘게 분할하는 뜻이 아니었다. 

 

이러한 SERVICE LAYER들을, METHOD LAYER로써 METHOD로 기능별로 묶어 표현했어야했다.

(이에 따라 결합도는 낮게, 응집도는 높게 변화될 것이다)

 

3. 너무 기능구현에 '만 ' 집중했다

 

코드를 작성하며, 너무 기능 구현에 집중한것 같다는 얘기를 들었다.

사실 위에서 작성했던 REPOSITORY에는 반영되지 않았지만, 정말 많은 개발을 진행했고, 반영되지 않은 레퍼지토리들이
매우매우 많다.

 

이렇게 기능을 완성하는데 집중하다보니, 한가지 기능을 구성하더라도 다양한 방안을 고려하거나
하는 고민을 자주 하지 못한것 같다는 평가를 받았고, 굉장히 정확하다 생각한다.

 

Notion – The all-in-one workspace for your notes, tasks, wikis, and databases.

DELETE , UPDATE 쿼리 관련 | Notion

- PRODUCT 개발 도중 생각한, UPDATE/DELETE 관련 동시성 문제

 

동시성 문제를 고안해보라는 얘기에 따라 , PRODUCT 관련 동시성에 대해 크게 고민해본 경험이 있었다.

이러한 동시성을 고안해보라는 얘기 전에, 사실 설계 과정에서부터 고려 하였어야 했다.

 

기능을 만드는 것은 쉽다, 인터넷도 너무 잘되어있고 자연스럽게 진행할 수 있다. 

하지만 단순한 기능 뿐만 아니라, 동시성 문제, 자료구조의 선택 등 다양한 고안을 진행했어야 했다. 

 

SAVE 만을 위한 REPOSITORY. 더 좋은 방안이 있었을 것이다.

 

4. 코드에 대한 고민이 부족했다 

 

위의 3번과 이어지는 내용이자, 가장 핵심적인 내용이었다. 

이 4번은 따로 분리하여 작성하도록 하겠다. 

 

코드에 대한 고민이 부족하다. 

 

코드 리뷰를 진행하며, 코드에 대한 고민이 내 코드에서 잘 보이지 않는다는 얘기를 들었다.

사실 작성 도중에는 정말 많은 고민을 했었기 때문에, 그렇지 않을 것이라 생각하고 다시 코드를 확인해보니

확실히 그러한 부분이 많이 보였다. 왜 그랬을지. 고민해보았다.

 

1. 협업 과정에서 충돌이 너무 많이 발생했다.

이번 팀플 과정에서 가장 많이 문제가 발생했던 것은 , 

'내가 할땐 되던건데 합치니 안된다' 였다. 

 

이 말은 곧, 다른 사람과의 커뮤니케이션 OR 내 코드의 가독성의 문제 때문에 남이 내 코드에 맞춰

테스트 해주기 어려웠다는 의미가 된다. 

 

즉, 코드의 가독성을 올리고, 말이 아닌 '명세서'로써 협업을 진행했어야했다. 

 

그로인해, 너무 의미없는 시간이 많이 걸렸다.

 

2. 너무 오랜 시간이 걸려서, 만들고 나니 기능에 대한 요구가 사라졌다. 

내가 만들었던 코드들. . 이중에 쓰인것은 3할이 안된다.

 

개발 과정에서 너무 많은 시간이 쓰였다. (이는 내 공부, 경험 부족이기 떄문에 사실 다른 방법이 없다)

그러다보니 내가 개발을 완성 -> 이미 해당 기능의 장점을 어필하지 못해 기능 취소 -> 내가 만든 코드 삭제

로 이루어지는 경우가 굉장히 많았다.

 

내가 만든 코드를 완성하려면, 짧은 시간내에 밤을 새더라도 완성하여 해당 기능을 어필했어야 했다. 

ERD (notion.site) 

ERD | Notion

- ERD만 보아도, 4번이나 변경되었다. 이처럼 계속해서 바뀌는 내용에 맞추어 빠르게 내 완성한 코드를 
  전달했어야했다.

 

 

3. 인터넷에 가장 먼저 나오는 'MSA의 단점' : 개발 과정의 어려움을 체감하다.

가장 먼저, 시스템 구조를 5시간 연속으로 회의하고 전화하면서 MSA 구조로 진행하기로 결심한 이후

MSA의 단점에 대해 검색해본 경험이 있다.

MSA의 단점으로 검색하면 가장 먼저 나오는것은 '개발 과정의 어려움'이다.

나는 이얘기를 사실 믿지 않았다. 그냥 하면 되는거지 그런게 어딨어? 라고 생각했다.

그러나 그 과정에서 체감한 , 개발 속도를 늦추었던 이유들에 대해 정리해보겠다. 

 

Spring Cloud를 쓰기로 결심한 순간, 내 전용 test 환경을 만들어야 했다.

이것은, Spring Cloud + Eureka + Config를 사용하며, 내 전용 conifg파일을 모아둔 것이다.

이렇게 복잡한 구조임에도 불구하고, 저 config-server의 내용중 단 하나도 최종 결과에 반영되지 않았다.

즉, TEST 만을 위한 설정이다. (내 DB, 내 DB ID, 기타 등등)

 

그렇지 않는다면, 상호 작용을 TEST 하기 굉장히 힘들다.

 

MEMBER CONTAINER에서 사용자의 ID를 받아와야 상품을 작성할 수 있다면,

임의의 값을 넣는것 말고는 단위 TEST를 진행하기 힘들다.

그렇기 떄문에 빌드, TEST CASE로만 테스트를 진행하고 PUSH 한경우가 있었다.

그 결과, PUSH 이후 상호 작용 과정에서 많은 오류가 났고, 내 오류를 남이 고쳐줘야 하는 경우가 있었다.

 

남이 내 코드를 고치는건, 남의 시간을 뺏으며 내가 직접 고쳤을 때 보다 오래걸렸다.

 

즉, 어떻게 해서라도 test를 진행하고 push 해야했다. 그 사건 이후론 계속해서 TEST를 진행하고 PUSH하는 습관이 들었지만 해당 과정이 얼마나 어이없었는지를 이제는 알게 되었다. 

이러한 TEST과정이 , 온프레미스 구조보다 훨씬 오래 걸리게 된다.

 

이것이 MSA의 단점이구나 싶은 순간이었다.

 

 

다짐 + 앞으로의 리팩토링 예정 

 

 1. 대화는 명세서로, 변수명 등은 명확하게

 

 협업이 필요한 과정에서는 반드시 명세서를 작성해주는 것이, 상호간의 속도를 높인다.

 변수명은 명확하게, 약속된 CASE로, 명명 규칙에 따라 작성한다. 

 최초에서부터 이렇게 시작해야, 속도가 크게 감소한다.

 

 2. 코드의 모든 부분은, 일리가 있어야한다.

 

 LIST를 사용했다면 왜 LIST인지.
 MONO를 쓴 이유는? WEBCLIENT를 쓴 이유는? 비동기를 쓴이유는? 그 장점은?

 등을 고민해야 한다. 

 

 3. 코드의 작성시부터, 입체적인 고민을 하자 .

 

 JPA를 활용했다면 LOCK은 어떻게 할 것인지,

 동시성 문제는 어떻게 할 것인지. 
 공부를 하면서 좋은게 있다면 그것을 써보자 

 

 4. TEST는 어떻게든 진행해야 한다. 

 

 특히 MSA나 , GOOGLE CLOUD, EUREKA 등을 활용하면 
 TEST가 굉장히 어려워진다. (단순한 METHOD의 TEST 말고) 

 그래도, 해야한다. 그게 더 빠름을 몸소 체득했다. 

 

 

현재, 열심히 한 것에 비해 코드에서 티가 나지 않는다. 이러한 현재 문제를 늦었지만 천천히 공부하며 바꿔보자.

늦어도 완성하면 된다!