Intro 프로젝트를 진행하다보면 분리에 대한 고민이 드는 시점이 종종 있습니다. 당장 필요해서 열심히 구현하고보니 다른 프로젝트에서도 자주 쓰일 것 같을 때도 있고, 다른프로젝트에서 여기에 있는 기능을 가져다 쓰려고 하는데 전부 포함시키기에는 불필요한 의존성이 너무 많을 때도 있습니다. 가장 쉬운 방법은 Copy And Paste(CNP방법론) 이 있겠지만, 그렇게 복사해낸 코드에 변경사항이라도 필요하면 일일히 복사된곳을 찾아가서 하나하나 고쳐줘야 하는 번거로움이 있습니다. DRY(Don't Repeat Yourself) 원칙을 위배하면 나중에 수습하기가 참 고생입니다. 특히, 서로간 통신이 빈번해 동일한 도메인을 공유해야하는 프로젝트간에는 이 공통된 객체간의 동기화가 보장되는게 정말 중요합니다..

Intro Code Coverage 코드 커버리지는 작성한 소스코드중 얼마나 많은 부분이 자동화된 테스트에서 실질적으로 실행되었는지를 측정할 수 있는 지표 입니다. 높은 코드 커버리지는 테스트가 실행되는 동안 소스코드의 더 많은 부분이 실제적으로 실행된것을 의미하기 때문에 보다 낮은 커버리지의 프로그램에 비해 버그가 발생할 확률이 더 낮다고 기대할 수 있습니다. 물론 높은 커버리지가 더 좋은 테스트임을 보장하는 것은 아닙니다. 특히 최근의 트랜드처럼 급한 템포의 개발이 이루어지는 상황에서도 빠르게 만들어낼 뿐만 아니라 신뢰수준이 높고 좋은 퀄리티의 코드를 작성하기 위해서는 정말 중요한 지표라고 생각됩니다. 진행중인 사이드 프로젝트에서 코드 커버리지를 측정하고 해당 지표를 조금씩 개선해보는 실습을 진행 해..

Intro 자바에서 기본형 타입과 래퍼클래스 간에는 변환이 자동으로 이루어지기 때문에 그 차이를 굳이 인식하지 않고도 어렵지 않게 코드를 작성할 수 있습니다. 그나마 스트림을 사용할 때나 필요에 의해 명시적으로 .boxed() 나 .mapToInt() 를 호출하게 되는데요. 모두 아시는 것처럼 primitive와 각각의 Wrapper 클래스는 많은 차이가 있습니다. 그 차이점에 대해 자세히 다루어 보려고 합니다. 둘의 차이에 대해 이해하기 위해서는, 먼저 자바의 스택 메모리와 힙 메모리에 대한 이해가 필요합니다. Stack Memory vs Heap Space JVM은 메모리를 효율적이고 효과적으로 관리하기 위해 Stack과 Heap으로 불리는 두 가지 영역으로 메모리를 분리했습니다. 우리가 새로운 변수..

Intro 스프링기반 프로젝트를 만들다 보면 기계적으로 필요에 따라 각종 어노테이션을 붙이게 됩니다. 컨트롤러에는 @Controller를, 서비스 레이어에는 @Service를, 그리고 데이터베이스에 접근하는 퍼시스턴스 레이어에서는 @Repository를 붙였습니다. 그 외 어플리케이션 컨텍스트에 빈으로 등록 하고 싶은데 특별한 설정 절차가 필요 없어서 컴포넌트 스캔을 통한 자동 등록이면 충분 할 때에는 @Component를 붙여 왔습니다. 그런데, 사실 Bean 으로 등록되어 후에 Dependency Injection에 사용된다는 공통점을 생각 해 보았을 때는 "전부 @Component"로 해도 되는거 아니야?" 라는 생각이 들 수 있습니다. 각각의 차이도 모른채 습관적으로만 사용하고 있는게 사실입니다...

Intro 프로젝트에서 파일 업로드 부분에 대한 개선을 진행 했습니다. 기존의 파일 업로드를 처리하는 부분에 몇가지 문제가 있었는데, 특히 대용량 파일을 안정적으로 업로드 하기 위해서 해결해야 하는 포인트들이 여러가지가 있었고, 꽤나 난해했습니다. 사용자가 파일 업로드를 마쳤지만, 서버에서 일어나는 다양한 작업을 마칠때까지 오랜 시간동안 응답을 받지 못함 사용자 입장에서 업로드 100% 에서 오랜시간 화면이 멈추어 있어 UX가 좋지 않음 대용량의 파일을 업로드할 때 응답에 걸리는 시간이 너무 오래걸려 timeout 되는 문제 사용자는 파일을 성공적으로 업로드 했지만, 서버에서 해당 파일을 처리중 문제가 생겼을 때의 방안 대용량의 파일 업로드시 대량의 IO 작업으로 시스템 자원이 쏠리는 현상 간단히 추려보..