효습

설계는 기능 명세로부터 시작한다기능 명세를 구체화하는 동안 입력과 결과를 도출하고 이렇게 도출한 기능 명세를 코드에 반영한다기능의 이름 , 파라미터 , 리턴 타입 지정  설계 과정을 지원하는 TDD테스트 코드를 만들기 위해서는테스트할 기능을 실행실행 결과를 검증→ 테스트 대상이 되는 클래스와 메서드의 이름을 결정해야한다.→ 메서드를 실행할 때 사용할 인자의 타입과 개수를 결정해야한다.  설계 과정클래스 이름메서드 이름메서드 파라미터실행 결과TDD 자체가 설계는 아니지만 , TDD를 하다 보면 테스트 코드를 작성하는 과정에서 일부 설계를 진행하게 된다.  필요한 만큼 설계하기TDD는 테스트를 통과할 만큼만 코드를 작성한다필요할 것으로 예측해서 미리 코드를 만들지 않는다TDD로 개발하는 코드 비율이 높아질수..

이전에 알림 기능을 구현할 때는 Polling 방식으로 구현했었다. Short Polling클라이언트가 서버로부터 정기적으로 알림 조회 요청을 보내서 데이터를 받아오는 방식이다. 그런데 웹이나 앱을 사용하다보면 알림 페이지에 있지 않아도 실시간으로 알림이 오는데 이걸 어떻게 구현할까?하고찾아보니까 크게 2가지가 있었다. 1. SSE(Server-Sent-Events)2. FCM(Firebase-Cloud-Messaging) 사실 처음에는 FCM을 하려고 해서 실제로 의존성까지 추가했는데 Karma 프로젝트는 웹으로만 동작하고 모바일 앱으로만 동작하지 않는다! -> SSE로 바꿨다. 처음에 알림 기능을 구현할 때 , 주문 상태가 접수완료 , 주문거절 , 제작대기 , 배송중인 주문 정보만 조회해서 ..

Karma 프로젝트를 진행하면서 가장 해보고 싶었던 건 OAuth 2.0 로그인이었다. redis도 이론이랑 간단한 실습만 해봤지 실제 프로젝트에서 써본 적은 없어서 이번 기회에 redis도 사용해봤다. 하지만 refresh token을 redis에 보관하면 redis도 배포된 서버에서 같이 동작해야하는데이걸 당시의 프로젝트 기한 내에 못할 것 같아  일단은 refresh token을  mysql에다가 저장했었다. 이제 시간 여유가 조금 생겨서 redis 서버 배포를 다시 시도해봤다.   https://sy-hj08.tistory.com/33 서버 배포 과정 이해하기배포하는 과정을 캡쳐한 게 없어 자세한 배포 과정을 정리할 수 없지만 대략적인 과정을 정리하겠다. 이번 Spring Boot 프로젝트를 배포..

Starting MySQL. ERROR! The server quit without updating PID file (/opt/homebrew/var/mysql/user.local.pid).  mysql.server start 하다가 저런 에러가 날 수 있다 보통 삭제하고 다시 설치하면 다시 정상 작동한다 하지만 난 Mysql 데이터 파일(ibdata1)  없었다 .근데 ibdata1이 없으면 InnoDB 엔진이 mysql 서버를 실행시키지 못함몇 번을 다시 깔아도 없길래 캐시 삭제를 시도함 (근데 보통 저 파일은 mysql을 설치하면 다시 생기기때문에 mysql 을 삭제하고 다시 설치하면 해결된다근데 난 안생겼음 몇 번을 다시 깔아도 안생김 )  그럼 뭐가 문제냐?mysql 설정 파일 , 캐시 파일이 ..

프로젝트 중에 스마트 워크 센터를 검색을 구현하는 api를 담당했다.처음에 검색 요소가 이름 , 태그 2개인 줄 알고검색어가 없는 경우, 1개가 들어오는 경우 , 2개가 들어오는 경우 생각해서 메서드를 4개를 만드려고 했다. 이렇게 코드 짤 때가 너무 비효율적인 것 같다고 생각했는데 알고보니 지역구까지 해서 검색 요소가 3개인 것이다! 3개면 만들어야하는 메서드가 6개다.물론 만들수는 있지그런데  더 좋은 방법이 있는데 그걸 선택하지 않을 이유는 없다 예전에 살짝 공부한 적이 있는 QueryDSL이 떠올라 한번 적용해보기로 했다    Dependencies 추가 //QueryDsl implementation 'com.querydsl:querydsl-jpa:5.0.0:jakarta' annotati..

쉬운 경우에서 어려운 경우로 진행예외적인 경우에서 정상인 경우로 진행 구현하기 쉬운 테스트부터 시작하기 예를 들어모든 조건을 충족하는 경우모든 조건을 충족하지 않는 경우 예외 상황을 먼저 테스트해야 하는 이유다양한 예외 상황은 복잡한 if-else 블록을 동반할 때가 많음 → 코드가 복잡해지고 버그 발생 가능성이 높아짐초반에 예외 상황을 먼저 테스트하면 이런 가능성이 줄어듦예외 상황에 따른 if-else 구조가 미리 만들어지기 때문에 많은 코드를 완성한 뒤에 예외 상황을 반영할 때보다 코드 구조가 덜 바뀐다예외 상황을 찾고 테스트에 반영하면 예외 상황을 처리하지 않아 발생하는 버그도 줄어듦 완급 조절정해진 값을 리턴값 비교를 이용해서 정해진 값을 리턴다양한 테스트를 추가하면서 구현을 일반화 테스트할 목록..

ERD(Entity Relationship Diagram) : 릴레이션 간의 관계들을 정의함 4.2.1 ERD의 중요성 관계형 구조로 표현할 수 있는 데이터를 구성하는데 유용하지만 비정현데이터를 충분히 표현할 수 없음 4.2.3 정규화 과정 릴레이션 간의 잘못된 종속 관계로 인해 데이터베이스 이상 현상을 해결하거나 저장공간을 효율적으로 사용하기 위해 분리하는 과정 정규형 원칙정보 표현의 무손실 : 정보가 사라지지 않아야 한다, 같은 의미의 정보를 유지하면서 더 효율적인 구조로 변화해야한다데이터 중복의 최소화 : 데이터 중복을 최소화하면서 , 데이터 관리의 편리성을 부여하고 자료 저장 공간을 효율적으로 사용분리의 원칙 : 독립적인 관계는 별개의 릴레이션으로 표현 , 릴레이션 각각에 대해 독립적 처리가 가능..

DB (DataBase) : 일정한 규칙 , 규약을 통해 구조화되어 저장되는 데이터 모음DBMS (DataBase Management System) : 데이터베이스를 제어 , 관리하는 통합 시스템DBMS 마다 정의된 쿼리 언어(query language)를 통해 삽입 , 삭제 , 수정 , 조회 등을 수행할 수 있음 4.1.1  엔티티 (Entity) 사람 , 장소 , 물건 , 사건 , 개념 등 여러 개의 속성을 지닌 명사를 의미서비스의 요구사항에 맞춰 속성을 정함약한 엔티티와 강한 엔티티A가 혼자서는 존재하지 못하고 B의 존재 여부에 따라 종속적이라면 A는 약한 엔티티이고 B는 강한 엔티티이다 4.1.2 릴레이션 (Relation)데이터베이스에서 정보를 구분하여 저장하는 기본 단위엔티티에 관한 데이터를 ..

CPU 스케쥴링 알고리즘은 CPU 이용률은 높게 ,주어진 시간에 많은 일을 하게 ,준비 큐 (ready queue)에 있는 프로세스는 적게 ,응답 시간을 짧게 설정하는 것을 목표로 함 3.4.1 비선점형 방식 (non - preemptive)프로세스가 스스로 CPU 소유권을 포기하는 방식 , 강제로 프로세스를 중지하지 않으므로 컨텍스트 스위칭으로 인한 부하가 적음 FCFS (First Come , First Served)가장 먼저 온 것을 가장 먼저 처리하는 알고리즘준비 큐에서 오래기다리는 현상(convoy effect)이 발생하는 단점이 있음 SJF (Shortest Job First)실행 시간이 가장 짧은 프로세스를 가장 먼저 실행하는 알고리즘Starvation(기아 상태) 발생할 수 있다 : 긴 시..

TDD란?TDD란 테스트부터 시작한다기능을 검증하는데 테스트 코드를 먼저 작성하고 테스트를 통과시키기 위해 개발을 진행한다먼저 테스트 파일 경로에 클래스를 만들고 완성하면 java 소스 파일 폴더에 넣어도 된다완성되지 않는 코드가 배포되는 것을 방지할 수 있다 TDD 흐름기능을 검증하는 테스트를 먼저 작성한다가장 먼저 통과시킬 기능 먼저 구현함작성한 테스트를 통과하지 못하면 테스트를 통과할 만큼만 코드를 작성한다테스트를 통과한 뒤에는 개선할 코드가 있으면 리팩토링한다.테스트코드 자체도 리팩토링 대상이다리팩토링한 뒤 , 다시 테스트를 실행하여 기존 기능이 망가지지 않았는지 확인한다이 과정을 반복하면서 점진적으로 기능을 완성해나가는 것이다  TDD 사이클을 레드(Red)-그린(Green)-리팩터(Refact..