클린코드/리팩토링 주니어 기술면접

좋은 함수명은 첫째, 함수가 수행하는 동작을 명확하게 표현해야 합니다. 둘째, 동사로 시작하여 무엇을 하는지 직관적으로 알 수 있어야 합니다. 셋째, 함수의 의도와 목적을 드러내며 주석 없이도 이해할 수 있어야 합니다. 넷째, 부수효과가 있다면 함수명에 포함시켜 예상치 못한 동작을 방지해야 합니다. 마지막으로 일관된 네이밍 컨벤션을 따라 팀 전체가 같은 방식으로 이해할 수 있어야 합니다.

첫 번째는 함수 추출(Extract Method)로, 의미 있는 코드 블록을 별도의 함수로 분리하는 방법입니다. 두 번째는 임시 변수를 쿼리 함수로 바꾸기로, 복잡한 계산 로직을 별도 함수로 추출합니다. 세 번째는 조건문 분해하기로, 복잡한 if-else 구조를 각각의 함수로 분리하여 가독성을 높입니다. 네 번째는 매개변수 객체 만들기로, 여러 개의 매개변수를 하나의 객체로 묶어 함수 시그니처를 단순화합니다. 이러한 기법들을 통해 함수는 한 가지 일만 수행하는 단일 책임 원칙을 따르게 됩니다.

매직 넘버란 코드에 직접 하드코딩된 숫자 리터럴로, 그 의미를 코드만으로는 파악하기 어려운 것을 말합니다. 문제점은 첫째, 숫자만 보고는 그것이 무엇을 의미하는지 알 수 없어 가독성이 떨어집니다. 둘째, 같은 값이 여러 곳에 중복되어 있을 때 수정이 어렵고 실수가 발생할 수 있습니다. 해결 방법은 의미 있는 이름을 가진 상수로 추출하는 것입니다. 예를 들어 86400이라는 숫자 대신 SECONDS_PER_DAY와 같은 상수를 사용하면 코드의 의도가 명확해집니다. 이를 통해 유지보수성과 가독성이 크게 향상됩니다.

단일 책임 원칙은 하나의 클래스나 함수는 단 하나의 책임만 가져야 하며, 변경의 이유도 하나여야 한다는 원칙입니다. 즉, 하나의 모듈은 하나의 액터(사용자 그룹)에 대해서만 책임을 져야 합니다. 이를 위반하면 첫째, 한 기능의 변경이 다른 기능에 영향을 미쳐 예상치 못한 버그가 발생할 수 있습니다. 둘째, 코드의 결합도가 높아져 테스트가 어려워집니다. 셋째, 여러 책임이 얽혀있어 코드 이해와 유지보수가 복잡해집니다. 예를 들어 사용자 인증과 데이터베이스 저장을 한 클래스에서 처리하면, 인증 로직 변경 시 DB 코드까지 영향받을 수 있습니다.

첫 번째 단계는 현재 동작을 보존하기 위해 특성 테스트(Characterization Test)를 작성하는 것입니다. 이는 현재 코드가 어떻게 동작하는지 문서화하고 검증하는 역할을 합니다. 두 번째는 테스트 가능한 구조로 만들기 위해 의존성을 분리하고 seam을 만드는 작업입니다. 세 번째는 작은 단위로 리팩토링을 진행하되, 각 변경 후 즉시 테스트를 실행하여 동작이 변하지 않았는지 확인합니다. 네 번째는 커버리지를 점진적으로 높여가며 더 안전한 리팩토링 환경을 구축합니다. 중요한 것은 한 번에 많은 것을 바꾸지 않고, 동작 변경과 구조 개선을 분리하여 진행하는 것입니다. 또한 버전 관리 시스템을 활용해 언제든 되돌릴 수 있도록 자주 커밋해야 합니다.