Today's Dev Notes(2018-11-22)

안녕하세요, Brad입니다. 오늘 수업시간에 다루었던 Q&A를 우선 정리해볼게요. 그런데 수업시간에 다루었던 내용 중 어제 제가 궁금하였던 부분은 그 부분에 정리해놓을게요!

 

Q&A

• Mustache @index + 1을 어떻게 하면 될까요?

  • Mustache의 Helper를 이용하면 가능합니다. 하지만 너무 복잡하다고 하네요.
  • 또는 {{@index_1}} 을 사용하면 1부터 인덱스가 매겨집니다.

• HTML 들여쓰기

  • template engine부분은 들여쓰기 적용하지 않는 것이 좋습니다. 보여지는 화면으로 봤을 때 template engine때문에 하나 더 들여쓰면 그 질서가 깨지기 때문입니다.

• 삭제 구현시 기준점

  • 삭제 구현을 할 때 어떤 데이터(예를들어 userId, id, name 등)를 가지고 그것을 구별해 삭제하냐는 것입니다.
  • id(PK)를 기준점으로 삭제,수정하는 것이 좋습니다. 유일하기 때문이죠.
  • userId를 쓸 수도 있겠지만 보통은 id를 많이 쓴다고 합니다.

• TDD

  • 테스트하기 쉬운 코드는 일단 의존성이 약해야 합니다. 그런데 Controller의 경우 DB에 의존하고 있는 관계이기 때문에 테스트하기 어렵습니다.
  • 웹 프로그래밍에서는 모든 부분은 TDD로 개발하려는 생각은 어려울 수 있습니다. 다만 Answer, Qustion, User부분에서는 할 수 있죠.
  • 그렇기 때문에 주요 로직들은 그 안으로 모아야 가능하고 그 안에서 테스트할 수 있습니다! 즉, '상태데이터를 가진 객체에게 메시지를 보내라는 것'입니다!

• DB에서 유저를 삭제했는데 왜 id가 빈자리로 생성되지 않는걸까요?

  • DB자체가 그렇게 가동되기 때문입니다.
  • 이유는 성능적으로 빈자리 찾으려면 O(n)의 복잡도가 필요하기 때문입니다.
  • 지금은 데이터가 몇 개 없어서 큰 차이가 안 나지만 엄청난 데이터로 늘어나면 그 차이가 늘어나는 것입니다.
  • 따라서 성능 비교는 성능 절대값이 아니라 성능의 상대적 차이(몇 배 차이나는지)가 중요합니다.

• MvcConfig 사용 관련

  • 매핑 메서드 내 로직이 따로 없을 때 사용합니다.
  • 실제 현업에서는 많이 안 사용합니다. 왜냐하면 지금은 로직이 없더라도 나중엔 권한처리등 로직이 생기기 때문입니다.
  • 그리고 유지보수 측면에서도 매핑 부분을 한 곳으로 모아두는 것이 좋기 때문에 단순한 웹 애플리케이션이 아니면 안 사용하는 것이 좋습니다.

 

수업내용

오늘은 외부키와 객체간 관계에 대해서 다루었습니다. 평소 미션에 따른 요구사항 설계만 생각하다보니 전체적인 관계를 크게 생각해보지 못했는데요. 수업을 들으면서 요구사항에 왜 그런식으로 나왔는지에 대한 이해를 어느정도 할 수 있었습니다.

저희가 현재까지 구현한 qna미션은 다음과 같은 구조를 가지고 있습니다. User와 Question간 (1:n)관계로 나타낼 수 있는데요. User 하나가 Question 여러개랑 연결될 수 있다는 것이죠. 설계시에 이러한 객체간의 관계를 파악하는 것이 우선해야 한다고 하네요. 그리고 이러한 관계 파악이 끝난 후에 프로그래밍이 시작하는 것입니다.

 

• FK(Foreign Key, 외래키)

  • 다른 테이블의 특정키를 저장해놓음으로써 관계를 맺어줍니다.

  • 실제 현업에서는 테이블수와 객체수가 같은 것이 아니라 객체수가 훨씬 많습니다. 클린코드나 유지보수적 측면에서 객체지향적으로 프로그래밍하기 때문입니다. @Embedded라는 것을 통해 필드를 여러 클래스로 나눌 수 있습니다.

  • OneToMany관계엔 Many부분에 FK를 주로 둡니다. 효과적인 측면에서 그렇습니다. 생각해보면 그렇죠.

  • OneToOne관계 User - Address 라면 보통은 중요한 부분(User)가 아니라 덜 중요한 부분(Address)에 FK를 둡니다.

  • FK에서 @ForeignKey 옆에 name은 뭘까요?

  • 없다면 랜덤 키값이 부여되는데 그것의 이름을 지정하는 역할을 합니다.
  • 사실은 Index 이름입니다. 그런데 아직 Index가 뭔지 잘 모르겠네요..

• uni-direction(한방향 의존관계), bi-direction(쌍방 의존관계)

• 성능(빠름), 의존성(작음) 측면에서 가능한 uni-direction을 고려하는 것이 좋습니다.
• (User 또는 주문Class - 'God클래스'라고 부른다고 합니다)는 bi-direction을 피하는 것이 좋습니다.
• 의존관계를 맞지않아도 repository내 메서드 정의 가능합니다. 굳이 mapped할 필요는 없습니다.
• 다만 cascade 적용은 회사 정책에 따라 다릅니다. 유저가 삭제해도 그 글을 유지할것인지, 아니면 남겨둘 것인지에 따라 달라질 수 있는 것이죠.