정준원의 개발 일지

🌼서버 반상회란?디프만 16기 서버 개발자들이 참여하는 반상회16기에서 처음으로 진행되는 행사!내가 여러 포스팅에서 얘기했던 대로 네트워킹을 하고 싶어서 만든 이번 기수에 처음으로 진행되는 행사였다.🌱기획퇴근 후 밋업처럼 가볍게 참석해서 네트워킹을 할 수 있으면 좋겠다고 생각했다.주말에 진행하게 되면 디프만 세션 만으로도 체력이 많이 소모되기 때문에 가볍게 참석할 수 있었으면 했다.그래서 퇴근 후에 진행하게 되었다.실제로 퇴근 후 가볍게 오신 분들도 적지 않았고 나도 퇴근 후 참석해서 하루를 알차게 보낸 것 같은 생각이 들었다.서버 개발자들끼리 네트워킹을 할 수 있는 행사를 만들고 싶었다.특히 다른 팀의 서버 개발자들과 네트워킹을 할 수 있는 기회를 만들고 싶었다.디프만에는 좋은 사람들이 많은 데, ..

실습 2부 - 의존성 역전하기외부 연동들에 의존성 역전 사용!MailSenderRepositoryRepository 들의 네이밍 JpaRepository로 변경! 의존성 역전을 위해 인터페이스 만들기.UserRepository 인터페이스를 생성구현체 UserRepositoryImpl 생성구현체는 UserJpaRepository를 주입받음.  UserRepository는 infrastructure에 있을 경우 상위 모듈인 service에서 하위인 infrastructure를 의존하는 그림이 나오게 됨.따라서 서비스 하위에 외부 연동을 담당하는 port 패키지 생성 후 service에서 사용하는 인터페이스들은 port에 위치 시킴. 분리된 Repository에 따라 코드 수정post@Service@Requi..

패키지 리팩토링!1. 기존 프로젝트 코드들을 user 패키지를 생성하여 옮기기기존 구조 변경된 구조 2. 추가 리팩토링 진행model -> domaindto 네이밍 -> 제거(이미 역할을 내포하고 있음.)repository -> infrastructure 3. 리팩토링 후 테스트 재확인정상 동작하는 것을 확인! 4. 테스트의 구조 또한 위와 동일하게 변경 5. 리팩토링 후 테스트 재확인! 6. 끝!헥사고날과 같은 더 고도화된 아키텍처도 존재함.헥사고날은 도입에 너무 큰 리소스가 듦...강의 마지막 즈음엔 헥사고날과 같은 고도화된 아키텍처에 대해서도 학습 예정!

테스트의 범위ServiceImpl과 Domain을 중점으로 공부할 예정임.Controller와 RepositoryImpl은 아주 적게 다룰 것임.이유가 Controller는 요청을 받고 응답할 뿐이기 때문에 스프링에서 아주 잘 만들어 놨을 것이기 때문임.Repository에서도 마찬가지로 이미 JPA에서 잘 만들어 놨기 때문에 다룰 이유가 없다고 생각 됨. 낮은 커버리지 걱정걱정 : JPA 와 Spring 쪽 테스트를 안 하게 되면 커버리지가 너무 낮게 나옴.도메인 : 도메인이 그만큼 빈약하다는 의미경쟁력 : 서비스의 경쟁력을 의심해봐야 함. 실기 전 추가 사항 및 추가 내용JPA, Http 통신 등 외부 내용들은 의존성 역전 원리를 적용해 다룰 예정임.ServiceImpl -> Repository Se..

H2모든 테스트가 H2를 필요로 한다.H2를 사용하는 순간 중형 테스트가 된다.모든 테스트가 중형 테스트가 되었음...소형 테스트가 없음무거움...!설계가 잘못되었을 확률지금 작성한 테스트가 실제로 테스트가 필요한 본질이 아닐 확률 레이어드 아키텍처의 문제점레이어드 아키텍처유사한 기능들을 같은 계층으로 묶어 관리하는 방식의 아키텍처 구조의존성 역전이나 추상화 없이 바로 구현체를 사용하는 구조요청은 순차적이다Controller가 받아서 Service에게 전달Service는 비즈니스 로직을 처리 후 Persistence(JPA)에게 전달JPA는 Repository 데이터를 가져와 Service에게 전달다시 Service는 비즈니스 로직을 처리 후 Controller에게 전달Controller는 클라이언트에게..

Controller 테스트1. test 패키지와 파일 생성.2. 만만한 HealthCheck부터 시작!3. API 테스트에 많이 사용되는 mockMvc 사용.@SpringBootTest@AutoConfigureMockMvc@AutoConfigureTestDatabasepublic class HealthCheckControllerTest { @Autowired private MockMvc mockMvc; }4. mockMvc를 통해 호출(GET 방식), 응답이 200인지 확인.@Testvoid 헬스_체크_응답이_200으로_내려온다() throws Exception { mockMvc.perform(get("/health_check.html")) .andExpect(status().isOk(..

Service 리팩토링get과 find를 구분하는 컨벤션!find는 null을 반환할 수 있어 Optional로 받는 경우가 많음.get은 데이터가 없으면 에러를 던진다는 의미가 내포됨.해당 컨벤션에 따라 네이밍 변경!public Optional getById(long id){}-> public Optional findById(long id)public UserEntity getByIdOrElseThrow(long id) {}-> public UserEntity getById(long id) {}  User 서비스 자체에서 create가 유저를 생성한다는 의미를 내포함.public UserEntity createUser(UserCreateDto userCreateDto) {}-> public UserEn..

상황레거시 코드가 많음. 서비스는 운 좋게도 매년 성장했음.개발자가 2배 늘었지만, 개발 속도는 1.2배 정도에 그쳤음.(커뮤니케이션 비용 등) 서비스 장애를 우려해서 배포를 신중하게 했음.회귀 버그가 발생할 가능성이 생겼고, 이를 두려워 하게 됨.회귀 버그 : 잘 동작하는 기능이 다시 버그가 발생하는 상황테스트 자동화 도입으로 회귀 버그를 줄이고자 했음테스트 자동화로 인해 커버리지를 높일 수 있음.외부 API 연동, DB 연동 등 쉽지 않은 테스트 케이스를 마주하게 됨.mockito나 H2를 활용해서 처리함.서비스는 단순한데, 이 단순한 서비스 로직 확인을 위해 테스트를 작성하는 일로 인해 더욱 복잡하게 되어 버림.스프링 부트와 H2를 사용하니 100개가 넘는 테스트를 하는 데 2분이 넘게 걸리게 됨...