인자가 많은 메서드는 왜 나쁠까?를 읽고.

이 글은 토스페이먼츠의 ‘인자가 많은 메서드는 왜 나쁠까?’를 바탕으로 정리했습니다.

• 코드를 사용하는 사람의 입장에서 논한다.
• 인자가 많으면서 각 인자의 의미를 파악하기 어렵다면, 해당 메서드의 사용성은 떨어진다.
• 잘 모르는 인자 또는 불필요한 인자에 null을 넣는 것은 불편하다.

• ‘연락처에서 이름과 휴대폰 번호’처럼 항상 같이 사용하는 인자는 하나로 묶는다.
• 연관이 없는 메서드는 분리함으로써 각 메서드의 독립성을 보장한다.
• 가장 중요한 인자만 남긴다.
• ‘함수 인자에 의존성 주입’은 코드 사용자에게 부담이지만, 객체에서 의존성을 관리하면 코드 작성자가 부담을 감당할 수 있다. (코드 사용자는 더 편리하다.)
• 중복으로 호출되는 의존성 주입 코드를 한 곳으로 모으면, 객체 간의 표현도 더 풍부해진다.
• 코드 사용자에게 친절하지 않은 코드는 그 코드를 사용하기 위해 너무 많은, 팀 내부의 도메인 지식을 알아야 하므로, 즉 만든 개발자만 이해하는 코드는 좋지 않다.
• 개발자가 요구사항을 위해 사용해야 하는 코드를 쉽게 읽을 수 있는 환경이 가장 바람직하며, 개발자가 가장 생산적으로 활동할 수 있다.
• 다른 팀원이 도메인 지식을 다시 학습하지 않아도 되도록 코드를 리팩토링해야 한다.
• 리팩토링에는 디자인 패턴과 클린 아키텍처, 도메인 주도 개발(DDD) 등이 있다.

코드를 읽는 동료 개발자를 항상 고객처럼 생각하라.

42의 코딩 스탠다드, Norminette중 대표적으로 몇 가지가 떠오르는 글이었다.

• 함수의 parameter 갯수는 최대 5개로 제한한다.
• 함수는 하나의 역할만 해야 한다.

과거의 나처럼, 규칙이 생겨난 배경에 대한 이해가 부족하다면, 당연히 불편하게 여길 수 밖에 없다.

나 혼자 코드를 작성했다 하더라도 누군가 반드시 그 코드를 읽고 건드릴 수 있다는 걸 기억하자.