문제 | 접근방식 | 답변 |
---|---|---|
node, nestjs에 관련된 학습과 결정에 대한 시간 관리 | ||
ex) typeorm의 함수들이 어떻게 동작하는지에 대란 학습, nestjs에서의 middleware를 활용하는 것과 이를 적절하게 활용할 수 있는지와 같은 고민 | 지금은 그냥 명확한 기준 없이 개인적으로 만족하는만큼 찾아보고 구현을 하는 것 같습니다. 그리고 이런 경험이 도움이 되기는 할 것 같다고 생각합니다. 하지만 잘 모르는 언어와 프레임워크들을 사용하는만큼, 레퍼런스들을 찾아보고 좋은 방안이 무엇인지 결정하는데에 걸리는 시간이 너무 오래걸리는 것 같아서 기준점을 어떻게 잡아야할지 고민이 됩니다. | best practice라는 키워드 |
나중에 수정할 수 있는 부분들은 크게 고민할 필요는 없다 | ||
폴더나 파일구조에 보다는 계층끼리의 의존성에 대해서는 팀끼리 룰을 정해서 사용해보는 것도 좋을 것 같다. | ||
학습 정리를 미루어두는 문제 | 프레임워크나 db 선택 근거 작성을 잘 정리해 두는 작업이 필요하다고 생각하였습니다. | |
우선 참고한 레퍼런스들과 선택한 이유를 대략적으로만 작성하고 최종적으로 완성된 정리는 미뤄두었는데 좋은 결정인지는 의문입니다.. | 면접 대비하기 위해서는 무조건 자세할 수록 좋다.. | |
다른 사람에게 설명할 수 있을 정도로는 상세하게 작성해두어야 한다. | ||
시간이 지나면 다 까먹게 됨 | ||
테스트 코드 작성 | CI 테스트도 말씀해주셨었고, 테스트코드를 제대로 작성해본 적이 없어서 이번 기회에 작성해보려고 했으나 제대로 작성하지 못하였습니다. 의미있는 테스트코드를 작성하지도 못하는 것 같아서 우선은 postman으로 응답에 대해서 확인하였습니다. 이번 프로젝트를 진행하면서도 테스트코드를 작성하기는 어려울 것 같고, 추후에는 swagger를 사용하여 테스트를 진행할 것 같습니다. | |
postman이나 swagger를 활용하여 테스트를 진행해보는 것과 테스트코드를 직접 작성하는 것에 큰 의미와 차이가 있을지 궁금합니다. | 테스트코드의 가장 큰 의미는 자동화가 가능하다는 것 | |
postman이나 swagger를 사용하면 적어도 버튼을 눌러야 한다. | ||
테스트 코드로 새로운 기능을 추가해도 기존의 로직에 영향을 미치지 않는다는 것을 확인할 수 있다. |
외부 환경에 영향을 많이 받는 프로젝트의 경우, 전부 moking하여 사용하면 테스트 코드를 작성하는 것이 의미가 있는지?
그래도 작성하는 것이 좋다. moking할 수 밖에 없다.