코드를 구현한 후 로그를 확인하기 위해 새로고침을 했다. 실수로 연속 두 번을 눌러버렸다.그랬더니 예상치 못한 결과가 출력되었다. 예상한 결과와 달리 순서가 뒤죽박죽 섞인 로그가 출력되었다. 심지어 다른 스레드인데 트랜잭션 ID가 일치한다. 대체 무슨 일이 생긴 걸까? 동시성 문제 동시성 문제가 일어나는 과정은 다음과 같다.1. 스레드 A가 서비스 객체에 접근하여 데이터를 저장하고 조회하려고 한다.2. 스레드 A가 서비스 객체에 접근하여 데이터를 저장했다.3. 스레드 A가 저장한 데이터를 조회하기 전에 스레드 B가 서비스 객체에 접근하여 데이터를 저장했다.4. 스레드 A는 본인이 저장한 데이터가 아닌, 스레드 B가 저장한 데이터를 조회한다.5. 스레드 B는 본인이 저장한 데이터를 조회한다. 🙋🏻..
문제 링크스티커 한 장을 떼면, 그 스티커와 변을 공유하는 스티커는 모두 찢어져서 사용할 수 없게 된다. 즉, 뗀 스티커의 왼쪽, 오른쪽, 위, 아래에 있는 스티커는 사용할 수 없게 된다. 모든 스티커를 붙일 수 없게 된 상냥이는 각 스티커에 점수를 매기고, 점수의 합이 최대가 되게 스티커를 떼어내려고 한다.문제에 제시된 조건과 요구 결과이다. 최대 점수를 얻을 수 있도록 스티커를 떼야한다. 처음엔 공유하는 스티커가 찢어져 사용할 수 없으니 BFS인가..? 했는데 전혀 아니었고, 그럼 그리디인가..? 했는데 무조건 높은 점수를 더해가면 나중에 틀리는 반례가 있었다. 즉, 모든 스티커에 방문할 때마다 최댓값을 비교하며 변경해야 하는 다이내믹 프로그래밍이었다. 예시를 통해 그리디가 아닌 이유를 알 수 있다...
실무자의 경험이 많이 담겨있는 책이라 학부생 위치에서 이해하기 어려운 부분도 있었다. 하지만 서비스 기획팀과 개발자 간의 소통 부재로 인한 문제 상황, 면접관 관점에서의 면접 등 알기 어려운 부분을 알게 되었다. 소프트웨어 장인흥분을 감추지 못하고 나무르의 사무실로 가서 “다 끝냈습니다. 동작도 합니다.”라고 외치자, 그는 타이핑을 멈추고 나를 돌아봤다. “코딩이 직업인 사람이 동작하는 코드를 만드는 건 기본이에요.” 그는 조용히 말했다. “일을 끝냈다는 말에는 제대로 동작한다는 것이 당연히 포함되어 있죠.” 시비를 거는 말투였다.“여기 앉아서 작업한 코드를 같이 봅시다.” 나무르 옆에 앉았다. 내가 작성한 코드는 200줄 남짓이었다. 나무르는 첫 번째 라인으로 커서를 옮기고 한 줄 한 줄 보기 시작했..
토비 AOP까지 읽는게 목표였고 해당 파트인 6장을 읽고 있는데 다이내믹 프록시가 매우 매우 어렵다..책 내용이 아니라 혼자 이해한 내용을 정리한거니 혹시라도 틀린 부분을 알려주시면 감사하겠습니다. ㅜㅜ 다이내믹 프록시를 사용하는 이유프록시 디자인 패턴의 치명적인 단점을 보완하기 위해 사용한다. 프록시 디자인 패턴은 원본 클래스 수만큼 프록시 클래스를 하나하나 만들어줘야 한다. 프록시 적용 대상 객체가 1억 개면 프록시 객체도 1억 개 만들어줘야 한다. 이러한 코드의 복잡도 한계를 해결하기 위해 사용하는 것이 다이내믹 프록시다. 다이내믹 프록시는 컴파일 시점이 아닌 런타임 시점에 자바 가상 머신이 지원해 준다. 애플리케이션 실행 도중 java.lang.reflect.Proxy 패키지에서 제공해 주는 AP..
내용을 정리한 글은 워낙 많아서 깨달음을 얻은 부분 위주로 정리했다. 예외를 처리할 때 반드시 지켜야 할 핵심 원칙 모든 예외는 적절하게 복구되든지, 아니면 작업을 중단시키고 개발자에게 분명하게 통보되어야 한다. 예외를 무시하거나 출력하고 넘어가는 코드는 만들지 말자. Exception과 체크 예외 체크 예외가 발생할 수 있는 메서드를 사용할 경우 반드시 예외를 처리하는 코드를 함께 작성해야 한다. 사용할 메서드가 체크 예외를 던진다면 이를 catch 문으로 잡든지, 아니면 다시 throws를 정의해서 메서드 밖으로 던져야 한다. 그렇지 않으면 컴파일 에러가 발생한다. RuntimeException과 언체크/런타임 예외 런타임 예외는 catch 문으로 잡거나 throws로 선언하지 않아도 된다.
내용을 정리한 글은 워낙 많아서 깨달음을 얻은 부분 위주로 정리했다. 전략패턴 특징 오브젝트를 아예 둘로 분리하고 클래스 레벨에서는 인터페이스를 통해서만 의존하도록 만드는 패턴 GoF의 디자인 패턴 책에서는 전략 패턴을 다음과 같이 정의한다. 동일 계열의 알고리즘군을 정의하고 → 전략 구현체로 정의하고 각각의 알고리즘을 캡슐화하여 → 인터페이스로 추상화 이들을 상호 교환이 가능하도록 만든다. → 합성(composition)으로 구성 알고리즘을 사용하는 클라이언트와 상관없이 독립적으로 → 컨텍스트 객체 수정 없이 알고리즘을 다양하게 변경할 수 있게 한다. → 메서드를 통해 전략 객체를 실시간으로 변경함으로써 전략 변경 쉽게 말하면 객체지향의 기법인 SOLID 원칙과 합성, 다형성, 캡슐화 등 OOP 기술들..
내용을 정리한 글은 워낙 많아서 깨달음을 얻은 부분 위주로 정리했다. 스프링으로 개발을 하면서 테스트를 만들지 않는다면 이는 스프링이 지닌 가치의 절반을 포기하는 셈이다. 테스트란 내가 예상하고 의도했던 대로 코드가 정확히 동작하는지 확인해서, 만든 코드를 확신하게 해주는 작업이다. 코드의 결함을 제거하기 위해 디버깅을 거치게 되고, 최종적으로 테스트가 성공하면 모든 결함이 제거되었다는 것을 알 수 있다. 단위 테스트 테스트의 관심이 다르다면 테스트할 대상을 분리하고 집중해서 접근해야 한다. 단위는 작을수록 좋다. 단, DB상태가 매번 달라진다면 단위 테스트로서의 가치가 없어진다. 단위 테스트를 하는 진짜 목적 : 에러 원인을 빨리 찾기 위해서이다. 인터페이스를 활용하여 DI를 적용해야 하는 이유 소프트..
내용을 정리한 글은 워낙 많아서 깨달음을 얻은 부분 위주로 정리했다. 개발자가 객체를 설계할 때 가장 염두에 둬야 할 사항은 바로 미래의 변화를 어떻게 대비할 것인가이다. 변경이 일어날 때 필요한 작업을 최소화하고, 그 변경이 다른 곳에 문제를 일으키지 않게 하기 위해서는 설계를 할 때 분리와 확장을 고려해야 한다. 변화가 한 번에 한 가지 관심에 집중돼서 일어난다면, 우리가 준비해야 할 일은 한 가지 관심이 한 군데에 집중되게 하는 것이다. 하나의 관심사가 방만하게 중복되어 있고, 여기저기 흩어져 있어서 다른 관심의 대상과 얽혀 있으면, 변경이 일어날 때마다 엄청난 고통을 일으키는 원인이 된다. UserDao는 Connection 인터페이스 타입의 오브젝트라는 것 외에는 관심을 두지 않는다. → 그저 ..
