if 지옥에 빠지다

if문 지옥에 빠졌다.

if문 최대 중첩이 6단계이다. 그 외 평균 3~4개의 중첩 if문이 보인다.

for문 중첩도 최대 4개까지 있다.
도메인 로직이 if문 안에 꼭꼭 숨겨져 있다.
코드를 볼 때 마다 새롭고, 유지보수에 들어가는 비용이 크다.
해당하는 서비스를 관리의 영역으로 둘 수가 없어, 새로운 업무를 적극적으로 맡을 수가 없다.

 

중첩 if문으로 인한 가독성 저하

로직을 위해서는 if 문은 필수이다. 하지만 if 문이 중첩되어 있다면 가독성은 점점 떨어지게 된다.

if(true) {
    if(false) {
        if(true) {
        }
    }
}

이런 코드를 만나면 가정의 고리를 계속 머릿속에서 이어 나가야 한다.
첫 번째 if문은 쉽다. 하지만 두 번째 if문을 만나면 첫 번째 if문을 다시 생각해야 하고, 세 번째 if문을 만나면 두 번째 첫 번째 if문을 다시 생각해야 한다.
우리의 뇌는 멀티태스킹을 싫어한다.

if 중첩을 만나면 우리의 뇌는 힘들어 하게 되어 있고, 이로 인해 여러가지 문제점을 발생시킬 수 있다.

심지어 if 괄호에 들어가는 조건문이 참과 거짓으로 짬뽕되어 있다면 우리의 뇌는 더욱 더 피로해지고, 생각의 오류를 발생시킬 수도 있다.
if문을 잘못 작성하여 프로그램이 오동작하는 상황을 많이들 겪어봤을 것이다.

더군다나 테스트도 힘들어진다.

위와 같은 if 중첩보다는 다음처럼 1단계로 풀어 놓으면 좋다.

객체지향을 적용하여 여러 클래스로 쪼갤 수도 있겠다.

if() {
} else if() {
} else if() {
}
 
if() {
}
if() {
}
if() {
}

여튼 반복문 조건문 중첩은 최대 2단계 까지를 추천한다.

 

다 고쳐?

일부 코드에서 중첩 if문이 발견됐다면 리팩토링하여 마무리 지었을 것이다. 하지만 전방위적으로 여러곳에 분포되어 있다.
고쳐? 말아?

상황에 따라서 적절하게 대처하는 자세

만약 팀에서 코드 개선에 대한 성과를 책정하고, 코드에 대한 품질 관리를 잘하고 있다면 리팩토링한다.

시간이 걸리더라도 하나씩 하나씩 고쳐나갈 것이다.
하지만 코드 보다는 새로운 서비스에 더 많은 성과를 책정하는 조직이라면 고치지 않을 것이다.

이 말이 꼭 성과우선주의라고 받아들여질지 모르겠다.

오해하지 않았으면 한다.
이처럼 행동해야 하는 이유는 후자의 팀에서는 새로운 서비스에 대한 니즈가 많다.
"코드 리팩토링 때문에 새로운 업무를 맡을수가 없어요" 라는 대처 방식은 팀이 나아가는 방향과는 정반대의 길을 가게된다.
좋은 의도로 시작하게 된 코드 개선이 자칫 팀이 나아가는 방향과 반대의 방향으로 가게 될 수 있고, 이로인해 팀의 분위기를 망칠 수 있다.

최근에 깨달은 바는 사람들은 자신의 이익에 맞게 생각하고 행동한다는 것이다.
"왜 우리 상사는 코드 품질에 대한 성과는 인정해 주지 않는 것일까?"
"우리팀에 새로운 기술을 안착시키고, 공부한 기술들을 전파했는데 내 성과는 왜 이모양이지?"
해당하는 조직에서 추구하는 성과의 기준이 다르기 때문이다.
사실 나도 이 부분에 대해서 이해하지 못했었고, 개발자라면 코드의 품질이 최우선 아니야? 라는 생각이 강했다.

하지만 이건 내 기준이고, 조직에서의 룰은 그들의 이익에 맞게 움직이고 책정되었다.
후자의 조직에서 내가 코드 개선을 하고 장애를 내면 리스크만 더 커진다.

이로인해 업무에 대한 회의감이 찾아 올 수도 있다.
좋은 의도로 시작한 코드 개선이 오히려 비수가 되어 나에게 날아올 수 있다.

나의 선택

우선 잘 유지보수 한다. 정말로 불필요하고, 이건 수정해도 100% 장애 안 나라는 확신이 드는 코드들에 대해서는 리팩토링을 한다.
그리고 장애가 발생했을 때 빠르게 대처가능할 정도의 환경 구성과 준비를 철저히 해둔다. 코드를 다 이해하진 못했더라도 큰 그림은 이해하고 있기에 디버깅과 이슈 해결에는 큰 무리가 없다.
대신 새로운 기능이 추가된다면 별도의 신규 서버를 만들고, 점진적으로 신규 서버로 기능을 이전한다.