kdh93

프로그램 코드를 작성하며 비슷한 규격의 코드가 반복 될 때, 프로그램의 핵심 기능과 부가 기능을 나누고 싶을 때 TemplateMethod Pattern을 사용한다. 학습 테스트를 통해 알아보자. 위 메서드의 대해 간단하게 훑어보자면 비지니스 로직을 실행하는 핵심기능과 메서드의 시작시간과 종료시간을 구해 메서드 실행시간을 구하는 부가기능이 공존하는 메서드다. 비지니스 로직을 수행하는 핵심기능은 각 logic별로 다르지만 시작시간과 종료시간을 구해 실행시간을 구하는 부가 기능은 logic1과 logic2 모두 같다. 이러한 비슷 규격의 코드를 템플릿화 시켜 변경되는 부분만 템플릿에 맞춰 사용하는 패턴이 템플릿메서드 패턴이다. 학습테스트에 적용해보자 Abstract Class에 골격이되는 템플릿메서드를 작성..

Command Line Interface 를 배워야하는 이유 GUI보다 더 많은 명령이 가능하기때문, 서버를 시작하거나 프로세스를 죽이고 관리하거나 권한을 변경하거나 숨긴 파일을 설정하거나 컴퓨터의 핵심 영역에 접근할 수 있다. Unix, Unix Like 계층적 파일 시스템 등.. 많은 명령어와 시스템들이 유닉스로부터 시작됨. -소프트웨어의 모듈화 레고 조각처럼 작은 프로그램을 만들고 여러 명령어를 연결해 하나의 프로그램을 완성시킴. -Unix Like 공식적으로 Unix라고 할 수 없지만 Unix처럼 동작하고 Unix에게 영감을 받은 운영체제들 Linux와 Mac OS X가 대표적 Linux Linux는 Kernel이다. 리눅스만으로 운영체제라고 부를 수 없고 ( 커널이 자동차 엔진이라 치자면, 엔진..

클래스 체계 public static 변수 private static 변수 private instance 변수 ( 저자는 public instance 변수는 거의 필요가 없다고함..) public method private method ( 주로 자신을 호출하는 함수 직후에 자리하는게 좋다고함 이렇게 클래스는 추상화 단계가 순차적으로 내려가기때문에 프로그램이 신문기사 처럼 읽힌다고.. 캡슐화 변수와 유틸리티 함수는 가능한 공개하지 않는편이 낫지만 반드시 숨겨야하는 법칙도 없다고함. protected 로 접근을 제어해 테스트 코드에 접근을 허용하기도함 클래스는 작아야한다. 저자는 클래스의 크기가 함수와 마찬가지로 작아야된다고 강하게 주장함. 그렇다면 얼마나 작아야하는가? 예시로 70개의 메서드를 가지고있는 ..

Spring 동시성 문제에 관한 강의를 듣고 복습 겸 정리겸 겸사겸사.. 우선 동시성 문제란... n개의 Thread가 동시에 하나의 자원에 접근할 때 발생하는 문제 강의에서 본 학습 테스트로 직접 동시성문제를 겪어봤다. nameStrore 라는 이름을 저장하는 필드값이 존재하고 fieldService가 제공하는 logic이라는 메서드에서는 매개변수로 name을 받고 log로 받은 name, nameStore에 현재 어떤 name값이 들어와있는지를 조회한다. (동시성문제 확인을위해 nameStore 조회전 1초간 Thread를 멈췄다.) 테스트는 2개의 Thread로 name을 nameStore에 저장해본다. 첫번째 동시적으로 nameStore Field 변수에 접근하지않고 2초라는 시간텀을 두고 각각의..

Jwt 토큰 인증이 테스트코드에서는 성공적으로 잘 돌아갔다. 최종적으로 POST MAN으로 외부에서 실제로 API요청시에도 정상 기능을 하는지 확인해보기로했는데.... Http 403 code와 함께 권한 인증 오류가 발생했다... 이유가 뭘까 분명히 JWT 코드에는 문제가 없었는데 우선 스프링 시큐리티 debug 를 활성화 시켜 어느 필터에서 문제가 발생했는지 체크해보기로 함. AuthorizationFilter 에서 AccessDenied 오류가 발생... AuthorizationFilter에서 권한부여가 실패해 인증실패가 됬다. 처음엔 MethodSecurity를 선언한 Config 문제인줄 알았지만 @Secured도 @PreAutrhorized에 문제도 아닌 상황 디버그 로그를 곰곰히 확인하다 원..

8장은 외부 패키지, 라이브러리, 오픈 소스등으로 사용되는 외부코드에 관한 글이다. 경계살피고 익히기 외부에서 온 코드를 다루는 방법은 어렵다. 사용할 때 라이브러리가 예상대로 동작하는지, 라이브러리코드의 문제인지 나의 코드 문제인지 파악하기가 힘들다. 그렇기때문에 외부 코드 작성전 학습테스트를 진행하는것이 좋다. 통제된 테스트 환경에서 외부 코드를 테스트해 API를 제대로 이해했는지를 확인하는 것. 학습테스트에는 비용이 없다. 투자 대비 얻는 성과가 더 큼. 아직 존재하지 않는 코드를 사용하기 협업 과정중 다른팀이 아직 우리가 필요한 API를 완성하지 못했을때의 이야기 구현을 미루고 인터페이스를 정의 -> 우리가 작성하려는 코드의 의도가 분명해진다. 인터페이스 정의 후 다른팀의 API가 완성되었을때 인..

깨끗한 코드와 오류처리의 연관성 -> 여기저기 흩어진 오류 처리 코드때문에 실제 코드가 하는일을 파악하기가 어려워진다. 오류 코드보다 예외를 사용하라 if else문으로 코드의 오류를 처리하기보다는 try catch문을 사용해 코드와 오류 처리코드가 섞이지 않게 하자. Unchecked Exception을 사용하라 checkedException은 OCP를 위반한다, (하위단계에서 코드를 변경하면 예외를 선언한 상위단계 메서드 선언부를 전보 고쳐야하기 때문) 또한 ChekedException은 Throws로 인해 의존관계측면에서 단점이 존재함. (다른 계층에서 Catch하지못한 예외를 다른 계층으로 넘겨버린다. ex) Persistance Layer의 예외를 Business Layer까지 Throw해 Bu..

우선 저번 팀프로젝트에서는 Spring Inteceptor와 Session을 이용해서 로그인 기능을 구현했지만 이번엔 Spring Security와 JWT를 사용해 인증과 인가를 부여하기로했다. JWT를 사용한 이유 학습의 목적. 경험해보지않은 기술을 직접 구현해보며 학습하기위해 최근 Security 강의를 들었던 경험의 복습 인증 정보를 서버에 저장하지않고 토큰에 저장해 사용자가 가지고다니는 Sateless한 점. Signature 에 의한 보안성 크게 3가지 이유로 인해 이번 프로젝트에서 인증 기능은 JWT를 사용하기로했다. Spring Security에서 JWT의 흐름부터 파악하며 공부하기 시작했다. 클라이언트에 로그인 요청 REST API Server 필터에서 요청 헤더에 JWT가 존재하는지 검..

Authentication [ 인증 ] 1. 식별의 의미 2. AuthN: 항상 권한부여보다 먼저 등장 (우리는 항상 사용자에게 로그인을 먼저하라고한다.) 3. 로그인과 관련된 세부정보만 묻는다. 4. 401 Error Authrization [ 권한부여 ] 1. 인증 후 역할에 따른 접근의 강제 2. AuthZ: 항상 인증 후에 등장 3. 사용자의 자격증명에 대해 몰라도된다. (사용자의 Role을 알아야함. ) 4. 403 Error ROLE: 권한 부여의 그룹. 실제 서비스에는 수백가지의 권한이 존재한다. 사용자에게 일일히 권한을 부여하기에는 코드가 너무 복잡해지므로 ADMIN, USER등 역할을 주고 여러 권한을 한꺼번에 부여한다. 역할에는 항상 'ROLE_ ~~' 같은 접두사가 붙어야한다. 세밀한..

CORS Cross-Origin Resource Sharing (CORS): 두가지 출처에서 서로의 자원을 공유 여기서 출처: Origin 이란 URI를 뜻한다. origin: (도메인주소, 포트 번호 , HTTP 프로토콜) 서로 다른 출처에서 자원공유를 하려할 때 브라우저에서 보안적 의미로 막는 행위 CORS가 없다면 해커의 서버에서 나의 서버로 쉽게 침투 할 수 있다. 보안 공격방법이 아닌 보안협약이라고 볼 수 있다. 이렇기에 백엔드서버와 프론트서버의 자원 공유를 위해 수동으로 이 설정을 풀어줘야한다. 해결 방법 1. @CrossOrigin(origins = "http://localhost:4200"): Spring REST API 서버에서 Annotation으로 해당 origin의 요청을 허용 문제..