개요? 최근에 프로젝트를 진행하면서, 리눅스 커널단의 설정에 의해 이슈가 발생하였다. 그래서 이번 기회에 TCP_TW 설정에 대해 알아보고자 한다. 이전에 이슈가 된 설정은 , 옵션이었는데, 이 옵션들은 상태의 소켓을 재사용하는 옵션이다. TIME_WAIT? TIME_WAIT 상태는 TCP 연결이 종료된 후, 일정 시간 동안 유지되는 상태이다. 이슈 최근 azure 의 를 세팅하면서 외부 요청에 대한 타임아웃이 발생하는 이슈가 있었다. 환경 AKS에 하나의 파드에 두개의 컨테이너를 띄운 상태 NAT 게이트웨이를 사용 이슈 시나리오 A컨테이너에서만 외부API를 호출하면 바로바로 응답이 옴 B컨테이너에서만 외부API를 호출하면 바로바로 응답이 옴 A컨테이너에서 외부API호출 후 바로 B컨테이너에서 외부API를 호출하면 타임아웃이 발생함 AKS초기 구성시에는 해당 현상이 발생하지 않았었다. 그런데, 어느 순간 해당 현상이 발생하기 시작했다. 서버 구축을 해주던 인프라팀에서 “tcp…

1. IoC(Inversion of Control)란? 의존성 관리를 외부에 하여 객체의 생성과 관리를 제어하는 개발 패턴 2. 누가? 왜? 누구한테 위임하는가? 주로 프레임 워크에 위임합니다. 대표적으로 Spring 프로레임워크라고 볼 수 있겠습니다. 왜 위임하는가? 개인적으로 생각하는 위임하는 주요 장점중 하나는 개발자가 비즈니스 로직에 집중할 수 있다는 것입니다. 그렇다면, 정도로 보면 되겠네요. 3. 예시 DI에서 활용했던 코드를 사용해서 탐구해보겠습니다. 일반적으로 개발자가 객체를 생성관리 한다면 다음과 같을 것입니다. 그렇다면, 객체생성을 프레임워크에 위임하다고 하는데 그러한 패턴을 코드로 우선 보겠습니다. 란 객체에게 의 을 달라고 하네요 🤔 그런데 여기서 중요한 부분은 확실하게 를 사용하지 않은것으로 봐서는 객체 생성을 프레임워크에 위임한 것으로 볼 수 있습니다. 🚫그런데 실행했더니 에러가 발생하네요 🤔 Spring 의 마법을 보기위해서 무언가 설정이 더 필요한가…

1. DI(Dependency Injection)란? 의존성 관리를 위해 사용되는 디자인 패턴입니다. DI의 핵심 아이디어는 “제어의 역전(Inversion of Control)“입니다. 일반적으로 객체는 자신이 사용할 의존성을 직접 생성하거나 찾아내는 책임을 갖고 있습니다. 하지만 DI에서는 객체는 의존성을 요청하기 위해 컨테이너 또는 프레임워크에 의존합니다. 이렇게 함으로써 객체는 자신이 사용할 의존성을 외부에서 제공받게 되고, 의존성의 생성과 관리는 외부에 됩니다. DI를 통해 객체 간의 결합도를 낮출 수 있으며, 유닛 테스트 작성과 코드 재사용을 쉽게 할 수 있습니다. 또한 DI 컨테이너를 사용하면 의존성의 라이프사이클 관리와 의존성 간의 관계 설정을 자동화할 수 있습니다. DI 프레임워크로는 Spring, Nest 등이 있습니다. 좋은 DI 설계는 모듈화와 확장성을 개선하며, 코드를 더 테스트 가능하고 유지보수하기 쉽게 만들어줍니다. 2. 예시를 통해 알아보는 DI 장점.…

CSRF(사이트 간 요청 위조(Cross-Site Request Forgery)? 웹 애플리케이션 취약점 중 하나로 사용자가 자신의 의지와 무관하게 공격자가 의도한 행동을 해서 특정 웹페이지를 보안에 취약하게 한다거나 수정, 삭제 등의 작업을 하게 만드는 공격 방법이다. 2008년에 발생한 옥션의 개인정보 유출 사건에서도 관리자 계정을 탈취하는 데 이 방법이 사용되었다. 공격의 난이도가 높지 않아 흔히 사용된다. -나무위키- 사례 2006 년 Netflix 웹사이트에는 CSRF에 대한 수많은 취약점이 있었습니다. 이 취약점으로 인해 공격자는 피해자의 대여 대기열에 DVD를 추가하거나, 계정의 배송 주소를 변경하거나, 계정을 완전히 손상시키기 위해 피해자의 로그인 자격 증명을 변경하는 등의 작업을 수행할 수 있었습니다. ING Direct 의 온라인 뱅킹 웹 애플리케이션은 불법 자금 이체를 허용하는 CSRF 공격에 취약했습니다. 인기 동영상 웹사이트 YouTube 도 2008년에 C…

XSS? XSS(Cross-site Scripting)란 SQL injection과 함께 웹 상에서 가장 기초적인 취약점 공격 방법의 일종으로, 악의적인 사용자가 공격하려는 사이트에 스크립트를 넣는 기법을 말한다. 공격에 성공하면 사이트에 접속한 사용자는 삽입된 코드를 실행하게 되며, 보통 의도치 않은 행동을 수행시키거나 쿠키나 세션 토큰 등의 민감한 정보를 탈취한다. 공격방법 Stored XSS Stored XSS는 사이트 게시판이나 댓글, 닉네임 등 스크립트가 서버에 저장되어 실행되는 방식 Reflected XSS Reflected XSS는 보통 URL 파라미터(특히 GET 방식)에 스크립트를 넣어 서버에 저장하지 않고 그 즉시 스크립트를 만드는 방식 대부분은 Stored XSS라고 생각하면 된다. Reflected XSS의 경우 브라우저 자체에서 차단하는 경우가 많아 상대적으로 공격을 성공시키기 어렵다. -나무위키- 대응방법 문자입력을 작성한 그대로 입력하지 않는다 문자를 필…

“Unit Testing - 블라디미르 코리코프 지음” 책을 학습하여 일부 내용을 요약하였습니다. 단위 테스트의 목표 테스트로 대부분의 회귀에 대한 보험을 제공하는 도구라 할 수 있다. 새로운 요구 사항에 더 잘 맞게 리팩터링한 후에도 기존 기능이 잘 작동하는지 확인하는데 도움이 된다. 테스트 초반에 (상당한)노력이 필요하다. 그러나 프로젝트 후반에도 잘 성장할 수 있도록 하므로 장기적으로 보면 그 비용을 메울 수 있다. 지속성과 확장성이 핵심이며, 이를 통해 장기적으로 개발 속도를 유지 할 수 있다. 잘못 된 테스트 잘못된 테스트는 초반에 코드가 나빠지는것을 늦출 수는 있다. 테스트가 없는 상황에 비해 개발 속도가 덜 느려진다. 그러나, 잘못 된 테스트로 진행한다면 시간이 지남에 따라 프로젝트 침체단계를 필할 수는 없다. 제품 코드 대 테스트 코드 제품코드와 테스트 코드는 다르다고 생각하지만 다르지 않다. 테스트 코드가 많을수록 좋다고 생각하지만, 그렇지 않다. 코드는 자산이 아…

TDD 란? TDD 란 Test Driven Development 의 약자로 “테스트 주도 개발”이라고 합니다. TDD 의 장점 출처 코드 품질 TDD 는 개발자가 단순한 설계를 할 수 있도록 도와줍니다. 일반적으로 OOP 구조를 유지할 수 있습니다. 애플리케이션 품질 TDD 는 프로덕션 코드를 구현하기 전에 먼저 테스트를 해보고 프로덕션 코드를 구현 할 수 있습니다. TDD 를 통해 프로덕션 코드를 점진적으로 개발해 나가므로써, 철저한 테스트와 적은 버그를 발생 시킬 수 있습니다. 생산성 향상 디버깅 시간을 줄일 수 있습니다. TDD 로 개발을 시작하면 초기에는 시간이 많이 소요 될 수 있습니다. 하지만, 새로운 기능 추가 및 테스트 시간이 더 빨라지고 든든한 테스트가 있기때문에 리팩토링에 부담을 줄일 수 있습니다. 문서 테스트 코드는 문서 역할을 할 수 있습니다. 잘 정리된 테스트코드 가 있다면, 테스트 코드로 프로젝트를 이해 할 수 있습니다. 뿐만 아니라 모든 코드를 이해 하…

학습목적으로 작성되어 생략된 내용과 다소 부적확한 내용이 있을 수 있습니다. 다루는 내용 @Entity, Jpa 연관관계, 편의메소드, @Embedded , @Embeddable 예제로 사용해볼 관계도 테이블 과 테이블이 있습니다. 이때 는 여러개 의 을 작성 할 수 있습니다. 위의 테이블 구조로는 가 작성한 이 어떤것 인지 알수 없습니다. 그래서 이때 relation id 를 둘중 하나의 테이블에 저장 해두어야 합니다. 한명의 가 여러개의 를 가질 수 있으므로, 테이블에 관계 ID를 저장하도록 변경합니다. 테이블에 컬럼은 테이블의 고유 입니다. 데이터 User 테이블 id name password 1 name1 pass1 2 name2 pass2 3 name3 pass3 Post 테이블 |id|user_id|title|contents| |------|---|---| |1|3|제목 123|내용| |1|3|제목 748|내용| |2|1|제목 189|내용| |3|2|제목…

참조블로그 : https://asfirstalways.tistory.com/350 빌더 패턴 한번에 인스턴스를 생성하고 싶은데 생성자 인자가 너무 많을때 혹은 기본 생성자로 인스턴스를 만들고 setter 로 점진적으로 값을 주입시킬때 이럴때 빌더 패턴을 사용하면 장점이 있습니다. 빌더 패턴을 사용하지 않은 예 생성자 생성 인자가 너무 많다보니, 순차적으로 뭐가 들어가는지도 헷갈리기 시작합니다. 혹여나 실수로 위치를 다르게 넣을 수 도 있을것 같습니다. 빌더 패턴 적용 예 빌더 패턴을 사용하면 많은 생성자 인자를 명시적으로 맵핑 할 수 있는 장점이 있고, 기본 생성자를 만들고 로 순차적으로 맵핑하는 것보다 한번에 인스턴스를 생성 할 수있습니다. 한번에 그리고 명시적으로 파라미터를 맵핑 할 수 있는 장점이 있는 빌더 패턴을 알아보았습니다.

정적 메소드 팩토리 정적 메소드 팩토리를 사용하면, 의미있는 이름의 생성자를 제공 할 수 있는 장점이 있습니다. 참조 글 baeldung.com/java-constructors-vs-static-factory-methods 1.생성자에는 의미 있는 이름 이 없으므로 항상 언어에서 부과하는 표준 명명 규칙으로 제한됩니다. 정적 팩토리 메소드는 의미 있는 이름을 가질 수 있으므로 그들이 하는 일을 명시적으로 전달합니다. 2.정적 팩토리 메서드는 메서드, 하위 유형 및 기본 형식을 구현하는 동일한 유형을 반환할 수 있으므로 보다 유연한 반환 유형 범위를 제공합니다. 3.정적 팩토리 메서드는 완전히 초기화된 인스턴스를 미리 구성하는 데 필요한 모든 논리를 캡슐화 할 수 있으므로 생성자에서 이 추가 논리를 이동하는 데 사용할 수 있습니다. 이것은 생성자가 필드를 초기화하는 것 이외의 추가 작업 을 수행하는 것을 방지 합니다. 4.정적 팩토리 메소드는 제어된 인스턴스 메소드 일 수 있으며 싱…

of 와 from 의미가 뭘까? 문득 코딩을 하다 궁금해졌습니다. 메소드의 이름으로 사용되는 of 와 from 의 의미에 대해서 알고 싶어졌습니다. 구글 검색결과 oracle - java documentation stackoverflow 등등 에서 정보를 찾을 수 있었습니다. 오라글 문서에서 정의하는 메소드 네이밍 컨벤션은 아래와 같습니다. Prefix Method Type Use of static factory 팩토리가 주로 입력 매개변수의 유효성을 검사하고 변환하지 않는 인스턴스를 만듭니다. from static factory 입력 매개변수를 대상 클래스의 인스턴스로 변환합니다. 이 경우 입력에서 정보가 손실될 수 있습니다. parse static factory 입력 문자열을 구문 분석하여 대상 클래스의 인스턴스를 생성합니다. format instance 지정된 포맷터를 사용하여 임시 개체의 값을 형식화하여 문자열을 생성합니다. get instance 대상 객체 상태의 일부를 …

위 코드 출력 결과 는 입니다. Collections.unmodifiableList 으로 반환된 객체는 결국 원본객체의 참조입니다. 그러므로 원본 객체가 수정되면 으로 반횐된 도 동일한 값을 가집니다. 그러나, 는 불변객체 이므로 수정 삭제가 불가능합니다.

Java Enum 활용기 참고하여 작성되었습니다. 자바 이넘 자비 enum 을 활용하면 상태와 행위를 한곳에서 관리할 수 있는 장점에 대해서 알아 보겠습니다. 예시로 로또 상금 로직 구현해보면서 파악해보겠습니다. 우선 Enum 미적용된 코드부터 살펴 보겠습니다. Enum 으로 적용안되었을 경우 클래스는 맞춘 로또 숫자에 따라 상금을 반환해주는 메소드를 가지고 있습니다. 우선 위 코드는 확장성에 취약한 상태입니다. 만약에 4등의 상금이 줘야하는 추가 요구상황이 주어졌다면 어떻게 될까요? 이처럼 상태와 로직을 각각 수정해주어야 합니다. 클래스의 인스턴스 변수와 메소드가 같이 있어서 그나마 나아보일 수도 있지만, 위 예제는 단순한 예제이고 복잡해질 경우 유지보수와 확장성에서 어려움을 격을 수 있습니다. Enum 을 활용한다면 어떻게 될까요? 테스트 코드 위 Enum 에도 4등이 빠져 있습니다. 4등을 추가 해주고 싶다면 위 코드만 추가해주면 확장 할 수 있습니다. 이는 상태와 로직…

로 다양하게 테스트 해보기 다양한 파라미터로 테스트 할때 유용하게 사용됩니다. 5보다 작은 숫자 테스트 위 코드 처럼 6이하의 케이스를 테스트 하고싶다고 할때, 중복된 코드가 많이 발생하게 됩니다. 이러한 부분을 을 사용해서 리팩토링 해보겠습니다. 를 활용해서 테스트가 진행될때 숫차적으로 인자로 부여되면서 진행됩니다. 이 외에도 등 다른타입도 적용가능합니다. 한개 이상의 인자를 사용하고 싶을때? 위 예제는 5보다 작은 숫자 테스트 였습니다. 그런데 {숫자}보다 작은 숫자 테스트 하고싶을때는 아래와 같은 방법을 사용 할 수 있습니다. 의 기본 구분자는 입니다. 만약 다른 구분자를 사용하고 싶을때는 를 통해 다른 구분자를 사용해서 분리 시킬수 있습니다. Primitive type 타입 외 객체 부여하기 을 사용하면 다양하게 인자를 사용할 수 있습니다. 메소드처럼 인자를 정의하고 를 통해 메소드 이름을 정의하면, Primitive type 말고도 다양하게 테스트 할 …

#이터레이터(Iterator) 란? 반복자(iterator)는 객체 지향적 프로그래밍에서 배열이나 그와 유사한 자료 구조의 내부의 요소를 순회(traversing)하는 객체이다. (위키백과) Iterator 는 컬렉션 프레임워크에 속하는 인터페이스입니다. 컬렉션을 탐색하고 데이터 요소에 액세스하며 컬렉션의 데이터 요소를 제거할 수 있습니다. Iterator 메소드 Iterator.hasNext() : 다음 요소가 있으면 true 를 반환 Iterator.next() : 다음 요소를 반환 Iterator.remove() : 현재 요소를 제거 example code Iterator 를 잘 활용하면 코드를 단순화하고 일반화 할 수 있을 것 같다.

객체지향 생활 체조 총정리 규칙 1: 한 메서드에 오직 한 단계의 들여쓰기만 한다. 규칙 2: else 예약어를 쓰지 않는다. 규칙 3: 모든 원시값과 문자열을 포장한다. 규칙 4: 한 줄에 점을 하나만 찍는다. 규칙 5: 줄여쓰지 않는다(축약 금지). 규칙 6: 모든 엔티티를 작게 유지한다. 규칙 7: 2개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다. 규칙 8: 일급 콜렉션을 쓴다. 규칙 9: 게터/세터/프로퍼티를 쓰지 않는다. (developerFarm 개발자 농장 포스팅 내용) 객체지향 생활 체조 9가지의 원칙은 어떻게 보면 당연하거나, 까다롭게 느껴질 수 있다. 모든 경우에 적용 할 수는 없겠지만 9가지 규칙이 몸에 베인다면 깔끔하고 일관된 코드를 작성 할 수 있을 것 같다. 규칙을 지키며 작은 프로젝트를 진행 해보았는데. 프로젝트 전반적으로 객체지향,클린코드,리팩토링 측면에서 많은 도움이 되었다. 만 지키더라도 코드의 가독성이 많이 향상 된다는 것을 느꼈다.

Balls 는 ball 리스트를 가집니다. ball 은 최소(MIN), 최대(MAX) 조건이 있는 타입입니다. balls 는 특정한 조건을 가지기 때문에 위 코드 처럼 별도의 검증처리를 해줍니다. 단순히 변수의 이름 “balls” 로 정의 된것이 아닌 좀더 객체지향의 관점에서 본다면 어떨까요? 이렇게 말입니다. 에서 정의 했을 뿐인데, 편안함이 느껴지지 않나요? ^^?;;;;; 는 단순히 Integer 를 가진 변수일까? 어떤 조건이 있는 것 일까? 코드를 처음 보는 사람은 고민을 하게 됩니다. 만약에 객체가 1000줄 짜리 코드이고 거기에 인스턴스 변수였다면, 수정하거나 값을 추가하기 부담스러울 것입니다. validation 하는 부분을 찾기 힘들거나 찾았다 하더라도 정말 그것만으로 다 인가? 하는 의구심이 들기 때문입니다. 어떠한 객체가 있는데 그 객체가 최소(MIN), 최대(MAX) 조건이 있는 타입의 객체라면 어떨까요? Ball.class 로 원시 값 포장을 해보았…

캡슐화 객체의 속성(data fields)와 행위(메서드)를 하나로 묶고, 실제 구현 내용 일부를 외부에 감추어 은닉한다. (위키피디아) 디미터 법칙(Law of Demeter) 각 유닛은 다른 유닛에 대한 제한된 지식만 가지고 있어야 합니다. 현재 유닛과 “밀접하게” 관련된 유닛만 있어야 합니다. 각 유닛은 친구들과만 대화해야 합니다. 낯선 사람과 이야기하지 마십시오. 가까운 친구에게만 이야기하십시오. (위키피디아) 캡슐화는 외부로부터 내부 로직을 감춤으로써(은닉), 객체의 내부 데이터와 메소드의 응집도가 생깁니다. 이러한 부분은 스스로 자율적인 객체가 되는 이점이있습니다. 프로젝트가 커지거나 유지보수를 해야할때 추가 또는 수정되는 코드의 비용을 줄일 수 있습니다. 또한, 데이터와 메소드의 응집도가 생기므로 팀단위 개발 또는 규모가 커질때 파편화된 코드를 줄일 수 있고 중복된 코드를 방지 할 수있습니다. 캡슐화를 적용하지 않은 코드 예시 MemberTest 에서 으로 Role 에…

“소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.” 소프트웨어 개발 작업에 이용된 많은 모듈 중에 하나에 수정을 가할 때 그 모듈을 이용하는 다른 모듈을 줄줄이 고쳐야 한다면, 이와 같은 프로그램은 수정하기가 어렵다. 개방-폐쇄 원칙은 시스템의 구조를 올바르게 재조직(리팩토링)하여 나중에 이와 같은 유형의 변경이 더 이상의 수정을 유발하지 않도록 하는 것이다. 개방-폐쇄 원칙이 잘 적용되면, 기능을 추가하거나 변경해야 할 때 이미 제대로 동작하고 있던 원래 코드를 변경하지 않아도, 기존의 코드에 새로운 코드를 추가함으로써 기능의 추가나 변경이 가능하다. 1. 확장에 대해 열려 있다. 이것은 모듈의 동작을 확장할 수 있다는 것을 의미한다. 애플리케이션의 요구 사항이 변경될 때, 이 변경에 맞게 새로운 동작을 추가해 모듈을 확장할 수 있다. 즉, 모듈이 하는 일을 변경할 수 있다. 2. 수정에 대해 닫혀 있다 이것은 모듈의 동작을 확장할 수 있다는 것을 의미한다. …

SOLID 원칙 - SRP (단일 책임 원칙) 한 클래스는 하나의 책임만 가져야 한다. 클래스는 그 책임을 완전히 캡슐화해야 함을 일컫는다. 클래스가 제공하는 모든 기능은 이 책임과 주의 깊게 부합해야 한다. 로버트 마틴은 책임을 변경하려는 이유로 정의하고, 어떤 클래스나 모듈은 변경하려는 단 하나 이유만을 가져야 한다고 결론 짓는다. 예를 들어서 보고서를 편집하고 출력하는 모듈을 생각해 보자. 이 모듈은 두 가지 이유로 변경될 수 있다. 첫 번째로 보고서의 내용 때문에 변경될 수 있다. 두 번째로 보고서의 형식 때문에 변경될 수 있다. 이 두 가지 변경은 하나는 실질적이고 다른 하나는 꾸미기 위한 매우 다른 원인에 기인한다. 단일 책임 원칙에 의하면 이 문제의 두 측면이 실제로 분리된 두 책임 때문이며, 따라서 분리된 클래스나 모듈로 나누어야 한다. 다른 시기에 다른 이유로 변경되어야 하는 두 가지를 묶는 것은 나쁜 설계일 수 있다. 알아보기 회원정보가 있다. 회원 정보에…