같이 일하고 싶은 개발자

목차 들어가기 JPA CascadeType.REMOVE orphanRemoval = ture 마무리 들어가기 우리는 JPA에서 양방향 매핑시 cascade 전략을 이용해 부모가 자식 객체의 생명 주기를 관리할 수 있다. 이 때 전제 조건은 양방향관계를 맺고 있다에서 출발되는데, 양방향 전략 사용 시 둘 중 하나를 하나로 외래 키를 관리해야 한다. 문득 궁금했다. 이 Cascade 전략에 관련해서, 그러다 지식을 습득하는 과정에서 orphanRemoval이라는 키워드도 얻게 되었는데, 이 둘의 차이점이 무엇인지 정리함으로써 내 것으로 만들기 위해 이렇게 글을 정리하는 시간을 갖게 되었다. JPA CascadeType.REMOVE 이 CasCaseType.Remove를 지정했을 때, 부모 엔티티가 삭제되면 ..

목차 들어가기 Spring Security Context Holder 마무리 들어가기 앞서 [#1]에서 간략하게 어떻게 필터들이 동작하고, 시큐리티가 동작하는지를 확인할 수 있었다. 이 속에서 우리는 Context라는 것을 알게 되었다. 시큐리티는 사용자의 정보를 담기위해 Security Context라는 것을 만들어서 사용자의 Authenticaton(인증) 객체를 확인하고, 저장하는 과정을 가지게 되며, 이 인증된 객체를 전역에서 꺼내쓸 수 있다. 이러한 이유는 인증된 객체는 ThreadLocal에 저장되어 있기 때문이라고 간단하게 언급했었는데, 해당 객체에 관한 인증이 완료되면 HttpSession에 저장되어 애플리케이션 전역에서 참조가 가능한 것이다. 그럼 어떻게 내부적으로 동작을 하는 것일까? ..

목차 들어가기 What is Spring Security 마무리 들어가기 로그인? 보안? Spring Security? 우리는 서비스를 이용하다보면 로그인을 마주하게 된다. 이 로그인을 통해 사용자를 분석하고, 불법적인 각종 행위들을 막으며 여러모로 유용한 기능 중 하나라고 생각한다. 그러나 이 중요한 로그인을 기능으로 구현한다면 어떻게 해야할까? 내가 아는 범주에선 우선 그냥 먼저 사용자 table을 만들어서 사용할 ID와 PW을 저장한 후, 사용자가 해당 페이지 혹은 기능으로 접근할 때, 저장된 데이터와 접근한 사람의 데이터를 대조하는 방식으로 진행할 것이다. 이렇게 일일히 모든 기능마다 검증 로직이 필요하고, 보안은 물론 이게 로그인이 맞나? 싶을 정도다... 로그인 관련 기능을 구현하던 중 Spr..

오늘은 직접 간단한 @Test 예제를 통해 직접 테스트를 해보고, 왜 이 테스트가 필한지 이 리팩토링이 왜 필요한지를 직접 몸으로 느끼게 되었다. 개발자의 입장에선 불필요한 자원의 낭비나, 내가 구상한 방향으로 flow가 진행되지 않는다면 잘못된 결과를 초래할 수 있는데, 이는 곧 책임에 맞지 않는 코드를 사용하는 것과 같은 맥락이다. 보통 main() 메서드에 해당 메서드에 값을 전달해서 찍어보는 방식을 사용하거나 @slf4j라는 log를 찍도록 도와주는 어노테이션을 사용해서 올바른 데이터가 들어오는지 등 방식을 사용했다. 물론 이러한 방식이 잘못되었다는 것은 아니나, 만약 코드가 엄청 복잡해지고, 길어진다면? 과연 코드만 분리한다고 해서 우리가 가진 근본적인 문제를 해결할 수 있을까? 등 여러 고민들..

서비스를 개발하다 보면 우리는 구현한 기능 혹은 메소드를 테스트해야할 경우가 발생할텐데, 이는 개발자로서 중요한 순서이자 역량이다. 하지만 이를 접하지 않는다면 코드 구현력은 물론 더 큰 문제가 발생할 가능성이 높다. 그래서 테스트를 통해 내가 만든 기능들이 올바른 방향으로 흘러가는지에 관해 check 할 필요가 있는데, 이 과정 속에서 Test가 중요하다. 또한 내가 만든 메소드가 비효율적이라면 이는 추후 큰 비용의 발생을 야기할 수 있다 (내가 말하는 큰 비용이라하면 유지보수나, 사용되는 리소스를 의미한다.) 그래서 개발자 입장에선 불필요하거나, 책임에 맞지 않는 코드를 사용하는 것을 줄여야한다. 간단한 예제를 통해 문제점을 발견하고 직접 Test, refactoring까지  경험해 보았다. publ..

서비스를 만들다보면 데이터를 불러오거나, 핸들링하거나 등 여러 행위를 해본 경험이 누구나 있을 것이다. 이 속에서 배우길 데이터를 탐색하려고 하면 For 문이라는 반복문을 이용한 경험이 있을 것인데, 만약 이 loop가 길어지고, 주어진 조건이 많아진다면 어떻게 해야할까?에 대한 고민을 한번쯤을 해볼법도한데... 당연히 반복문 속 내용이 많아진다면 코드의 가독성도 떨어지고, 재사용도 힘들 것이며, 아무쪼록 그냥 그닥 좋은 코드가 못될수도있다. 자바에서는 이러한 문제점을 해결하기 위해서 버전 8부터 Stream이라는 개념을 지원해준다. 평소에 나는 스트림에 대해 익숙치 못해서 For문을 이용해 루프를 탐색하곤 했는데, 당연히 코드의 가독성도 떨어지고 그냥 마음에 들지않았다.. 항상 어떻게하면 이 loop를..

🤥개요 들어가기 일반적으로 우리는 데이터를 탐색하고자 할 때, 반복문을 사용할 것이다. 그러나 루프가 길어지고 주어진 조건식이 많아진다면 당연히 이 루프속 내용은 많아질 것이고, 가독성 또한 떨어지며 코드의 재사용도 힘든데 이러한 문제점을 해결하기 위해 Java 8 버전부터 Steam(스트림)이라는 개념을 지원해준다. 어떻게하면 우리는 이 Steam을 잘 활용할 수 있을까에 대한 고민을 담은 글이다.? 스트림을 왜 써야할까? 등 Stream의 내용을 학습하고, 내가 고민한 내용을 바탕으로 적용해보기 위해서 정리한 글이다. 본 글은 구글링 및 10분 테코톡 11강, 12강 Stream에 관련한 영상을 시청 후 정리한 내용이다. 본 내용에서 사용한 사진은 테코톡에서 발췌한 사진임을 명시한다. 본 글은 왜 이..

FACTS(사실, 객관) : 이번 일주일 동안 있었던 일, 내가 한 일 심화 과제 -> Security 구현 이유있는 코드, 그리고 리팩토링 시큐리티는 어렵다 -> 회사꺼 그냥 쓰는게 답일까? 감기 그리고 감기 감기감김가믹마김감김가 집에만 있었는데 뭔 감기야 .. DTO는 불변객체로 만드는 것이 좋다. Jackson lib가 해주는 일들 @Transactional @JDK Dynamic Proxy & CGLIB FEELINGS(느낌, 주관) : 나의 감정적인 반응, 느낌 너무 민감한 시큐리티... 망할...X DTO를 왜 불변객체로 만들어야할까에 대한 고민, Jackson lib.. @JDK Dynamic Proxy & CGLIB 어렵다... FINDINGS(배운 것) : 그 상황으로부터 내가 배운 것,..

자바 혹은 스프링을 공부하다보면 뭐 String은 Immutable하다. 불변 객체이다 등 불변이라는 단어를 자주 들어봤을 것이다. 이러한 내용 속에서 습득하고, 익힌 정보들은 다음과 같다. 객체 지향 프로그래밍에서 정의하는 불변 객체(Immutable object)는 다음과 같다. 1. 불변 객체 ( Immutable Object ) 불변 객체는 생성 후 상태를 바꿀 수 없는 객체를 말한다. ( 반대 개념은 가변 객체 ) 불변 객체의 장점은 다음과 같다 조작의 단순화 성능 개선 많은 객체 지향 언어들에서 객체는 참조(reference) 형태로 전달하고 받는다. 그래서 이 참조를 통해 공유돼어 있다면 그 상태가 언제든지 변경될 가능성이 존재한다. 불변 객체는 객체를 복제할 때 객체 전체가 아니라 단순히 ..

공부한 내용을 꾸준히 기록으로 남기기 너무 어렵다. 해당 내용을 정리해야지 해놓고 까먹기 일수다... 요 근래간 코드에 관해 많은 고민을 했었고, 많은 인사이트를 넓힐 수 있던 기간이었다. 오늘 개인 프로젝트 제출이였는데, 요 근래 발생한 문제를 해결하느라 프로젝트에 집중 못했고, 그 결과 완성을 하지 못했다. (사실 완성할 수 있었는데, 그 방법으로 하기 싫었고, 새로운 방법으로 하고 싶었다.) 요즘엔 [10분 테코톡]을 시청하고 정리하며 친구들과 스터디를 진행하고 있다. 각자 시청하고 싶은 토픽을 정해서 시청하고, 내용을 정리하며 서로 공유하는데, 뭔가 스터디 느낌이면서도 아닌듯한 그냥 그렇다.. 약간의 동기부여? (하지만 재밌다) 이러한 내용들을 보면서 모르는 내용을 그냥 넘어가지말고 이해할 때까지..