올해 회사에서 서비스 안정성 강화가 목표로 제시되어 라이브 중인 서비스에서 크리티컬한 에러가 발생하지 않게 작업하는 것이 최우선 목표가 되었다.
이 과정에서 개발자로 어떠한 상황까지 우리가 수정을 해야 되고 누가 수정을 해야 되는지에 대해 궁금증이 생겨 글을 작성하였다.
문제가 생길 시 누가 수정해야 될까?
내가 어떤 api를 만들었다고 가정한다.
이때 api를 만들면서 내가 작성한 부분만 아니라 다른 개발자가 작성한 코드도 활용해서 만들었다.
그리고 이 부분이 QA에서 이슈가 발생하였을 때 이런 경우 누가 어디를 어떻게 수정하는 것이 맞을까?
사실 이건 뭐가 어떻다고 쉽게 정의할 수 있는 부분은 아니다.
내가 쓴 부분이니 내가 수정하는 게 맞을까?
에러가 난 부분이 다른 개발자가 짠 코드에서 난 거라서 그 개발자에게 넘겨야 될까?
내가 잘못 사용하는 건 아닐까? 등
문제의 원인이 어디냐에 따라 다르겠지만 이러한 상황에서 어떤 원칙을 가지고 수정하는 게 맞는다고 생각한다.
버그와 오류의 차이는???
버그: 일어날 수 없다고 가정한 상황
함수의 선조건 및 후 조건에서 실패하는 경우
발생할 경우 코드를 수정해야 되는 상황
오류: 실제 실행 중 발생할 수 있는 예측 가능한 상황
발생하여도 서비스가 중지되거나 문제가 발생하면 안 되는 상황
내가 찾아본 차이는 이러했다.
간단하게 요약해 보면
버그가 발생 -> 나오지 말아야 할 상황인데 발생
오류가 발생 -> 어떤 방식이든 제어를 한 상황
함수와 함수의 선조 건과 후 조건??
함수는 기본적으로 함수명과 인자, 반환값으로 구성되어 있다.
보통 우리가 잘 작성한 함수라면 함수명으로 최대한 함수의 역할과 기능을 유추하여
내부의 코드 확인 없이 사용할 수 있다고 한다.
이런 작업을 원활하게 하기 위해 우리는 몇 가지 원칙을 지켜서 해야 한다.
1. 함수의 기능은 최대한 한 가지의 명확한 기능만을 가지게 한다.
2. 함수가 받는 인자가 어떤 타입이고 얼마나 필요한지 알아야 한다.
3. 함수가 반환하는 값이 어떤 타입인지 알아야 한다.
사실 1번의 원칙이 핵심인데 이 부분을 잘 지키기 위해서 함수의 선조건과 후조건이 필요하다.
선조건은 함수가 시작할 때 함수의 유효한 작동 범위에 해당되는 값이 들어왔는지 확인하는 부분이다.
만약 나눗셈을 하는 함수에 인자로 int만 적혀있다고 가정한다.
이때 분모의 값이 0으로 들어오게 되면 함수는 예외를 발생하고 작동이 중지된다.
이러한 상황을 선조건을 만족하지 못했다로 볼 수 있고 이러한 상황을 함수 시작 시에 방어하는 로직을 추가해야 한다.
후조건은 함수가 해당 기능을 다 처리하고 반환을 할 때 정확하게 수행했는지 확인하는 것이다.
나눗셈을 하는 함수의 반환값이 소수점 포함인지 정수만 인지를 확실하게 확인하고 반환하는 과정이다.
함수 조건이 버그와 오류와 어떻게 관계가 있는지??
버그가 발생하면 기본적으로 개발자가 예측을 잘못한 것이다.
개발자가 이렇게 들어올 줄 알고 거기까지만 예측해서 작성했기 때문이다.
즉, 이해를 잘못해서 만들어버린 것이다.
따라서 위 함수의 선/후 조건 자체가 아예 잘못된 것이기 때문에 함수를 다시작성해야 한다.
오류가 발생하면 함수의 선/후 조건을 확인하는 과정에서 문제가 발생한 경우이다.
즉, 개발자가 정한 조건에 해당되지 않기 때문에 제어를 한 상황이라고 볼 수 있다.
이 경우 버그와 다르게 함수를 호출한 사람이 조건에 맞게 수정해야 한다.
마무리
보통 개발을 진행할 때 버그와 오류, 에러 이러한 용어를 혼용하고 있는 경우가 많았다.
이때 어디까지 개발자가 어떻게 수정을 해야 되고 공통 로직을 사용할 때 어디까지 수정을 허용해야 되는지 코드 리뷰를 하거나 질문을 받을 때 명확하게 답변을 주기 어려워 이 부분을 찾아보게 되었다.
지금은 코드 내부적으로 범위에 관한 이야기였지만 더 크게 보면 api 호출과 같은 연동에 대해서도 넓어지는 개념이다.
따라서 이 부분에 대해 명확하게 이해를 해야만 타분야 개발자와 협업을 할 때도 도움이 된다고 생각한다.
