기본제공 타입의 객체는 직접 초기화한다. 경우에 따라 저절로 되기도 하지만 그렇지 않을 수 있다. 생성자에서는 초기화 리스트를 사용하여 초기화하자. 나열 순서는 선언된 순서를 지키자. 비지역 정적 객체를 지역 정적 객체로 바꾸어 여러 번역 단위에 있는 비지역 정적 객체들의 초기화 순서 문제는 피해서 설계하자. 올바른 초기화 C++에서 객체의 값을 초기화하는 것은 상황에 따라 다르게 동작한다. 초기화되지 않은 값을 읽도록 내버려 두면 정의되지 않은 동작이 발생할 수 있다. 하지만, C++의 객체 초기화는 규칙이 명확히 있으니 올바르게 사용하자. C++의 C 부분만을 쓰고 있으며 초기화에 런타임 비용이 소모될 수 있는 상황이라면 값이 초기화된다는 보장이 없다. 그렇지만 C가 아닌 부분으로 확장한다면 상황에 ..
전체 글
const를 붙여 선언하면 컴파일러가 사용상의 에러를 잡아내는 데 도움을 준다. const는 어떤 유효범위에 있는 객체에도 붙을 수 있으며, 함수 매개변수, 반환 타입에도 붙을 수 있고 멤버 함수에도 붙을 수 있다. 컴파일러 쪽에서 보면 비트수준 상수성을 지켜야 하지만, 프로그래머는 논리적인 상수성을 사용하여 프로그래밍해야 한다. 상수 멤버 및 비상수 멤버 함수가 기능적으로 서로 똑같게 구현되어 있을 경우 코드 중복을 피해야 한다. 이때 비상수 버전이 상수 버전을 호출하도록 만들어라 const const는 '의미적인 제약'을 소스 코드 수준에서 붙인다. 또한, 컴파일러가 이 제약을 단단히 지켜준다. const는 다양하게 활용할 수 있다. 클래스 바깥에서는 전역 혹은 네임스페이스 유효범위의 상수를 선언하는..
상수를 쓸 때는, #define보다는 const, enum을 우선으로 함수처럼 쓰이는 매크로는 #define 매크로보다 inline함수를 우선으로 #define 대신 const, enum, inline #define ASPECT_RATIO 1.653이라고 상수를 정의했다고 치자. 우리에게는 ASPECT_RATIO라는 기호식 이름(symbolic name)으로 보이지만 컴파일러는 전혀 알 수 없다. 소스 코드가 컴파일러에게 넘어가기 전에 전처리 단계에서 숫자 상수로 바꾸어버린다. 그 결과, ASPECT_RATIO는 기호 테이블에 들어가지 않고 1.653이라는 숫자로 들어가게 된다. 따라서, 우리는 에러를 보면 ASPECT_RATIO는 이름은 찾아볼 수 없다. 이러한 문제를 매크로대신 상수(const)를 사..
![](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2F2Boae%2Fbtsn7NwGmLC%2FO2zJlEqVQrVNeFyxLRBzz0%2Fimg.png)
Vector 내적 외적 정리 내적 A*B = |A| * |B| * cosθ 두 벡터사이의 각은 코사인의 역함수로 구할 수 있다. 게임에서 내적이 사용되는 사례 물체가 앞에 있는지 혹은 뒤에 있는지 판별 플레이어의 시선(forward)을 기준으로 좌, 우의 내적값은 음수값을 갖는다 → 내적이 양수라면 앞에, 음수라면 뒤에 있다. 시야각 내에 물체 판별 시야각이 X라 했을 때, 플레이어의 시선(forward)과 물체의 위치 벡터를 내적하여 얻은 각도가 X/2보다 크다면 시야각에 벗어나는 물체이다. 점 A와 평면 S와의 최단 거리 계산(이때, d가 0이라면 점 A는 평면 위의 점이다.) 선과 평면사이의 접점을 구할 때 외적 두 벡터와 모두 직교하는 새로운 벡터를 구한다. 내적과는 달리 교환법칙이 성립되지 않는..
![](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2F1m7Eq%2FbtqZPGvCWNe%2FkV8GV80ZDoc9GPyZtsIHm0%2Fimg.png)
부하 테스트 서버가 얼마만큼의 요청을 견딜 수 있는지 테스트를 해보자. 코드에 문법적, 논리적 문제가 없더라도 서버의 하드웨어 제약 때문에 서비스가 중단될 수 있다. 대표적인 경우가 OOM(Out of Memory)이다. 서버는 접속자들의 정보를 저장하기 위해 각각의 접속자마다 일정한 메모리를 할당한다. 이렇게 사용하는 메모리의 양이 증가하다가 서버의 메모리 용량을 넘어서게 되면 문제가 발생한다. artillery를 설치하고 서버를 실행해보자. npm i -D artillery npm start 그리고 터미널을 하나 더 실행시켜 다음 명령어를 이용하여 100명의 가상 사용자가 50번씩 요청을 보내게 해보자. npx artillery quick --count 100 -n 50 http://localhost..
![](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FIB6AV%2FbtqZJ5hBk4h%2FQdgBtbvpxiHU2tnsQt0BpK%2Fimg.png)
통합 테스트 라우터를 통째로 테스트해보자. routes 폴더에 auth.test.js를 작성하자. 하나의 라우터에는 여러 개의 미들웨어가 붙어 있고, 다양한 라이브러리가 사용된다. 이런 것들이 모두 유기적으로 잘 작동하는지 테스트하는 것이 통합 테스트이다. supertest를 설치하자. npm i -D supertest supertest를 사용해 auth.js를 테스트할 것이다. supertest를 사용하기 위해서는 app 객체를 모듈로 만들어 분리해야 한다. const express = require('express'); const cookieParser = require('cookie-parser'); const morgan = require('morgan'); const path = require(..
![](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FdhhNMF%2FbtqZJ6GE8AS%2F2pViIZozNvY2IAWZdKtOA0%2Fimg.png)
테스트 커버리지 유닛 테스트를 진행하다 보면 어떤 부분이 테스트되고 어떤 부분이 테스트되지 않는지 궁금할 수 있다. jest의 기능중에 전체 코드 중에 테스트되고 있는 코드의 비율과 테스트되고 있지 않은 코드의 위치를 알려주는 jest의 기능이 있다. 이를 커버리지(coverage) 라고한다. "scripts": { "start": "nodemon app", "test": "jest", "coverage": "jest --coverage" }, 스크립트를 작성하자. 그리고 실행해보자. npm run coverage File은 파일, 폴더 이름, %Stmts는 구문 비율, %Branch는 if문 등의 분기점 비율, %Funcs는 함수 비율, %Lines는 코드 비율, Uncovered Line #s는 커버..