토비의 스프링

그 동안 스프링으로 꽤나 다양한 프로젝트를 진행해봤다. 쇼핑몰 웹사이트, 학생/교수 웹사이트부터 앱 서버에 이르기까지... 그리고 현재 근무하고 있는 위메프에서도 스프링 부트를 이용해서 백엔드 개발에 참여하고 있다. 그러다보니 나에게 스프링 부트가 주무기가 되었다. 하

스프링 부트의 핵심이라고도 볼 수 있는 테스트! 테스트를 안 쓰고 스프링 개발을 진행한다면 그건 반쪽짜리 스프링 개발자로 볼 수 있다.테스트를 자동화할 수 있다. -> 빠르게 테스트가 가능하다전체 코드를 작성하지 않아도 메소드 하나라도 테스트가 가능하다리팩토링 시 유용

예를 들어서 한 코드가 있다. 그 코드는 A - B - C 이런 형태를 가지고 있다. 그런데 우리는 새로운 코드를 가지고 싶어졌다. 그 코드의 형태는 A - D - C 의 형태이다. 앞선 코드와 가운데 부분만 다른 형태다. 이것 때문에 함수 하나를 통째로 새로 작성하는

우리가 구현한 프로그램을 사용자들이 사용할 때 우리가 예상치 못한 행동으로 오류를 발생시킬 때가 있다. 물론 최고의 방법은 우리가 그때마다 그에 맞는 대체를 하는 것이다. 하지만 동시 사용자가 수만명에 이르고 개발자들은 그에 비해 턱없이 부족하다면? 그래서 우리는 예외

비즈니스 로직과 데이터 액세스 로직을 분리하기 위해서 서비스 계층을 따로 둔다. 이 때 서비스 계층에서 다양한 트랜잭션을 사용할 경우 원자성에 따라서 해당 로직을 하나의 트랜잭션으로 묶는 작업이 필요하다. 즉 트랜잭션 경계 설정이 필요하다!이 때 트랜잭션에 대한 정보를

만약 로그를 찍는 코드와 비즈니스 로직을 수행하는 코드가 있다고 하자. 비즈니스 로직을 수행하는 코드는 핵심 코드, 로그를 찍는 코드는 부가 기능 코드로 볼 수 있다. 이를 분리해서 결합도를 낮춰보자. 가장 흔하게 쓰이는 방법으로는 함수로 빼는 방식이 있고 다형성을 위