유지보수를 위해 타입은 선택이 아니라 필수가 되어야합니다.

개발하면서 항상 마주치는 상황이 있습니다. 내가 만들지 않았거나 너무 오래되서 기억이 잘 나지 않은 메서드나 변수를 가진 코드를 유지보수하는 문제입니다. 우리는 항상 유지보수의 문제와 맞닿아있기 때문에 유지보수하기 쉬운 코드를 목표하기도 해야합니다. 이 때 타입은 유지보수를 위한 최소 조건이라고 생각합니다.

 

타입을 적용하면 변수는 올바른 유형의 값만 할당할 수 있습니다. 이렇게 하면 오류를 방지하고 코드를 더욱 유지 관리할 수 있습니다. 예를 들어, "int"(정수) 유형의 변수가 있고 "string"(텍스트) 유형의 값을 할당하려고 하면 오류를 발생시킬 수 있습니다. 이것은 큰 문제가 되기 전에 실수를 일찍 발견하는 데 도움이 됩니다.

 

타입이 없을 때 발생할 수 있는 가장 큰 문제는 사람의 실수로 발생할 수 있는 가능성이 타입을 사용하지 않는 어디서나 생긴다는 점 입니다. 타입이 없는 모든 곳은 수정 시 문제가 발생할 수 있습니다. 입력 값의 타입을 잘못 이해한다면 메서드 내에서 에러가 발생할 것이고, 출력 값의 타입을 잘못 이해한다면 메서드 바깥의 사용하는 곳에서 에러가 발생할 것입니다. 내가 작성한 코드가 아니더라도 메서드의 안밖을 이해해야합니다. 타입이 명시되는 것만으로도 메서드의 안쪽을 확인해야하는 이유가 사라집니다.

 

개발을 하면 재사용성을 위해서나 간단한 추상화를 통해 복잡성을 숨기기 위해서나 특정 로직을 메서드로 감싸 제공합니다. 타입이 없으면 재사용할 수 있으나 복잡성을 숨겨 제공하지는 못합니다. 추상화의 주된 목적은 복잡성을 숨기고 단순한 인터페이스를 제공하는 것인데 이 목적을 이룰 수 없습니다. 추상화된 기능을 사용하는 입장에서는 입력값과 출력을 알기 위해 복잡성을 따라 들어가 이해해야하기 때문입니다. 내부의 복잡성을 잘못 이해하고 잘못된 타입을 쓰면 그 잘못된 수행이 실행되기 전까지 알 수 없습니다. 해당 동작을 테스트에서 재현하지 못하면 알지 못한채로 서비스는 사용되고 이는 당연히 장애로 이어집니다. 타입이 명시되는 것 만으로 내부 복잡성을 이해할 필요가 없어지고 잘못 사용한 타입에 대한 문제를 실행하기 전에 인지할 수 있고 서비스 장애를 예방할 수 있습니다.

 

결론적으로, 타입은 오류를 방지하고, 실수를 방지하고, 코드의 가독성과 유지보수성을 향상시키는데 도움이 될 수 있는 강력한 도구입니다. 설정하는 데 시간이 조금 더 걸릴 수 있지만, 장기적으로, 이것은 많은 고통을 덜어줄 것입니다.