잘못 작성된 람다 코드를 삭제하기까지의 여정

Optional의 `map` 안에 구독 유효성 조건을 한꺼번에 넣은 코드는 이름이 모호하고 람다 내부가 복잡해, 동료가 흐름과 의도를 파악하기 어려웠다. 짝 프로그래밍으로 메소드명을 `isValidSubscription`으로 바꾸고, 기간·만료일 검증과 사용 가능 여부, 회원 상태 확인을 작은 메소드로 분리했다. 이어 유효성 검사를 먼저 수행하고 실패 시 `false`를 반환하도록 흐름을 정리해 조건을 한눈에 읽을 수 있게 했다. 람다를 습관적으로 쓰기보다 일반 제어문과 비교해 가독성을 판단하고, 코드를 읽을 동료의 관점에서 표현을 선택해야 한다는 교훈을 얻었다.

• 람다를 썼다는 이유만으로 간결하거나 읽기 쉬운 코드는 아니다.
• 복잡한 조건은 도메인 의미가 드러나는 작은 메소드로 나누면 변경 지점을 좁힐 수 있다.
• 조건이 많을 때는 빠른 리턴으로 실패 원인을 순서대로 드러내는 방식을 고려한다.
• 람다와 일반 제어문을 나란히 비교해 팀원이 이해하기 쉬운 표현을 선택한다.