[WIL3] 협업 툴 활용하기와 Spring 시작

🌊 WIL 3

2021.6.21 ~ 2021.6.27

 

⛵ 협업 툴 활용하기 : 노션

  항해에서 팀 협업들을 거치면서 협업툴을 적극적으로 활용해야겠다고 느끼고 있다. 알고리즘 스터디에서는 팀원들간의 의 문제 풀이에 대한 코드와 해석을 서로 공유하기 위해서 노션을 사용했다. 그동안은 개인적인 노트 용도로만 노션을 사용했었는데 협업툴로써 노션을 처음 써보게되었다. 내가 느낀 협업 툴로써의 노션의 장점은 다음과 같다.

1. 직관적이다보니 노션을 사용해본 적이 없는 팀원들도 빠르게 적응할 수 있다.

2. 공유하기의 옵션을 세밀하게 조정할 수 있다. (편집 허용/불가)

3. 특정 사람들을 초대할 수 있고 모든 사람에게 공개할 수도 있다.

알고리즘 스터디의 노션 페이지

 꾸미는 것도 시간 대비 너무 이쁘게 나와서 요즘 재밌게 꾸미고 있다. 노션에 생각보다 다양한 기능이 있어서 요즘에는 이것저것 시도해보고 있다. 아 역시 알고리즘빼고 다 재미있는 것 같다.

 위의 사진은 내가 직접 만든 이번 알고리즘 스터디조의 노션페이지다. 알고리즘 문제에 지친 우리 팀원들에게 조금이나마 힘이 될 수 있게? 만들어 주고 싶었다 노션 페이지를 들어올때 한번씩 피식이라도 하게 해주고 싶었다.

 

 

⛵ 협업 툴 활용하기 : 슬랙

Spring 기초주차 스터디의 슬랙방

  목요일부터는 Spring 기초주차 스터디를 시작하였다. 들어가자마자 스터디 팀장님이 '카톡보다는 슬랙을 사용해보는 게 어떨까요?'라고 제안하셨다. 이전 스터디조들에서는 카톡방을 파서 소통했었다. 하지만 이번 팀장님은 슬랙이 요즘 기업들에서 많이 사용하는 방식이기도 하고 카톡 단톡방보다 훨씬 좋다라고 추천하셨다. 

  전혀 생각해보지 않은 방법이지만 이번 기회에 새로운 툴을 배워보는 것도 나쁘지 않을 것 같아서 좋다고 동의했다. 지금 몇일째 사용해본 결과 카톡보다 훨씬 좋고 다음 팀에서도 적극적으로 사용해보고 싶었다. 슬랙에 대한 이야기는 포스팅을 따로 작성했었으니 확인해보면 좋을 것 같다.

2021.06.30 - [개발 TIP] - 떠오르는 협업용 메시저, 슬랙 사용기

 

 

⛵ 협업 툴 활용하기 : 피그마

 

  이건 나의 개인적인 챌린지였다. 피그마는 최근 가장 떠오르는 웹기반의 UI/UX 디자인 및 프로토타이핑 툴이다. 본격적인 팀프로젝트를 시작하기 전에 약간이라도 배워둔다면 나중에 프론트엔드 개발자나 디자이너들과 소통하기 좋을 것이라고 생각했다. 나의 경우에는 포토샵을 어느정도 배워났기 때문에 몇번 만지다보니 바로 감을 잡을 수 있었다. 사용하다보니 알게된 점인데 구글 스프레드 시트처럼 여러사람이 함께 공동으로 작업할 수 있어서 나중에 팀프로젝트에서 프로토타이핑 협업툴로 사용한다면 좋을 것 같다는 생각을 했다.

 

 

---

⛵ 다시 시작하는 Spring

 항해에 들어오기 전부터 Spring을 이미 어느정도 공부를 해왔었다. 당시에 Spring을 공부하고 싶었지만 어디서부터 시작해야할지 몰라서 일단 스터디에 들어가고 함께 책을 통해 공부를 시작했다. 책을 통해 공부한 내용을 바탕으로 그럴듯한 팀프로젝트(github 리포지토리로 이동 | 회고 포스팅 이동)를 만들기도 했다. 하지만 만들고 나서 의문이 남았다.

 

 이게 지금 제대로 설계한 것이 맞나?

 이게 무슨 코드더라?

의문을 품고 Spring을 어떻게 하면 잘 사용할 수 있을지를 다시 공부했다. 그러던 중 항해99 부트캠프를 시작하게 되었다. 이번주부터 듣게된 항해99의 Spring 강의는 솔직하게 말하면 기대 이하였다. 하지만 함께 좋은 설계에 대해 고민할 수 있는 사람들이 많은 것이 좋았다. 모르는게 있으면 질문할 튜터님도 계시고 함께 공부하고 고민하는 팀원들이 있어좋았다.

JPA관련된 질문

 위의 사진 속 질문 외에도 그동안 정말 궁금해왔던 Service-ServiceImpl 관련된 질문과 DTO 사용에 관련된 질문을 튜터님에게 여쭤보았었다.

 

Q1) 다른 목적을 가지고 있더라도 같은 속성을 가지고 있는 DTO들에 대하여 재활용하는 것에 대하여 어떻게 생각하시는지 궁금합니다. 다른 목적을 가지고 있다고 DTO를 새로 또 만들게 되면 DTO가 정말 많아질텐데 이 방법이 맞는 방법인가요?

A1) 다른 목적을 가지고 있다면 DTO를 새로 만드는 것이 좋습니다. 현재 진행하시는 프로젝트에서 DTO가 많이 나온다는 것은 지극히 정상입니다. 이후에 비슷한 DTO들 끼리 상속을 받을 수도 있고 리팩토링 과정을 거칠 수는 있습니다. 우선 지금 단계에서는 다른 목적이라면 DTO를 새로 만드시는 방법을 추천드립니다.

 

Q2) Service - ServiceImpl구조에 대한 질문이 있습니다!

 제가 이전에 Spring을 배울 때에는 Service-ServiceImpl구조를 따랐었습니다. 당시 저는 계층 사이의 낮은 결합도를 위해 인터페이스를 통해 계층 사이 호출이 이뤄져야한다고 배웠습니다.

 하지만 튜터님의 Spring 기초 강의-2주차를 보면 인터페이스를 거치지않고 Service를 사용하시더라구요. 이에 의문을 가지고 관련하여 찾아보니 실제 요즘 현업에서는 Service-ServiceImpl 구조를 사용하지 않는다는 포스팅을 읽기도 하였습니다.  Service - ServiceImpl구조에 대한 튜터님의 생각과 실제 현업에서는 어떤 식으로 사용하는지 여쭤보고 싶습니다!

A2) 알아보신 내용이 대부분 맞습니다. Service-ServiceImpl를 처음 사용하게 된 이유는 낮은 결합도 때문이지만 대부분 1:1관계를 가지고 있어서 대부분의 개발자들이 이에 필요성에 대해 공감하지 못했고 요즘은 사용하지 않는 추세입니다. 하지만 분명히 Service-ServiceImpl 구조가 필요한 경우도 있기때문에 필요시에는 Service-ServiceImpl로 수정하어 사용합니다.

 

Q3) DB 의 복합키에 대해 JPA 에서 ID 설정을 어떻게 하나요?

A3) @Id 대신 @EmbededId 혹은 @IdClass 사용 (https://techblog.woowahan.com/2595/)

 

Q3-2) 이와 관련된 질문을 하나 더 있습니다!!
혹시 JPA에서는 PK(기본키)를 auto increment되는 컬럼으로만 주로 사용하나요?
  제가 예전에는 Spring-MyBatis를 사용하고 있었기 때문에 DB 테이블을 직접 작성하였었습니다. 그러다보니 필요하다 생각하면 복합키를 만들기도 했었구요. 또 그때 저는 User라는 테이블을 만들때 아이디(username)는 User테이블에서 유일한 값이니, 이 값을 PK로 지정했었습니다. 하지만 튜터님 2주차 강의에보니 따로 auto increment되는 컬럼(id)를 따로 만들어 주셨더라구요.
  사실 제가 DB를 배울때는 이런 인조식별자는 될 수 있으면 만들지 말라고 배우기도 했고 저 역시도 별로 필요없는 컬럼을 굳이 만들어야하나?라는 생각이 있습니다.
혹시 제가 놓치고 있는 부분이 있을까요? 아니면 JPA의 특징상..?그런건가요?  

 

A3-2) id 를 기본키로 했을 때의 장점이 있는데 모든 경우에 장점이 되는 건 아닌 거 같지만, 제가 아는 범위 내에서 말씀 드릴께요.
    1. id 를 PK 로 하면 PK 에 대한 통일성이 생긴다. 즉, 어떤 테이블에서든 PK 는 증가하는 범위라고 파악할 수 있습니다.
   2. id 순으로 정렬할 때 성능상 도움이 된다. id 정렬 순이 결국 data 의 생성 순이라고 볼 수 있습니다.
        a.게시판 글로 예를 들어보면.. 게시판 글이 생성되는 순서로 id 가 만들어질텐데요. DB 데이터도 결국 HDD (하드 디스크) 에 저장되는데, id 순으로 저장된다면 나중에 게시판에서 최신 순으로 글을 읽어올 때 성능 상 도움이 됩니다. 왜냐면 HDD 에서 데이터를 읽어올 때 데이터가 근처에 있는게 유리하기 때문인데요. 자세한 부분은 모르셔도 될꺼 같고, 암튼 여기까지가 제가 알고 있는 범위입니다.