콘텐츠로 이동

2021 06 12

2021-06-12

jwp-chess 복습하기

  • 어떤 부분을 중점적으로 개발했는가? - SparkJava에서 Spring으로 전환하기 - Spring Web MVC와 Spring JDBC를 처음 공부하며 적용해봄
  • 고민했던 부분, 느꼈던 감정, 페어 프로그래밍 회고 - 배럴과의 페어가 매우 스무스 했음 - 둘 다 처음 스프링을 접해서 그런가 학습 속도가 비슷했음 - Spring 적용은 자체는 사실 학습테스트에 있는 것을 거의 갖다쓴 수준이라 그렇게 어렵지 않았음 - 테스트 코드 작성에 더 시간을 많이쓴듯 - 각 Layer 별로 테스트하려다 보니 Mocking을 사용했음 - 전혀 무슨 뜻인지 모르고 블로그 따라침
  • 피드백 공유 및 코드가 개선된 포인트 공유 - REST API에 대해 공부해보기 - HTTP method로 행위를, URL로 자원을 표현 
    GET: /startNewGame --> GET: /game/new
GET: /loadPrevGame --> GET: /game/saved
POST: /move --> POST: /game/move

    - @GetMapping, @PostMapping 어노테이션의 필드값을 채워 넣을 때, 필요한 것만 넣자! - 굳이 중복된 의미를 가진 것을 쓰지 말자 - @RestController와 produces/consumes은 같은 의미! - 어노테이션에 같은 것 써주는 것도 중복이겠구나 - 런타임 코드상에서도 중복일까?? - 스프링 어노테이션은 언제 해당 필드를 추출해 값을 설정해두는 걸까? - Dao를 얇게 유지할 것 (최소한의 DB Access만 할 것!) - Dao 내부에서 비즈니스 로직을 가지면 안댐 - 생성로직을 가지지 말라고 피드백을 가졌음 - 근데 이후 미션에서 Dao에서 Domain 객체를 생성해서 반환했었음 - 해당 미션에서는 한 번에 효율적으로 DB에 접근해서 온전한 도메인을 못만들었음 - Dao 내부에서 DB 여러번 찔러서 온전한 도메인을 생성하여 반환하도록 코드를 짰었음 - 테이블 하나 당 Dao를 작성했으면 이런 일 없었을 텐데! - 기타 문법적인 사항 - final, 공백 적절한 활용 - Map에서 entrySet을 활용해 key-value를 동시에 접근 - Jackson의 ObjectMapper를 통해 JSON을 생성하여 테스트하기

  • 개선될 포인트 - 도메인 객체, Dto를 생성하는 과정을 각각 도메인/Dto 내부에서 해주는 것이 좋아보임 - Spring의 JdbcTemplate을 사용해봄 - SpringBoot에서 주입시켜주는 것인데 당시에는 몰랐음 - 지금은 아니? - application.properties 이런 설정들이 JDBC 설정들을 적어놓은 것이자나? - 이게 어떻게 JdbcTemplate 빈 객체를 만드는지 조금 알아보자 - 디버깅 찍어보는 것도 괜찮지 않을까? - Service에서 Transactional 처리를 조금 해주는 게 좋겠다 - 왜 Transactional 처리 해주는게 이득인지 아니? - 원자성 보장? - 그러면 그냥 synchronized로 하는게 좋지 않을까? - 내부적으로 어떻게 돌아가는 걸까? - 세션 만드는 과정을 interceptor로 하는 것이 좋아보임 - MockMvc와 RestAssured의 차이 정리하기
  • 정리할 포인트 - [Spring이 JdbcTemplate 빈을 주입해주는 방법] - [스프링에서 어노테이션에 대한 정보를 런타임에 어찌 활용하는지] - [Transactional 처리의 내부 동작] - [MockMvc와 RestAssured 차이]

atdd-subway-map 복습하기

  • 어떤 부분을 중점적으로 개발했는가? - 기능별 패키지 처음 접해봄 - 상호 독립적인 테스트를 구현하는 방식에 대해 고민해 봄
  • 고민했던 부분, 느꼈던 감정, 페어 프로그래밍 회고 - 샐리, 영이와 진행한 3인 페어 - 서로의 피드백을 공유하면서 리팩토링 하는 것이 좋았음 - 하나의 도메인을 만드는데(Line) 필요한 정보가 2개의 테이블에 저장되어 있어(Line&Section), setter가 필요했음 - 구간을 삭제/추가하는 로직이 연결리스트 구현과 비슷하다고 느낌 - 검증을 어디서 얼마나 해야하는지 고민함 - Bean Validation을 통한 Controller 단에서의 검증 VS 도메인 안에서의 검증
  • 피드백 공유 및 코드가 개선된 포인트 공유 - 상호 독립적인 테스트를 구현하는 법 - Test > Resource에 schema.sql 작성해서 @Sql(schema.sql) - @DirtiesContext를 통해 메서드마다 빈 새로 생성 - Repository에서 도메인을 반환할까, 요청한 필드값을 반환할까? - 가능한 Service에서 Repository에 질의를 한다면 도메인이 나오는게 좋아보임 - Dao 하나로 온전히 도메인을 만들 수 없다면, Repository 클래스를 만들어 그 안에 필요한 Dao를 넣어두고, 온전한 객체를 만들어 반환하게 하는 것은 어떨까 고민해보자~ - 만약 특정 필드만 필요하면 그걸 반환하게 하자 - 중복을 체크하는 로직을 어떻게 구현할 것인가? - 원래는 DB 필드에 unique를 걸어둬서 스키마를 읽어야만 알았음 - findByName, findById 등을 조회하여 저장하는 방식을 구현해볼 것 - 테이블의 키로 단건조회하는 비용은 무시해도 괜찮음 - Optional.orElseThrow() 형식의 도입 추천 - 하나에 Dao에서 테이블을 Join 하여 정보를 가져오기 VS 테이블 별로 Dao를 만들어 정보를 각각 가져와 합치기 - 현재 테이블별로 Dao를 만들었다 - Line을 전부 다 가져오는 findAll() 메서드를 호출하면 DB를 많이 찌르게 된다 괜찮은가? - Table Join하여 많이 긁어오는게 좋아보이기도 한다 - DB 접근 시 주로 문제가 되는건 잘못된 실행 계획으로 인한 쿼리 수행시간 - 잘못된 인덱스, 옵티마이저의 부적절한 선택 - Key로 조회하는 것은 효율 측면에서 매우 미비함 - 이 정도는 추후에 문제가 생겼을 때 리팩토링해도 괜찮다 - 서비스가 서비스를 가져도 되는가? - 순환 참조가 아니라면 서비스가 서비스를 가지는 것은 괜찮다 - StationService가 역을 삭제할 때, 해당 역이 들어있는 구간을 삭제해주기 위해 LineService 호출 - 기타 문법적인 사항 - 데이터 접근 기술을 명시적으로 메서드에 드러내지 말 것 (확장에 안좋음) - List에 null을 담은 상태로 반환하지 말고, 비어있는 리스트를 반환해줄 것
  • 개선될 포인트 - 기능별 > 레이여 별로 패키지 좀 분리하자 - Controller의 Request를 다 분해해서 필드를 추출해서 Service한테 넘겼네? - 그냥 Request를 통으로 Service한테 넘겨주는 건 별로일려나? - 서비스가 Request까지 알아야할까? Presentation Layer 소속의 객체인데 여기서 쇼부보는게 맞지 않나? - 필요한 정보를 추출한다는 측면에서 Service가 아는게 어색한가? - 주구장창 JdbcTemplate만 썼네... - SimpleInsert 이런 것도 한번 도입 고민해보자
  • 정리할 포인트 - [다양한 JdbcTemplate의 활용] - [사용자의 Request를 어느 레이어까지 내려야할까?] - [독립적인 테스트 작성 방식]