7. 똥통에서 뒹굴기

누구나 늪과 같은 코드를 만나본 적이 있을 것이다. 알지 못하는 사이에 코드 속에서 허우적 거리다가 결국 점점 빠져들고 있음을 깨닫는다.

코드가 꽉 짜여 있어 고치기도 어렵고, 뭔가 바꿔 보려 하면 많은 에러를 뱉어 낸다. 바꿔보려 할수록 그 속에 더 깊이 빠져들 뿐이다.

1.  눈치 채기

훌륭한 코드는 순수 예술이나 한 편의 시와 같다. 그러나 언제나 이런 시와 같은 훌륭한 코드만 존재하진 않는다.

이상한 코드를 효과적으로 다루기 위해서는, 문제 지점을 어떻게 찾고 다룰지 알아야 한다.

※ 나쁜 코드를 언제든 만날 수 있다는 마음의 준비를 하자. 나쁜 코드를 다룰 때 쓸 강력한 도구들을 미리 준비해 두자.

2. 헤쳐 나가기

더러운 코드를 만들게 된 이유부터 냉정하게 분석해야 한다.

더러운 코드를 방금 발견 했다고 하자. 어디서 부터 건너뛰어야 할까? 아마 코드에는 낙인이 찍혀 있을 것이다. 그게 잘못되었음을 알기에 그 누구도 건드리려 하지 않았을 것이다.

한편 처음엔 모르다가 빠져들어가기 시작한 후에야 비로소 알아보는 코드도 있다.

과언 정말 끔찍하게 더러운 코드일까? 진짜 늪과 같은 코드인가 아니면 단지 친숙하지 않을 뿐인가? 충분히 살펴보기 전까지는 코드나 코드를 작성한 사람에 대한 경솔한 판단을 내려서는 안 된다.

조잡한 코드를 일부러 짜는 사람은 거의 없다. 

※ 나쁜 코드를 만낫을 때 느껴지는 혐오감을 참자. 대신 그걸 나아지게 할 방법을 찾아보자.

3. 조사결과

새로운 코드에 대한 심성 모형을 만들고 나면, 코드의 품질을 측정해 볼 수 있다.

• 외부에 노출하는 API는 깔끔하고 합리적인가?
• 자료형을 잘 고르고, 변수 명을 적절히 지었는가?
• 코드의 레이아웃을 정돈하여 일관성 있게 작성 하였는가? 
• 객체들의 협업 구조가 보기에 간결하고 명확한가? 아니면 코드베이스 전반에 제어 구조가 예측할 수 없기 얽혀 있는가?
• 특정 기능을 구현하는 코드 부분이 어디에 있는지 쉽게 찾을 수 있는가?

이러한 조사에 소프트웨어 고고학을 도입해도 좋을 것이다. 

코드 품질이 어떠한지에 대한 단서를 찾기 위해 버전 관리 도구의 로그를 확인하고 결정하자.

• 이 코드는 얼마나 오래되었는가?
• 전체 프로젝트에 있어서 파일은 얼마나 오래되었는가?
• 얼마나 많은 사람이 그 파일로 작업을 하였는가?
• 마지막으로 수정된 건 언제였는가?
• 최근 작업한 참여자 가운데 아직 프로젝트에 남아 있는 사람은 있는가?
• 코드에 대한 정보를 얻기 위해 그들에게 질문할 수 있는가?
• 이 영역에서 얼마나 많은 버그가 발견되고 수정되었는가?

4. 수렁에서 일하기

헤어나기 어려운 늪이나 다름없는 코드를 찾아냈다면, 긴급 상황에 처한 것이다. 그것을 다루기 위해서는 적절한 전략이 필요하다.

• 나쁜 코드를 고쳐야만 하는가?
• 현재의 문제를 해결할 최소한의 수정만 한 뒤, 달아나야 할까?
• 괴사 부위를 도려나고, 새롭고 더 나은 코드로 바꿔야 할까?

대부분의 문제는 이후의 계획을 통해 적절한 방향을 정할 수 있다. 해당 코드를 다루는 일에 얼마동안 투입될지를 할 수 있다면, 어느 정도의 시간과 노력을 들여야 할지 판단할 수 있다. 시간이 없다면 전체를 뒤엎으로 하지 말자.

시간을 지혜롭게 쓰자. 코드를 별로라고 생각할 수 있겠지만 별다른 수정 없이도 몇 년 동안 적절히 작동했다면, 지금 수정하는 것은 적절하지 않을 수 있다. 이후에 훨씬 더 많은 부분을 수정해야 할 수도 있다.

지금 당장 코드를 수정하는 게 적절하지 않다 판단했다고해서, 오물 위에 둥둥 떠다녀도 된다는 건 아니다. 이후에 점진적으로 수정해나가면서 코드를 개선할 수도 있다.

※ 전투지역을 선택하자. 나쁜 코드를 수정하는 데 시간과 노력을 들여야 할지를 주의 깊게 판단하자. 지금은 그 대로 놔두는 게 실리적일 수도 있다.

5. 치우기

오랜 시간 작업하든 간단한 수정만 하든, 로버트 마틴의 조언인 보이스카우트 규칙을 따르자.

" 캠핑 지역은 항상 캠핑 전보다 더 깨끗하게 정리하고 떠나자 "

오늘 광범위한 수정을 하기 적절하지 않다고 해서 조금도 나아지게 할 수 없다는 것은 아니다.

간단한 수정이라도 좋다. 코드 외간을 정리하거나. 오해의 소지가 있는 변수 명을 적절하게 바꾸자. 복잡한 분기를 간단하게 바꾸거나. 거대한 함수는 더 작으면서도 적절히 명명된 작은 함수들로 나누자.

주기적으로 코드 일부라도 확인하고 그때마다 조금씩 나아지게 만든다면 머지 않아 좋은 결과물을 만들어낼 수 있다.

6.수정하기

1. 기능을 변경 하면서 코드의 레이아웃을 바꾸지 말자. 꼭 필요한 경우 레이아웃을 변경하자. 그런 다음 해당 코드를 소스 관리 도구에 커밋을 한뒤에 기능을 변경하자( 다만 코드 레이아웃이 마음에 들지 않는 경우에만 변경하길 추천한다 )
2. 수정으로 인해 기존 기능에 문제가 생기지 않음을 보장할 수 있는 모든 수단을 사용하자. 신뢰할 만한 자동화 도구를 사용하자. 그런 도구를 사용할 수 없다면 변경 사항들에 대해 충분히 세심하게 검토하고 검증하자. 다른 사람들의 도움을 청하자. 이러한 방향이 바로 리팩토링의 첫 번쨰 요구 조건이다. 리팩토링은 코드 구조를 향상시키기 위한 일련의 기술들을 뜻한다.
3. 이 목표에 효과적으로 도달하려면 적절한 단위 테스트들로 코드를 충분히 둘러싸야한다. 지저분한 코드 주변에 테스트 코드가 전혀 없는 것 같다면, 코드의 주요형태와 관련된 몇몇 테스트 코드를 먼저 작성하는 것에 대하 고려하라.
4. 코드를 감싼 API를 수정하되 내부 로직을 직접 수정하지 말라. 적절한 명치과 매개 변수 타입, 순서를 가지도록 수정하라. 이는 코드 전반에 걸쳐 일관되어야 한다. 아니면 새로운 외부 인터페이스를 만들 수도 있다. 기존 API를 통해 새로운 외부 이너페이스를 작성하고 이후 내부구조를 변경할 때 이 이너페이스의 내부도 변경하면 된다.

코드 변경에 대해 할 수 있다는 용기를 가지자. 안전망인 소스 관리 도구는 이미 마련되어 있다. 실수를 하더라도 금세 되돌리고 다시 수정해볼 수 있다.

이러한 과정은 낭비가 아니며 이를 통해 코드 그 자체나 코드의 변경 가능성에 대해 알 수 있기 때문이다

7. 나쁜코드? 나쁜 프로그래머?

나쁜 코드로 인해 작업이 더뎌지는 건 실망스러운 일이다. 하지만 효율적으로 일하는 프로그래머는 나쁜 코드뿐만 아니라 그 코드를 작성한 사람들도 적절히 다룬다. 코드에 비난을 퍼붓는 건 도움이 되지 않는다. 이부러 잘못된 코드를 작성하려는 사람은 거의 없기 때문이다.

어쩌면 원 저자는 코드 리팩토링의 필요성에 대해 이해하지 못했을 수도 있다. 혹은 로직을 짜임새 있게 표현할 방법을 찾지 못했을 수도 있다. 그밖에도 미처 알아채기 어려운 그와 유사한 일들이 있었을 수도 있다. 어쩌면 빨리 끝내라는 압박 때문에 원칙을 무시했을 수도 있다.

하지만 당신은 더 잘 알고 있다. 가능하다면 코드를 변경할 기회를 즐기자. 더럽고 지저분한 코드에 적절한 구조와 청결함을 불어넣는 작업은 꽤 보람이 있다. 별 의미 없는 작업이라 치부 하기보다는 더 나은 품질을 실현할 기회로 삼자. 연습이라고 생각해도 된다. 배워나가자 어떻게 해야 똑같은 코딩실수를 반복하지 않을 수 있을까!