
1. 단위 테스트 현황단위 테스트를 적용해야 하는지는 더 이상 논쟁거리가 아니다. 그냥 쓰고 버리는 프로젝트가 아니면, 단위 테스트는 늘 적용해야 한다.논쟁은 단위 테스트를 작성해야하는가? 에서 좋은 단위 테스트를 작성하는 것은 어떤 의미인가로 바뀜2. 단위 테스트의 목표코드베이스(code base)에 대해 단위 테스트 작성이 필요하면 일반적으로 더 나은 설계로 이어진다. 하지만 단위 테스트의 주목표는 아니다.그럼 주 목표는?⇒ 소프트웨어 프로젝트의 지속 가능한 성장을 가능하게 하는 것테스트가 없는 프로젝트의 경우 시작은 유리하지만, 이내 진척이 없을 정도로 느려진다.테스트가 없다면?코드베이스에서 무언가를 변경할 때마다 무질서도(엔트로피)는 증가한다. 하나의 버그를 수정하면 더 많은 버그를 양산하고, 소..

프로세스가 메모리를 할당 받으면 자신만의 방법으로 메모리를 관리하기 위해 이 공간들을 어떤 구조로 관리하는데, 우리는 이를 프로세스 주소 공간이라고 부른다.프로세스의 메모리 배치는 일반적으로 여러 섹션으로 구분되며 위 그림과 같다.텍스트 영역: 실행 코드데이터 영역: 전역변수힙 영역: 프로그램 실행 중에 동적으로 할당되는 메모리스택 영역: 함수를 호출할 때 임시 데이터 자장장소(함수 매개변수, 복귀 주소 및 지역 변수)스택 영역스택 영역은 함수 호출이 발생할 때마다 임시 데이터를 저장하는데 사용되는 메모리 공간이 영역은 후입선출(LIFO) 방식으로 동작하며, 함수가 호출될 때 해당 함수의 매개변수, 복귀 주소 및 지역 변수가 이곳에 저장된다.함수의 실행이 완료되면 해당 함수에 할당된 스택 프레임이 제거되..

현재 진행중인 프로젝트에서 쪽지 관련 API를 만들면서 겪었던 문제들을 어떻게 해결하였는지 적어보려 한다.1. Table 설계현재 구현하려는 쪽지 기능은 카톡과 같이 한사람이 여러 채팅방을 가질 수 있으며 각각의 채팅방은 1대1 채팅방을 기본으로 한다.이를 바탕으로 처음 설계한 Table은 다음과 같다.user table은 간략히 표현해 보았다.각각의 컬럼을 설명하자면 다음과 같다.[room table]id: pk값last_content: 해당 채팅방의 마지막 쪽지 내용time: 해당 대화방에서 마지막으로 주고받은 쪽지 시간sender_id: 최초로 쪽지를 보낸 user의 pk값 (fk)receiver_id: 최초로 쪽지를 받은 user의 pk값 (fk)sender_is_deleted: 최초로 쪽지를 보..

1번 1번은 난이도가 좀 있는 구현문제이다. 보자마자 N값이 작아 브루트포스가 떠올랐고 블록마다 번호를 붙여 상하좌우 탐색해주면 답을 구할 수 있다. 배열을 String으로 줘서 2차원 배열로 바꾸는게 조금 번거로웠다. 상하좌우 탐색할때 이미 탐색했던 번호는 더이상 탐색하면 안되고 자기 자신 번호 또한 탐색하면 안된다. 2번 기본적인 백트래킹 문제이다. 문제에서 최대로 올 수 있는 값의 크기가 17만?? 이라고 줘서 완전탐색을 쉽게 떠올릴 수 있었다. 상하좌우 대각선 8방향에 대해 dx dy 배열 만들어서 방문여부를 체크해주며 백트래킹 하면 된다. 3번 완탐을 하기엔 시간복잡도가 N^M이었고 문제에서 MOD를 줘서 dp로 접근해 보았는데 다행히 dp로 풀리는 문제였다. 내가 제일 꺼려하는게 dp 문제인데..
JPA 인프런 강의를 들으면서 궁금했던 점들을 정리하고자 한다. 1. @Transactional없이 JPA를 실행 할 수 있을까? JPA는 데이터베이스 작업을 수행하기 전에 트랜잭션이 활성화되어 있는지 확인한다. 만약 트랜잭션이 활성화되어 있지 않으면 JPA는 자동으로 트랜잭션을 시작한다. 따라서 @Transactional 어노테이션이 없어도 JPA를 사용하여 데이터베이스 작업을 수행할 수 있다. 하지만 이 경우 JPA가 자동으로 시작한 트랜잭션은 해당 데이터베이스 작업이 완료된 후 자동으로 커밋된다. 2. 영속성 컨텍스트는 트랜잭션이 종료되면 같이 종료될까? @GetMapping("/api/v1/simple-orders") public List ordersV1() { List all = orderRep..

2022년에는 많은 경험을 했던 해이다. 12달동안 어떠한 경험을 했고 어떠한 변화가 있었는지 살펴보자. 1월 ~ 2월 DND 동아리 참여, 부산 it 동아리 (PROJECT) 참여 DND라는 it 개발 동아리에서 프론트엔드로 Round Table이라는 서비스를 개발하였다. 8주라는 짧은 시간동안 개발을 끝내야해서 시간에 많이 쫒겼던것 같다. 마지막 발표전날엔 새벽 6시까지 개발하던게 생각난다.. 그래도 어찌저찌 배포까지 끝냈고 버그가 많았지만 하나의 서비스를 만들어보는 경험을 하였다. 협업도 처음으로 해봤었고 좋은 경험이었다. DND에서 개발을 하면서 동시에 부산 it 동아리인 PROJECT에서도 4주 프로젝트를 진행하였다. 두개를 동시에 할려다보니 이쪽에서는 많은 집중은 하진 못했다,, 2달동안 두개..