kdh93

Standard Output Redirection: 명령어의 출력값을 파일로 저장하거나, 프린터 또는 다른기기로 보낼 수 있다. "명령어 > 파일명" 출력값을 파일로 얻을 수 있다. 이미 존재하는 파일로 덮어쓰기도 가능 "파일1 > 파일2" 파일1로 파일2를 덮어 쓸 수 있다. ">>" appending >> 원래 존재하는 파일에 추가해서 리다이렉션 할 수 있다. Standard input Redirection: 명령어의 입력값을 파일로 저장하거나, 프린터 또는 다른기기로 보낼 수 있다. cat은 파일명을 입력안하고 엔터를 칠 경우 입력을 기다리며 키보드 입력을 리스닝하게된다. cat < test.txt cat으로 test.txt의 데이터를 표준입력받는다. Standard error Redirect..

@Bean이나 Component Scan 으로 스프링 컨테이너 내부에 빈 저장소에 등록하기전 해당 빈을 조작 후 등록한다. (빈을 생성한 후로 무언가를 처리하는 용도) 객체를 조작 할 수도 있고 , 다른 객체로 바꿔치기도 가능함. 빈으로 등록될 A,B 클래스가 존재한다. 빈 후처리기 클래스. 초기화된 빈이 만약 A라면? B를 인스턴스화 해서 B를 return하여 스프링 컨테이너에 B 객체를 등록한다. config를 통해 빈은 A 객체만 등록되도록 설정해놓았지만 빈 후처리기에 의해 B 객체가 스프링 컨테이너에 등록됬단것을 확인 할 수 있다.

"cat" 파일안에 무엇이 있는지 확인하고 출력해줌. 여러개를 입력하면 결합시켜 출력한다. tac 명령어도 존재하는데 결합을 역순으로해서 출력해준다. "less" 파일을 열어서 그 내용을 보여준다. / 를 통해서 검색가능 (Vim 으로 파일을 연거랑 비슷한느낌 그냥 vim으로 여는게 나은거같은데) "head" 파일의 시작10줄까지만 확인한다. head -n 옵션으로 줄 수를 정할 수 있다. "tail" 파일 뒤에서부터 10줄을 확인 역시 -n 옵션이 가능하다. head와 tail로 파일을 직접 열지않고 커맨드상에서 깔끔하게 보고싶은 데이터만 확인이 가능하다. "wc" 파일 안의 줄 수 바이트 수 를 알려준다. 순서대로 파일안의 줄 수, 단어의 수, 바이트 수, 경로 -l 옵션을 통해 파일의 줄 수만 얻을..

포인트컷: 어디에 부가기능을 적용할지 적용하지않을지 판단하는 필터링 로직 클래스와 메서드이름으로 필터링한다. 어드바이스: 프록시가 호출하는 부가기능, 프록시 로직이 작성되는곳. 어드바이저: 포인트컷과 하나의 어드바이스를 가지고 있는것 이렇게 나눠둔 이유는? "역할과 책임을 분리하기위해" 포인트컷은 대상 여부를 확인하는 필터 역할만을 담당 어드바이스는 부가기능 로직만을 담당 둘을 합치면 어드바이저가 된다. 프록시 팩토리를 이용할 때 어드바이저는 필수이다. 스프링은 target마다 하나의 프록시를 만들고 여러개의 어드바이저를 호출한다. 어드바이저당 여러개의 프록시가 생성되는것이 아님

" ctrl + l " clear의 단축키 화면을 깨끗하게 "crtl + a " , "crtl + e" 명령줄 맨앞과 맨뒤로 이동 vim 과 비슷해서 바로 이해 "option + f" , "option + b" 문장 앞 뒤로 이동가능 "option + t" 앞 문장과 교체 가능 "ctrl + k" 커서를 기점으로 그 앞 문장들 잘라내기 잘라내기한 단어들은 "ctrl + y" 로 붙여넣을 수 있다. ctrl + c, v와는 다르다. 클립 보드부터다름. vim이랑 비슷비슷하네 History 방향키 위를 누를때 전 명령어가 뜨던것 명령어로 입력시 그동안 입력했던 명령어가 쭉 뜬다. "history | less" 페이지 단위로 보기가 가능. "!번호 " 를통해 해당 명령어를 실행가능. "ctrl + r"

CGLIB: 바이트 코드를 조작해 동적으로 클래스를 생성해주는 라이브러리 인터페이스 없이 구체 클래스만 존재해도 프록시를 만들어 낼 수 있다. 외부 라이브러리지만, Spring FrameWork 내부 소스코드에 포함되어있음, 별도 추가 X MethodInteceptor 를 제공한다. package org.springframework.cglib.proxy; public interface MethodInterceptor extends Callback { Object intercept( Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable; } obj : CGLIB이 적용된 객체 method: 호출된 메서드 args: 메서드..

"rm "

테스트는 왜 필요할까? 문서화 품질 보증 내가 작성한 코드의 의도를 확실하게 이해했는가? 자동화 검증 Mock 테스트를 위한 대역 가짜 행위를 정의하는것 : Stubbing BDDMockito Clasicist VS Mockist 테스트 환경의 독립성. 테스트간의 의존성을 가지게하지 말자. 공유 변수 금지

Test Driven Development 프로덕션 코드보다 테스트 코드를 먼저 작성하여 테스트가 구현과정을 주도하도록 하는 방법론 RED : 실패하는 테스트를 먼저 작성. GREEN : 테스트 통과하는 최소한의 프로덕션 코드 작성. REFACTOR : 구현 코드 개선, 테스트 통과 유지 TDD 의 장점 피드백이 빠름 복잡도 낮은, 테스트 가능한 코드로 구현 가능하다. 쉽게 발견하기 어려운 엣지 케이스를 놓치지 않을 수 있다. 과감한 리팩토링이 가능해짐. 테스트가 통과하도록 계속 검증 가능. 선 기능 구현 후 테스트 작성의 단점 테스트 자체의 누락 가능성 특정 테스트 케이스만 검증할 가능성 (해피케이스) 잘못된 구현을 다소 늦게 발견할 가능성. 클라이언트(테스트) 관점에서 피드백을 줄 수 있다.

테스트 케이스 = 문서 문서적인 측면 프로덕션 기능을 설명하는 테스트 코드 다양한 케이스를 통해 프로덕션 코드를 이해하는 시각과 관점을 보완 어느 한 사람이 과거에 경험했던 고민을 팀 차원으로 승격시켜서 모두의 자산으로 공유할 수 있다. @DisplayName 음료 1개 추가 테스트 (명시의 형태) → 음료 1개를 추가할 수 있다. (문장의 형태로 나열) ex) A 일때 B이면 C이다 테스트 행위에 대한 결과까지 기술하기. 도메인 용어를 사용하여 추상화된 내용을 담기. 메서드 자체의 관점보다 도메인 정책의 관점으로 생각하기 테스트의 현상을 중점으로 기술하지 말것. BDD Behavior Driven Development TDD에서 파생된 개발 방법. 함수 단위의 테스트에 집중하기보다, 시나리오에 기반한 ..