우아한 테크코스) Lv2 - 3주차 [블로그 - 빌드&배포 구성 / 댓글 관련 기능 구현] 미션 후기, 코드리뷰

Lv2 - 3주차 미션 : 빌드&배포 구성 / 댓글 관련 기능 구현

https://github.com/woowacourse/jwp-blog

학습목표

• JPA를 이용하여 기초적인 연관관계 매핑을 이해한다.
• 원격 서버에 배포하는 경험을 한다.
• 배포에 대한 기본적인 프로세스를 이해한다.

미션

• 게시글 작성 시 작성자 정보 부여하기
  • 작성자만 게시글 수정/삭제 가능하게 하기
• 댓글 관련 기능 구현하기
• 원격 서버에 직접 배포하기
• Script를 활용하여 자동 배포하기

체크리스트

• 모든 요청에 대한 Acceptance Test를 구현했는가
• HTML 중복 제거하였는가
• 테스트의 중복을 제거하였는가
• URL 컨벤션을 지키며 구현했는가
• 게시글과 회원 간 객체 연관관계가 잘 맺어졌는가?
• 댓글과 게시글, 댓글과 회원 간 객체 연관관계가 잘 맺어졌는가?
• 댓글등록/조회/수정/삭제 기능이 잘 동작하는가?
• 댓글 수정/삭제 시 작성자만 가능하도록 구현했는가?

---

새롭게 알게 된 것

• JPA 객체관계 매핑 (@OneToOne, ...)
• 영속성
• front: Event & 'Todo List' 실습
• 배포
• 리눅스
• Script를 활용한 자동 배포
• Jenkins
• JPA Auditing

---

느낀점

• 위를 보면 알다시피, 이번주에 등장한 개념들은 하나하나가 모두 무거운 내용들이라 이번주에 모두 마스터하기보단, 이번 미션때 경험해보는 느낌이었고 앞으로 차차 학습해가야겠다
• JPA 라는 주제를 따로 떼서 별도로 학습을 진행하긴 해야할 듯. 참고서적은 당연히 이거
• 프론트를 한창 삽질했고, 이후로도 주차가 지나가며 조금씩이지만 점점 나아지긴 하는 느낌
• 배포, 리눅스와 script, 젠킨스 등도 생각처럼 지루하진 않았다. 예전에 했던게있어 학습이 어색하진 않았고, 무엇보다 해당 기술들이 필요한것임을 느꼈다. 해놓으면 편하고.
• 배포와 관련해 이론적인건 이번주에 배웠고, 실제로 미션 제출 코드에 포함된건 다음주(4주차)부터. 실제로 원하는대로 좀더 자유롭게 사용하기 시작한건 그다음인 미니프로젝트.

---

7.25) 조영호님 특강 메모

• 기술 사용방법을 익혀서 프로젝트에 적용하는 것 먼저하고, 이후에 자연스레 원리를 이해하자
• 인터넷으로 그때그때 단편적인 지식을 얻는것보다, 스프링부트책 쭉 한번 읽는것도 생각보다 ㄱㅊ
• Repository와 Domain을 같은 레이어 레벨로, repo를 인터페이스로 만들어 의존성을 도메인으로 보내는 역전 ?
• ServiceImpl 같은거, 인터페이스 만드는 것에 대해 서비스는 반대 / 리포지토리는 찬성. 실용적 측면에선. 물론 이론적으론 인터페이스 쪼개는게 낫겠지만
• 컨트롤러단은 생각보다 단위테스트 하지 않는다, 그건 리포/도메인에서 할수도. mock으로 때려서 테스트
• 외부에서 필요한 의존성을 받아서 결합도를 낮추는 것
• 숨겨진 의존성이란게 있다. 명시적으로 생성자 등으로 받아 관리하려는 것
• DB는 양방향일수밖에. 외래키 타고 왓다갓다 가능
• 객체에선 양방향 의존성 가급적 피하라. 단, admin이나 배치에선 양방향을 고민할수밖에 없을것. 정필요하면 쓰는거지만, 둘을 같이 묶어서 계속 관리하기로 하고
• 의존성의 종류 4가지. 연관단계, 의존단계, 실체화단계 .. 등
• 조영호님의 추천 서적
  1. Apply Uml Pattern
  2. Head first design pattern
  3. Refactoring, kent beck
  4. Tdd, Kent beck
  5. Working effectively with legacy code

---

내 코드, 피드백 관련

• 백엔드와 마찬가지로, 프론트로 뷰와 로직을 분리하는 것이 좋다. 다음과 같은 코드는 지양하자.

  <div onclick="alert(1);">click</div>

• 예전 IE때는 캡쳐링을 많이 사용했었는데, 요즘은 버블링 위주

• 로그아웃시 세션ID를 삭제하기보다, 새로운 ID를 발급해 바꿔버리는 방법도 있다.

• 로그인후 GET에서 뒤에 SessionId 붙는 환경도 있고, 안붙는 곳도 있다. 톰캣 설정따라 다름. 여기선 패턴에 .*붙여서 간단히 우회

• 캡틴&조영호님 : "양방향은 꼭 필요한 경우가 아니라면 가급적 자제하자"

• 도메인이 늘어나며, 예외처리 방법을 통일시키기 위해 고민했다. 예외를 어디서 터뜨리고, 어디서 잡아서, 어떻게 처리할지에 대해서.

• 컨트롤러 반환시, return String("redirect:/articles~..") vs return RedirectView 방식의 차이
  그냥 리다이렉트만 할거면 상관없지만, 후자처럼 객체로 만들면 RedirectView의 다양한 메소드들을 활용할수잇어 추가적인 옵션을 줄수있다.

• SimpleJpaRepository의 save가 이렇게 생겨있다. 한 트랙젝션 단위를 이루는데 이걸 호출하는 서비스 메소드에서 save를 여러번 하고 메소드에 @Transactional가 붙어있다면?
  부모인 서비스의 메소드의 트랜젝션을 중심으로 이뤄진다고 이해하자. 첫 save땐 if문의 new로 걸리며 persist안에서 새롭게 생성되고 이후 두세번째 save땐 트랜젝션이 merge되어, 최종적으로 트랜젝션의 commit은 마지막에 한번만 수행되는 것으로 이해. 이말인 즉슨, 중간에 하나라도 에러나면 서비스의 메소드 단위로 모두 롤백된다.
  키워드 : transaction propagation

• Entity의 Column을 구체적으로 설정하자

• 테스트 데이터 설정

  • 단순히 data.sql를 만들고 옵션을 설정해주는 방법도 있고
  • ApplicationRunner와 CommandLineRunner를 이용하는 방법도 있다

• Article과 Comment : 단방향 vs 양방향과, 단방향이라면 누가 부모가 되는게 나을지에 대한 고민 -> 결론은 없고 사람마다 의견이 다름

• Service에 관해 고민해볼만한 거리

  • ArticleService와 CommentService를 분리하는 것이 좋을까?
  • Service를 어떤 기준으로 분리하는 것이 좋을까?
  • 각 Entity 마다 Service를 추가하는 것이 좋을까?

• JPA Auditing 기능 유용했다

• 데이터 크기를 결정하기 힘든 큰 크기의 데이터는 @Lob을 고려해본다

• 이제까진 무조건 ~Dto라는 네이밍을 했었는데, 고민해본뒤 관련된 객체가 하나라면 -Dto와 같이 간단히 쓰고 여러개라면 -Request, -Response 등과 같이 직접적으로 의미를 갖게하는것도 괜찮겠다고 스스로 정리했다.