SOLID: 함수만 '평탄화'하는 프로그래머가 되지 마세요 🛑

Source: Dev.to

코드를 한 줄만 수정해도 시스템 다른 쪽에서 뭔가가 깨질 거라는 두려움을 느낀 적 있나요? 저도 그런 경험이 있습니다.

오랫동안 저는 설계가 잘못된 코드를 그대로 이어받는 데만 집중했습니다; 기존에 있던 것 위에 기능을 하나씩 “덮어쓰기”만 하며, 두려움이나 시간 부족 때문에 아무것도 개선하지 않았죠. 하지만 프로그래밍은 오늘 동작하는 것에 그치지 않고 내일도 유지보수 가능해야 한다는 것을 배웠습니다.

S: Single Responsibility (단일 책임)

명백해 보이죠: 클래스는 존재할 단 하나의 이유만 가져야 합니다. 우리는 보통 User 클래스가 결제 처리나 대량 이메일 발송을 하지 않아야 한다고 생각합니다, 맞죠? 하지만 더 미묘한 함정에 빠지곤 합니다. 때때로 비밀번호 검증, 로그인 로직, 심지어 세션 관리까지 넣어버리죠.

결과: 너무 많은 것을 알고 있어 테스트하거나 변경하기가 불가능해진 클래스가 됩니다. 사용자는 엔티티일 뿐, 보안 오케스트레이터가 아닙니다.

코드 변경

“스위스 군용 칼” 같은 클래스를 갖는 대신, 데이터와 인프라 로직을 분리합니다:

// La Entidad: Solo representa qué es un usuario y sus datos esenciales
class Usuario {
    public string $email;
    public string $passwordHash; 
}

// El Servicio: Se encarga de la lógica de autenticación
class AuthService {
    private $hasher;

    public function __construct(PasswordHasher $hasher) {
        $this->hasher = $hasher;
    }

    public function login(Usuario $user, string $password) {
        if ($this->hasher->verify($password, $user->passwordHash)) {
            // Lógica para iniciar sesión...
        }
    }
}

코드를 단순히 작성하지 말고, 엔지니어링을 하세요

여러분에게 부탁드립니다. 코드 위에 코드를 계속 “덮어쓰기”만 하는 사람이 되지 말고, 변화를 만들자고요. 잘못된 함수를 발견했을 때, 그 위에 새로운 함수를 추가하기만 하지 말고, 리팩터링하고, 정리하고, SRP(단일 책임 원칙)를 적용하세요.

코드를 발견한 그대로보다 더 아름답고 읽기 쉽게 남겨두세요. 여러분의 작업을 읽는 다음 개발자는 반드시 “고맙습니다” 라고 말할 것입니다.

레거시 코드와 비슷한 경험을 한 적이 있나요? 댓글로 여러분의 이야기를 들려주세요! 👇