BDD(Behavior Driven Development), DDD(Domain Driven Design)?
- Behavior Driven Development(BDD) - 행동 주도 개발
→ TDD(Test Driven Development), 테스트 주도 개발에서 한 반 덜 나아간 개발 방식.
→ TDD에서는 유닛 테스트로 작성 된 테스트 케이스에 대한 문서를 작성했지만, BDD는 이것을 결합 테스트와 '시나리오 테스트'까지 확장하여 각각에 해당하는 문서를 대체.
→ 시나리오는 어디서부터 테스트를 시작할지, 어떤 것을 테스트하고 어떤 것을 하지 않을지, 한 번에 얼마만큼을 테스트할지, 테스트에 어떤 이름을 붙일지, 테스트가 왜 실패했는지 등에 대한 고민을 해결해줌.
- Domain Driven Development(DDD) - 도메인 주도 개발
→ 순수한 도메인의 모델과 로직에 집중.
→ 보편적인 언어의 사용을 추구하며 모든 사람이 이해할 수 있게 문서와 코드가 동일한 표현과 단어로 구성되게 만드는 것.
→커뮤니케이션에 있어 분석 단계, 설계 단계, 구현 단계에 이르기까지 통일된 방식으로 협업이 가능.
→도메인 모델 부터 코드에 이르는 단계가 통일된 규칙을 이룸.
Refactoring이란 무엇이고 장점은 무엇이 있을까요?
-
리팩터링을 하는 것은 유지보수에 큰 도움이 된다.
물론 우선 코드부터 치면서 마구잡이로 짜는 것이 개발 속도를 높일 수가 있다.
하지만 유지보수, 기능 추가 등의 작업이 이루어질 때 새로운 기능을 추가해야할 지점과 어떻게 고칠지를 쉽게 알 수 있다.
모듈화가 잘 되어있다면 전체 코드 중 모듈화부분만 살펴보면 되기 때문이다.
리팩터링이 잘 수행된 코드는 새로운 기능을 구축하는데 튼튼한 토대가 되고 본인, 타인이 언제 읽어도 쉽게 이해될 수 있는 코드가 된다. -
변수나 함수의 정확한 네이밍이 필요하다.
예를 들어 비밀번호를 담는 변수가 어느곳에선 pw, 어느곳에선 password, passWord 로 쓰이고, 검증하는 함수가 어디서는 check, 어디서는 validate가 된다면 며칠만 지나도 본인조차 알아보기 힘들 것이다.
이들을 통일하는 것이 가독성을 증가시키고 생산성을 올릴 수 있다. -
함수 하나당 최소한의 기능으로 분할해야 한다.
만약 회원가입 데이터를 검증하는 함수에서 모든 조건을 함수 한번에 담는다면 유지보수가 힘들고, 확장하기도 불리하며 테스트를 할때 문제를 직면할 확률이 높다.
함수당 하나의 조건으로 나누는 것이 직관적으로 알아보기도 좋고, 다른 함수를 추가하기도 용이하며 테스트코드의 작성또한 독립적으로 시행되어 오류를 줄일 수 있을 것이다.
Sequlize같은 ORM과 MySQL같은 데이터베이스의 차이
데이터베이스란 정보를 저장하고 여러 사람이 공유하여 사용할 목적으로 체계 화해 통합, 관리하는 데이터의 집합이며, ORM은 이러한 데이터베이스와 객체 지향 프로그래밍 언어간의 호환되지 않는 데이터를 변환하는 프로그래밍 기법, 객체 관계 매핑(Object Relational Mapping) 이다.
대표적인 데이터베이스로는 MySQL, 이를 좀 더 수월하게 다루기 위해 사용하는 노드의 ORM은 Sequelize가 있다.
하지만 ORM을 사용한다고 모든 점이 좋아지는 것은 아니다. 물론 코드의 가독성이나 객체지향적 접근으로 어느부분 효율이 증가하는 것은 사실이지만 ORM도 부족한 부분이 분명히 있기에 데이터베이스를 직접 다룰 줄도 알아야 한다.
ORM을 사용하면 데이터베이스와 바로 연결하는 것 보다 초기세팅이 더 많아지거나 복잡해진다. 그리고 내부 동작에 대한 충분한 이해가 없는 경우 문제 해결이 힘들 수도 있다.
또한 데이터베이스에 직접적으로 쿼리문을 보내는 것이 아니기 때문에 성능 저하가 발생할 것이며, 데이터베이스가 복잡해질수록 모든것은 순전히 ORM만으로 구현하기가 어려워 진다.
ORM을 사용했을 때의 장단점을 간단하게 알아보았다. 어느 상황에서 어떤 기술을 사용하여 문재 해결 할지 파악하는 능력이 개발자에게 중요한 부분이라고 생각이 든다.
어떻게 미들웨어를 라우터로 구현할 수 있는지?
미들웨어는 요청이 들어오면 등록된 미들웨어를 차례로 실행하여 사용자에게 보낼 응답을 처리
<동작 원리>
1.express.Router()로 라우터를 import한 다음 처리할 로직을 작성하고 라우터 객체를 다시 export.
2.라우터마다 base가 되는 경로가 있고, 내부 로직을 쓸 때는 subpath만 작성. 정규식을 쓸 수 있고 : 으로 parameter를 가져올 수 있음.
3.express.use()로 basepath와 라우터를 등록해서 사용.
4.콜백 앞에 다른 미들웨어를 끼워 넣을 수 있음. (써드파티 미들웨어, 오류 처리 미들웨어 등)
참조: https://dev-dain.tistory.com/67
불필요한 테스트코드?
불필요한 테스트코드란 테스트코드를 작성했음에도 불구하고 내 비즈니스 로직의 문제점을 찾을 수 없을 때 발생한다.
예를들어 다른 테스트코드와 상호의존적인 테스트코드를 작성했을 때 어떤 하나의 이유로 실패를 하게 된다면 그 실패의 근본적인 원인을 테스트를 통해 알 수 없게 된다.
이처럼 꼬리에 꼬리를 무는 테스트코드는 한 테스트코드를 수정할 경우 의존성을 지니고 있는 다른 코드마저 수정해야 할 경우가 생기기에 유지보수도 번거로워진다.
따라서 각 테스트는 독립적으로, 하나의 시나리오에 맞춰서 하나의 테스트만 작성하는 것이 올바른 테스트코드 작성법이라고 할 수 있다.
