입꼬리 올리고 사는 개발자

Spring 기초

- AOP

모듈화된 비즈니스 로직들 중, 중복되는 공통 부분들을 여러번 쓰기 보다 이 공통 부분을 따로 모듈화 하자는 개념.

가로 영역의 공통 부분을 잘라냈다고 하여 Cross-Cutting 이라고도 불린다.

이는 핵심 로직을 추출하는 것이 아닌 핵심 로직에 포함된 부가 기능들(ex. 로깅, 인증절차 등등)을 공통으로 묶어 재사용하는 것

명확한 분리를 통해 핵심 로직에 정말 핵심이 담기게 되고 + 공통된 기능이 한 곳에서 관리되어 유지보수에 좋다.

다양한 annotation을 통해 Advice(공통 기능 로직이 정의되는 곳)를 실행시킬 시점을 설정할 수 있다.

@Before, @AfterReturning, @AfterThrowing, @After, @Around...

- 쿠키 vs 세션

역할: 클라이언트와 서버간의 상태(state)를 유지하기 위해 사용

저장위치: 브라우저 / 웹 서버

만료시점: 쿠키 저장 시 설정(서버에서 쿠키 제작 시) / 브라우저 종료, 로그아웃, 서버에서 설정한 유지기간 만료 시

보안: 취약(클라이언트 측에서 변형이나 탈취가 일어날 수 있음) / 서버 측이라 괜춘

알고리즘

- 프로그래머스 : 모음 사전(Level 2, 완전탐색, 중복순열)

Spring 기초

- JPA Auditing

ORM 기술(java에선 JPA)을 사용하여 도메인을 DB에 매핑해줄 때 자주 쓰이는 필드값이 존재하는데 대표적으로 생성시간, 수정시간 등이 있다. JPA에서는 이 생성시간, 수정시간을 자동으로 감시해주는 auditing 기능을 지원하는데. Entity가 생성된 시점 + Entity를 Dirty Checking한 후 update가 되는 시점을 자동으로 해당하는 테이블에 넣어준다.

@EnableJpaAuditing - auditing 활성화. 실행 클래스 (~~~application)에 넣어줘야한다.

@EntityListeners(AuditingEntityListener.class) - 해당 클래스에 auditing 기능을 포함시켜줌

@MappedSuperclass - 이 annotation이 있는 추상 클래스를 Entity 클래스가 상속받으면 추상 클래스의 멤버변수를 컬럼으로 인식.

위 세 annotation이 필수적이다.

- Query Method

메소드명만 잘 지어도 쿼리를 알아서 짜준다??

JpaRepository<Entity 클래스이름, PK 타입> 을 상속받아주면 쿼리 메소드를 사용할 수 있다.

public interface PostRepository extends JpaRepository<Post, Long> {}

findAllByOrderByModifiedAtDesc

findTop2ByName

findByNameEndingWith 등등이 있다. 자세한 건 공식 문서를....

https://docs.spring.io/spring-data/jpa/docs/current/reference/html/#jpa.query-methods

알고리즘

- 프로그래머스 : 모음 사전(Level 2, 완전탐색, 중복순열)

느낀 점

오늘 특강에서 AOP 개념을 추상적으로 배웠다. 아 이러면 좋긴 하겠다 정도로 이해하고 나중에 구현하면서 장점을 이해해야겠구나 했었다. 그러나 갑자기 질문들에서 필터, 인터셉터 같은 개념들이 나옴 + 이 질문과 연관해서 프록시, 어드바이스 같은 개념들이 나오면서 모르는 단어들에 머리가 어질어질해졌다. 이해할 것만 이해하고 고수님들을 열심히 따라 잡아야지

Spring 기초

- Entity

Entity는 JPA가 관리해주는 객체들을 의미하며 @Entity 로 JPA가 관리할 수 있게끔 해주고, @Table, @Column으로 해당하는 DB에 매핑을 시켜주어야 한다.

- 영속성 컨텍스트(Persistence Context)

영속성이란 Entity의 영구성을 보장한다는 개념으로 영속성 컨텍스트에 저장함(EntityManager.persist(entity)) 으로서 Entity를 영속화할 수 있다.

여기서 영속성 컨텍스트란 JPA에서 객체를 효율적으로 관리하기 위한 개념으로. EntityManger가 관리해준다.

Entity의 생명주기는 비영속, 영속, 준영속, 삭제  4가지 상태가 있고 디버깅해서 이캐저캐 하면 살펴볼 수 있다.

- 영속성 컨텍스트의 기능

1. 1차 캐시 : 캐시 기능을 제공한다(DB 조회수 감소). Transaction이 끝나면 다 비워지기 때문에 한 transaction 내에서만 성능이 좋다.

2. 동일성 보장(Identity) : 1차 캐시를 통해 DB row 당 1개의 객체를 보장한다.

3. 쓰기지연 저장소(Actionqueue) : 버퍼링 기능을 제공한다. 쿼리를 보낼 시의 설정을 통해 최적화가 가능하다.

4. 변경 감지(Dirty Checking) : persist되었을 때 최초의 Entity 값을 snapshot 으로 저장하고 flush 시점에 현재 값과 snapshot을 비교한다. 변경사항이 있을 시 쓰기지연 저장소에 update 쿼리를 넣어준다.

알고리즘

- 프로그래머스 : 전력망을 둘로 나누기(Level 2, 완전탐색)

느낀 점

최근에 진행하는 알고리즘 난이도가 낮아서 그런지 스프링 개념 공부보다 알고리즘이 재미있다 ㅎ.

그래도 내가 더 모자란 스프링을 더 열심히! 숙련주차 들어가기 전에 기초 복습하면서 확실히 잡고 들어가자.

데이터베이스

- Transaction

Transaction이란 데이터베이스의 상태를 변화(DB에 접근)시키기 위해 수행하는 작업 단위이다.

하나의 SQL 명령문도, 여러개의 명령문을 한번에 실행하는 것 모두 Transaction으로 4가지의 특성을 가진다.

1. Atomicity(원자성) : Transaction이 DB에 모두 반영되던가 아예 반영되지 말아야 한다.

2. Consistency(일관성) : Transaction의 작업 처리 결과가 항상 일관적이어야 한다.(작업 중에 참조하던 테이블이 변경된다 하더라도 Transaction 시작 시의 원본 테이블을 참조)

3. Isolation(독립성) : Transaction은 실행중인 다른 Transaction에 절대 끼어들 수 없다. 

4. Durability(영구성) : Transaction이 완료되었을 경우, 결과는 영구적으로 반영되어야 한다.

커밋을 완료해야 Transaction이 종료된다.

rollback을 통해 ctrl + z가 가능하지만 DDL문(CREATE, DROP, ALTER, RENAME, TRUNCATE)는 rollback이 불가능하다.

알고리즘

- 프로그래머스 : 피로도(Level 2, 완전탐색)

- next_permutation (c++ <algorithm>)

순열을 이용한 완전 탐색 문제인지라 c++ next_permutation을 이용하여 풀었다.

이 과정에서 next_permutation 함수의 작동방식을 배웠는데 가장 큰 원리는 주어진 벡터에 나열된 값에서 '더 내림차순 스러운 다음 순열을 찾는 방식'이다.

예를 들어 내가 {1,4,2,3} 벡터에 next_permutation을 호출하면 그 다음 내림차순스러운 {1,4,3,2} 그 다음에는 {2,1,3,4} 이런 방식이다. 

더 놀라운 점은 만약 {4,3,2,1} 벡터에 n_p를 호출하면 False를 반환하면서 그냥 끝난다. 어떤 벡터에 하든 모든 경우의 수 찾는 줄 알았는데 아니었다. 이제 활용 쉬울 듯 합니다^^. 더 오름차순스러운 순열을 원한다면 previous_permutation도 있다.

느낀 점

주말에 충격적인 바선생님 출몰로 시간 관리에 실패한 후, 오늘 허겁지겁 과제하느라 Spring 개념은 대강 훑고 지나갔다. 처음 듣는 용어들 많았는데 내일은 상세히 파악해봐야지

오늘 배운 것

Spring 기초

 - JDBC

JDBC는 자바에서 제공하는 표준 DB 연결 인터페이스이다.

원래는 DBMS 회사마다 connection, query 보내기, 데이터 받기 등등의 설정이 다 달라서 서버 측에서 설정을 일일이 해줘야 했었고 DBMS가 바뀔 때도 또 다시 설정을 바꿔주어야 했었다.

그러나 자바가 JDBC API를 제공하면서 부터 회사에서 이 인터페이스를 구현하는 코드를 라이브러리 형태로 배포해주기 때문에 우리는 DBMS 드라이버만 설치하면 편하게 설정이 완료된다.

 - 3-tier architecture

3-tier architecture는 서버를 프레젠테이션 계층 - 비즈니스 계층 - 데이터 계층으로 구분하여 개발하는 구조를 뜻한다.

처음에는 MVC와 차이점이 무엇인지 3-tier의 한 방법론이 MVC인지 헷갈렸는데 넘 좋은 글이 있었다.

https://co-no.tistory.com/120

요약하자면 MVC 패턴은 비즈니스 로직과 UI의 책임을 구분한다는 장점은 여전하지만. 비즈니스 로직의 크기가 커져가면서 Controller부분과 Model 부분을 더 세분화하여 개발하는 것이라 이해했다.

- IOC(제어의 역전)와 DI(의존성 주입)

IOC는 외부에서 구현체를 주입(DI)받아 강한 결합을 막고이는 코드 유지보수의 효율성을 높여준다.(의존성 주입시 어떤 인터페이스를 주입할 지 한번만 갈아끼우면 됨.)

우리는 DI 디자인 패턴을 통하여 IOC 설계 원칙을 지킨 것.

알고리즘

- 프로그래머스 : 카펫(Level 2, 완전탐색)

느낀 점

처음 들어보는 내용이 나오면서 좀 오래 걸리는데 이제 구현을 따라치는 것만으로는 이해가 어려운 수준에 온 것 같다.

다양한 글들을 읽어보며 수준높은 이해를 해야할 듯 하다.

오늘 배운 것

Spring 기초

- MVC 패턴

Model, View, Controller로 구성된 디자인 패턴으로 Spring에서는 이를 채택하고 있음.

Model의 역할은 비즈니스 로직 + DB에서 데이터를 넣었다 뺐다.

View의 역할은 사용자가 보는 것 + 사용 인터페이스

Controller의 역할은 Model과 View의 상호작용을 제어

1. 요청이 들어왔어요
2. 디스패처 서블릿이 이 요청을 분석함. 이 분석한 데이터을 토대로 핸들러 매핑을 통해 컨트롤러 요청을 찾아주게 된다. 핸들러 매핑에는 api path와 controller 메서드가 매칭되어 있음. ex) GET /api/hello면 HelloController의 hello() 함수를 호출하도록.
3. 이 매칭된 정보를 디스패처 서블릿이 확인한 다음에. 해당하는 컨트롤러에 요청을 전달(dispatcher) . 서블릿을 다 만들어주지 않아도 컨트롤러에 해당하는 클래스를 만들고 @Getmapping 선언해 놓고 연결 잘 해주면 되는구나!
4. 요청에 대한 처리가 완료되었으면 결과 + 뷰에 대한 정보를 모델에 담아준다. 뷰에 대한 정보 예시. 로그인 하고 마이페이지를 요청했는데 거기 마일리지가 나와야할 것 아니냐. 이걸 컨트롤러에서 디비 연동해서 몇 포인트 있는지 알려준다는 뜻. + mypage.html 이 이름 자체.
5. 뷰 리졸버에서 뷰에 대한 정보들을 받아와서 뷰에 적용을 함
6. 뷰 반환

DispatcherServlet이 적절한 컨트롤러에 요청을 전달해주어서 Servlet을 많이 만들 필요가 없어지고 controller 로직에 집중이 가능.

알고리즘

- 프로그래머스 : 소수 찾기(Level 2, 완전탐색)

느낀 점

알고리즘 스터디 시작, 하루 한 문제, 성공적.

오늘 배운 것

웹 동작 방식

- IP주소, 브라우저, DNS

- HTTP : 송,수신 측의 통신규약이 프로토콜이고, HTTP는 웹에서 가장 많이 쓰이는 프로토콜이다.

- API : 서버의 창구 역할, 다른 소프트웨어와 통신하기 위해 따라야 하는 규칙

- 서버의 역할 : 예전에는 document를 잘 주는 게 서버의 역할이었지만 인터넷 발달이 고도화 되면서 이제는 json같은 데이터만 넘겨주고 DOM 구성은 프론트 단에서 잘 처리한다.

- REST(ful) API : REST는 소프트웨어 아키텍처의 일종이고 api 설계만 적절하게 해줘도 RESTful 하다고 말할 수 있다. (URL 고유하게 만들고, 적절한 HTTP 메소드 활용한다면)

- DB의 역할은 데이터를 성능 좋게 이용하기 위함

서버에 대한 이해

- 새로운 데이터를 처리하는 부분(Presentation 계층) - 서비스 로직을 처리하는 부분(Domain계층) - 기존의 데이터를 이용하는 부분(data access 계층) 으로 레이어드

- Presentation 계층 : 사용자와 상호 작용 처리. CLI, HTTP 요청, HTML 처리. URL 매핑해서 특정 함수가 호출되게 하는 것. 스프링에선 @Controller

- Domain 계층 : 핵심 로직이 포함된 계층. '유효성 검사' 및 '계산'. 서버 프레임워크가 유능해지면서 Domain 계층에만 집중할 수 있게 됨. 스프링에선 @Service

- Data Access 계층 : (대부분) 서버 외부에 있는 DB와 소통하는 계층. 스프링에선 @Repository

DB 기초

- in-memory DB는 서버가 멈추면 데이터도 휘발됨

- SQL : Structured Query Language. 표준이 존재하나 DBMS회사별로 약간의 차이가 있음. DDL, DCL, DML로 구성

- DDL : Data Definition Language. Data Definition Language 테이블이나 관계의 구조를 생성하는 데 사용
CREATE, ALTER, DROP, TRUNCATE - DB와 테이블을 생성, 수정, 삭제

- DCL : Data Control Language - 데이터의 사용 권한을 관리

GRANT, REVOKE - 사용자 또는 ROLE에 대해 권한을 부여, 회수

- DML : Data Manipulation Language - 테이블에 데이터를 검색, 삽입, 수정, 삭제
INSERT, SELECT, UPDATE, DELETE

- 데이터의 무결성 (data integrity) : 완전한 수명 주기를 거치며 데이터의 정확성과 일관성을 유지하고 보증

- 개체 무결성 : PRIMARY KEY와 관련. 모든 테이블이 primary key를 가져야 하며 primary key로 선택된 열은 고유해야 하고 NULL 은 허용하지 않는다.

- 참조 무결성 : FOREIGN KEY와 관련. PRIMARY KEY와 FOREIGN KEY 간의 관계가 항상 유지되어야 함. 예를 들어 참조되고 있는 속성 값(PRIMARY KEY를 가진)은 함부로 삭제될 수 없음.

- 범위 무결성 : 한 컬럼에 대해 NULL의 허용 여부와 타당한 데이터 값들을 지정. 자료형, 규칙과 제약, 값 범위들을 제한

- ERD : Entity Relationship Diagram. 개체-관계 모델. 테이블 간의 관계를 설명해주는 다이어그램으로 API를 효율적으로 뽑아내기 위한 구조도.

- CASCADE, JOIN, CONSTRAINT 등등...

느낀 점

팀원분들 잘 만난 것 같아 1차적으로 기분이 좋지만 내가 듣지도 않고 졸업해버린 DB가 나와서 좀 헷갈린다. JOIN도 기본적인 것만 다뤘는데 실습 쿼리짜기에서 틀린 부분도 있고 불안하지만 화이팅.

오늘 한 일

팀 프로젝트

- 팀 프로젝트 마무리 및 KPT 회고

인텔리제이 Ultimate에는 클래스 다이어그램을 그려주는 기능이 있다.

github에서 fork하지 않은 채 contributor가 되면 내 repository에 뜨지 않는다.

알고리즘

- 백준 1967 트리의 지름(Gold 4, DFS)

강연

- 좋은 개발자가 되기 위한 비밀.

느낀 점

팀 프로젝트 마무리하면서 이것저것 수정하면서 오후까지 보냈다. 오늘 새로운 개념을 배운 것은 없지만 주말에 글 하나 쓰면서 뇌 건강을 챙겨야겠다.