'전체 글'에 해당되는 글 17건

  1. 2019.09.17 Best Pratices of Node.js Error Handling
  2. 2019.06.22 [PostgreSQL] 데이터베이스 Backup & Restore
  3. 2019.06.11 테스트하기
posted by JakeYeom 2019. 9. 17. 18:16

1. Use Async-Await or promises for async error handling

비동기식 콜백 오류를 다루는것은 매우 어려운 일이므로 reputable promise library를 사용하거나  async-await 에 try-catch 와 같이 친숙한 구문을 사용하는 것이 좋다.

 

2. Use only the built-in Error object

error object는 내장객체만을 사용하는것이 통일성이 향상되고 정보손실을 방지할 수 있어 좋다. custom 객체를 사용하는경우 상호 운용성이 복잡해진다. ( ex: stack trace 정보가 손실될 수 있음 )

 

3. Distinguish operational errors vs programmer errors

운영상의 오류와 프로그래머가 내는 오류를 분류한다. 

운영상의 오류는 프로그래머가 이해할 수 있는 내의 범위의 오류를 말한다.

프로그래머 오류는 알 수 없는 코드장애로 응용프로그램을 다시 시작하는 오류를 말한다.

( 알려지지 않은 오류로 응용프로그램을 다시 시작해야한다면 다중사용자에 대응도가 매우 떨어지기 때문에 상황에 대한 대처법을 적용해야 한다. )

 

4. Handle errors centrally, through but not within middleware

모든엔드포인트의 에러는 캡슐화를 잘해서 메일 또는 로그로 중앙에서 관리할 수 있도록 해주어야 한다.

 

5. Document API errors using Swagger

스웨거에 에러에 대한 가이드를 명시한다. 사용자가 에러에 대한 대처를 작성할 수 있다.

 

6. Shut the process gracefully when a stranger comes to town

알 수 없는 오류가 발생할 경우. 애플리케이션 운영 상태에 대한 보장을 할 수 없으므로 Forever 나 PM2 같은 restarter를 사용하여 프로세스를 다시 시작한다.

 

7. Use a mature logger to increase errors visibility

Winston, Bunyan, Log4J 와 같은 로깅 도구를 사용하면 오류 발견을 쉽게할 수 있다.

console.log를 사용하는 것보다 오류 디텍팅 비용을 아낄수 있다.

 

8. Test error flows using your favorite test framework

코드가 작성자가 의도한 시나리오를 충족하는지, 올바른 오류를 처리하고 있는지 확인한다.

 

9.  Discover errors and downtime using APM products

모니터링 및 성능측정 제품을 사용하여 오류 및 다운타임을 검색한다.

 

10. Catch unhandled promise rejections

unhandled promise rejections을 catch 한다. 오류에 대해 기록을 남기고 처리할 수 있는 방법을 생각해 본다.

 

11. Fail fast, validate arguments using a dedicated library

arguments에 대해 검증할 수 있는 library를 사용한다.

'백엔드 > Node.js' 카테고리의 다른 글

Node.js 핵심개념정리  (0) 2019.10.15
posted by JakeYeom 2019. 6. 22. 22:22

Backup Process

1. Databases -> DB선택 -> Schemas -> public -> 우클릭 -> 메뉴에서 Backup을 선택

2.1 General 탭

-> Filename: 저장할 경로와 Backup File명 작성

-> Format: Custom or tar 선택

-> Role name: DB User 선택

2.2 Dump options 탭

-> Sections: Pre-data, Data, PostData Yes로 선택

Dump options - Sections

-> Type of objects: 설정 변경하지 않음

-> Do not save: Owner, Previlege Yes로 선택

Dump options - Do not save

-> Queries: Include CREATE DATABASE statement, Use Insert Commands Yes로 선택

Dump options - Queries

-> Disable: 설정 변경하지 않음

-> Miscellaneous: 설정 변경하지 않음

 

2.2까지 설정을 완료하고 General탭에서 Backup 버튼을 클릭! 하면 아래와 같이 Backup 스케쥴이 생성된다.

백업 스케쥴링

 

백업이 완료되면 아래와 같은 화면이 나타나고 사용자가 지정한 위치에 백업파일이 생성됩니다.

백업완료

 

 

Restore Process

1. Databases -> DB선택 -> Schemas -> public -> 우클릭 -> 메뉴에서 Restore를 선택

2.1 General 탭

-> Format: Custom or tar 선택

-> Filename: Restore 대상 File명 선택

-> Role name: DB User 선택

 

2.2 Restore options 탭

-> Sections: Pre-data, Data, PostData Yes로 선택

Restore options - Sections

-> Type of objects: 설정 변경하지 않음

-> Do not save: Owner, Previlege Yes로 선택

Restore options - Do not save

-> Queries: 설정 변경하지 않음

-> Miscellaneous / Behavior: 설정 변경하지 않음

 

Restore가 완료되면 다음과 같은 창이 나타납니다.

리스토어 완료

 

 

posted by JakeYeom 2019. 6. 11. 16:18

테스트 주도 개발 (TDD)는  더 나은 소프트웨어를 만들기 위한 기법 중 하나다.

 

테스트 코드를 작성해야 하는이유?

1. 코드의 정상작동 유/무를 확인하기 위해서, 소프트웨어에 대한 피드백 과정이 줄어든다.

( 소프트웨어 출시에 있어 피드백 과정이 줄어드는 것이 프로젝트 전체의 일정으로 보았을때 매우 효율적이다 )

2. 새로운 하부시스템을 전체 프로젝트에 통합하기 전에도 매우 유리하다. 

3. 운영되는 코드에 대해 문제를 빨리 알수 있고 수정이쉽고 비용이 낮아진다.

 

테스트 코드 작성시 알아아두어야 할것.

1. 최대한 많은 개발자 테스트를 자동화 하는것이 핵심.

2. 테스트 코드 작성에 따라 코드 작성시간이 올라갈 수 있지만 코드의 품질을 생각하여 테스트를 수행하는것이 좋다.

3. 잘못된 테스트 코드는 불필요한 리소스를 낭비할 수 있지만 테스트 코드 작성자가 테스트 코드에 대해 이해하고 적절한 테스트 전략을 세운다면 테스트 코드는 작성하지 않을 이유가 없다.

4. 모든 단계의 소프트웨어 스택과 개발 프로세스에 대해 테스트를 수행해야 한다. 특히 가장 작은 범위에서 테스트를 수행해야 피드백 과정 ( 문제발견 / 수정 )을 줄일 수 있다. 

 

테스트의 유형

- 유닛 테스트

가장 작은 단위의 기능에 대한 테스트를 단독으로 수행하는 것. 각각의 함수가 정확히 작동하는지 확인하기 위한 것.

 

- 통합 테스트

통합 테스트를 통해 각각의 단위 모듈을 더 큰 결합체로 통합하여 작동시키는 복합 기능을 검증할 수 있다.

 

- 시스템 테스트

'end-to-end tests' 이 테스트를 통해 전체 시스템에 대한 요구사항 명세를 확인할 수 있음. 통합된 소프트웨어 스택 전체에 수행되는 테스트로서, 프로젝트에 대한 검수 기준으로 사용됨.

 

테스트 작성 시기

1. 코드를 작성할때 ( 테스트코드를 같이 작성, 나중에 할 수록 테스트 효과가 줄어듬 )

2. 출시코드에 대해 버그를 수정할 때 ( 코드수정을 바로 하지말고 버그의 원인을 설명하는 실패 유닛 테스트를 작성하라 )

3. 빌드과정에서 테스트를 끼워넣을 수 있도록 하자.

 

테스트 대상

요구사항에 맞게 테스트하라 ( 어떠한것도 테스트대상이 될 수 있다 )

 

좋은테스트

1. 짧고 명확한 이름을 가지고 있어 실패했을때 원인파악이 쉬움.

2. 유지보수가 쉬움.

3. 수행에 오랜 시간이 걸리 지않음.

4. 최신 구현 코드(작업물)에 맞춰져 있음.

5. 특별히 머신 설정이 필요 없다.

6. 다른 테스트에 대한 의존성이 없어서 특정 테스트 전후에 실행할 필요가 없다. 외부 상태나 코드상의 어떤 공유 변수에 대한 의존성이 없다.

7. 실제 구현코드를 테스트 한다. ( 복제본이 아님, 복제본은 쓸모없을 수 있음 )

 

나쁜테스트

1. 일정한 결과값을 갖지 않음 ( 때로는 성공, 때로는 실패 )

2. 유지보수하기 힘든 테스트

3. 지나치게 큰 테스트

4. 하나의 테스트케이스에서 둘 이상을 수행하는 테스트

5. 직접 작성하지 않은 서드파티 코드에 대한 테스트

6. 필요하지 않은 기능에 테스트하는 테스트

7. 기능이 보장되어있는것까지 하는 테스트 ( ex: 속성의 getter, setter에 대한 테스트 )

8. 단 하나의 머신에서만 수행 가능한 테스트

 

테스트의 형태

- 테스트의 기본 프로세스

배치( 검사를 실행할 준비 ) - 실행 - 검증 ( 예측된 값이 맞는지 검사 실행 )

- 테스트 이름

명확한 테스트 명명을 하는것이 좋음.

 

테스트의 구조

- 테스트가 코드의 중요 기능을 모두 다른 점을 보장하라.

- 테스트는 중복해서 수행하지 않는다. ( 중복 수행은 노력과 혼란, 유지 보수 비용을 가중시킴 )

- 코드의 특정 행태를 확인하는 테스트를 작성하라.

 

테스트 유지 보수

- 테스트코드는 깔끔하게 다듬고 리팩토링을 하라.

- 코드를 수정하고 테스트케이스를 제거하지마라 테스트케이스 또한 유지보수를 하라.

 

출처: 훌륭한 프로그래머 되는 법