기주

쿼리스트링으로 전달되는 값은 자동으로 문자열로 바뀌어 전달되게 된다. 그렇기 때문에 쿼리스트링에는 별도의 문자열 표시인 따옴표 ''를 쓰면 안된다. 이 따옴표 까지 문자열의 일부로 인식되기 때문에 원하는 결과를 얻지 못하게 될 수 있다.   예시) 관심사에 '여행'이라는 문자열이 들어간 데이터들을 찾아본다고 가정하자    1.  {{baseUrl}}/user?search='여행'따옴표 까지 문자열의 일부로 인식되어 원하는 데이터 검색이 안된다.        2.  {{baseUrl}}/user?search=여행->  따옴표가 없어도 문자열로 변환되어 '여행' 값이 들어간 데이터가 검색된다        결론쿼리스트링에는 따옴표를 넣으면 안된다

오버라이딩:메소드 재정의상속으로 인해 동일한 이름의 메소드가 여러개인 경우, 자식 클래스의 메소드만 사용된다.  class A{ void paint() { System.out.println("a") }}class B extends A{ void paint() { System.out.println("b") }}A a = new A();B b = new B();A a2 = new B();a.print() // a출력b.print() // b출력a2.print() // b출력 A클래스의 인스턴스 a가 paint()를 호출하면, a가 출력된다B클래스의 인스턴스 b가 오버라이딩된 paint()를 호출하면, b가 출력된다A클래스 타입을가진 B클래스 a2가 오버라이딩된 paint()를 호출하..

1. 배열 -연속적인 메모리 공간에 저장-크기가 고정-인덱스로 빠른 조회(O(1))-삽입/삭제 느림 (O(n)) 세부분류정적배열: 자바에서 쓰는 방식. 크기가 고정되어 삽입/삭제 시 개발자가 직접 새로운 배열을 생성해 값을 옮겨야 한다. 동적배열: 자바스크립트에서 쓰는 방식. 내부적으로 새로운 배열로 값을 옮겨주므로 개발자가 직접 배열을 생성해 옮길 필요가 없다.   장점:인덱스로 빠른 조회가능.메모리 사용 효율적. (연속된 메모리공간) 단점:크기가 고정.삽입/삭제 시, 기존 요소들을 옮기는 작업으로 오래 걸림      2. 연속 리스트 배열처럼 연속된 메모리 공간에 저장하나, 크기 조절 가능.크기조정 시, 기존데이터를 옮기는 작업이 필요하다 일반적으로 동적배열과 연속리스트를 구분하지 않는 경우가 많다...

nest로 소셜로그인기능을 구현해보았다. 하지만 개발 도중, 생기는 문제가 있었다.지금은 소셜로그인 OAuth기능을 구글 서비스로만 구현했지만, OAuth기능을 제공하는 서비스들은 엄청많다. (네이버, 카카오, 페이스북, 깃허브..등등)새로운 소셜로그인 기능을 도입할 여지가 충분히 있는 상황이었다.그러면 새로운 소셜로그인기능을 추가할때마다, 기존의 서비스 코드를 수정하고, 새로운 메서드를 추가하거나, if문을 통해 분기처리를 하는게 맞는걸까?이러한 방식으로 하게된다면, if-else if문이 굉장히 길어지게되고, 새로운 기능이 더해질때마다 계속해서 수정해야하는 부분이 생기기때문에 유지보수가 어려워진다 그리고 하나의 서비스 클래스 에 여러가지 로직이 더해지기때문에 이해하기도 어려워진다문제의 코드)@Inje..

서비스를 개발하던 도중 테스트 코드를 작성해야할 필요가 있었고,  bcrypt와 같은 외부라이브러리를 사용할때, 함수 모킹이 되지않고, 테스트속도가 오래걸린다는 문제가 있었습니다 (bcrypt와 같은 암호화하는 작업들은 cpu 작업량을 많이요구하고 시간도 오래걸립니다)      문제가 생긴 메서드import * as bcrypt from 'bcryptjs';async signIn(loginDto: LoginDto): Promise { const channel = await this.prisma.channel.findFirst({ where: { id: loginDto.id }, }); if (!channel) { throw new UnauthorizedException(..

모듈 분리, 서비스 코드 분리 기준에 대해 생각해보자 각각 언제해야할까?    예를들어 댓글 CRUD기능과 댓글 좋아요기능이 있다고 가정해보자 그럼 1. 댓글 CRUD기능과 댓글 좋아요 기능의 서비스 코드를 분리해야할까? -> 특정 서비스내의 메서드들 중에서 어떤 것은 export를 해야하고 어떤 것은 export를 할 필요가 없다(해서는 안된다). 이때 각 메서드들은 별도의 클래스로 분리해야한다( 객체지향설계 SOLID 중 인터페이스 분리 원칙)   (인터페이스 분리 원칙 : 클라이언트가 자신이 이용하지 않는 메서드에 의존하지 않아야 한다는 원칙이다. -> 사용하지않는 불필요한 메서드 들은 가져오면 안된다. 꼭 필요한 메서드들만 주입 받아야한다 )      2. 댓글 CRUD기능과 댓글 좋아요 기능의..