리뷰 받으며 배운 기술 지식으로 답변
저는 팀 프로젝트에서 반복문 안에서 매번 데이터베이스를 조회하는 코드를 작성했다가 리뷰에서 N+1 문제를 지적받은 적이 있습니다. 그때까지는 개념만 알고 실제로 제가 그런 코드를 짜고 있는지 몰랐습니다. 팀원이 알려준 방법으로 조회를 한 번에 묶는 방식으로 고치면서 쿼리 수가 크게 줄어드는 걸 직접 확인했고, 그 뒤로는 반복문 안에 쿼리를 넣기 전에 한 번 더 생각하는 습관이 생겼습니다.
면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.
저는 팀 프로젝트에서 반복문 안에서 매번 데이터베이스를 조회하는 코드를 작성했다가 리뷰에서 N+1 문제를 지적받은 적이 있습니다. 그때까지는 개념만 알고 실제로 제가 그런 코드를 짜고 있는지 몰랐습니다. 팀원이 알려준 방법으로 조회를 한 번에 묶는 방식으로 고치면서 쿼리 수가 크게 줄어드는 걸 직접 확인했고, 그 뒤로는 반복문 안에 쿼리를 넣기 전에 한 번 더 생각하는 습관이 생겼습니다.
저는 사이드 프로젝트에서 기능 구현 후 테스트 코드 없이 PR을 올렸다가 리뷰어에게 예외 케이스에 대한 테스트가 없다는 지적을 받은 적이 있습니다. 그때 빈 입력값이나 잘못된 형식이 들어왔을 때를 테스트로 미처 챙기지 못했다는 걸 알았습니다. 이후로는 기능 코드를 짜면서 정상 케이스뿐 아니라 실패할 수 있는 경우를 먼저 목록으로 적어두고 테스트를 함께 작성하게 됐고, 리뷰에서 나온 지적도 확실히 줄었습니다.
저는 리뷰를 할 때 기능이 동작하는지보다 다른 사람이 이 코드를 6개월 뒤에 봐도 이해할 수 있는지를 중심으로 봤습니다. 팀원의 함수 이름이 기능을 정확히 설명하지 못해서 변경을 제안했는데, 처음엔 사소한 지적이라 반응이 소극적이었습니다. 그런데 나중에 그 함수를 다른 팀원이 잘못 이해해서 버그가 생긴 적이 있었고, 그 이후로는 제 리뷰 관점에 대한 신뢰가 생겼습니다. 동작하는 코드와 이해되는 코드는 다르다는 걸 그 경험으로 배웠습니다.
같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.
진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.