코딩 과제를 보다보면 간혹 이걸 실제 서비스에서 적용시키듯이 개발을 해야하는지 과제인 상황을 인지하고 개발을 해야하는지 고민될 때가 있습니다.
“영화별 매출액을 구하는 서비스를 개발하세요” 라는 예를 들어보겠습니다. 영화별 매출액을 출력해주면 되는 간단한 문제입니다
실제 서비스에서 해당 문제를 구현해야한다면 아마 영화테이블과 영화 매출액 테이블을 통해 데이터를 만들겠지만 과제라면 불필요한 영화테이블 대신 enum을 통해 관리할 수도 있습니다.
-- 영화 테이블을 통해 영화를 관리할 것인가?
SELECT
M.'영화이름'
, P.'매출액'
FROM 영화테이블 M, 매출액테이블 P
WHERE M.영화ID = P.영화ID
혹은
// 이렇게 ENUM으로 관리할 것인가?
MATRIX("매트릭스", 01),
PI_STORY('파이이야기', 02),
...
이런걸로 고민한다고 유난이라 생각할 수도 있지만 알고리즘을 제외한 사전문제들을 접하게 되면 한번쯤 마주하는 상황일 것입니다.
그래서 고민하다 스스로 내린 결론은 “평소에 주석을 통해 설명을 많이 다는 코딩스타일이라면 enum을, 그렇지 않다면 테이블을 통해 개발하는게 옳다” 입니다. 저는 평소에 주석을 집요하게 다는 스타일입니다. 스스로 개발한 코드도 한달만 지나면 남의 코드같은데 진짜 다른사람 코드는 분석하는 것도 한 세월이 걸립니다.
만약 별다른 설명없이 enum으로 개발한다면 사소한 것 하나라도 잘 보이고 싶은 자리에서 자칫 귀찮아하는 개발자로 비춰질까 걱정되기 때문입니다.
생각보다 면접관은 사소한 이유로 제 첫인상을 결정할 수도 있습니다.
결론은 내가 어떤 의도로 개발하는지 상대방이 명확하게 알 수 있는 코드를 짜자!