1.4코드 줄여 개선하기

간단하고, 불필요한 것이 없으며, 끝이라고 확실하게 답할 수 있는 것을 아름답다고 여긴다.

— 랄프 왈도 에머슨

제멋대로인 코드

불필요한 코드가 만들어지는데는 여러가지 이유가 있다. YAGNI(You Aren't Gonna Need It)라는 원칙으로, 당장 필요하지 않으면 굳이 작성하지 않는 원칙을 세우는게 좋다.

• 추가 코드가 그냥 재밌어서 작성했다: 코드는 단지 작성하는 과정을 즐기기 위해 작성하는 것이 아니라, 의미가 있을때만 작성되어야 한다.
• 미래에 필요할 것 같은 기능을 작성했다: 당장 필요하지 않으면 작성하지 마라.
• 실제로 필요한지 사용자들에게 확인을 거치는것보다 만드는게 더 쉽다: 추가 코드를 작성하고 유지하는데는 항상 시간이 더 많이 든다.
• 문서에도 없는 추가 요구사항을 제멋대로 만들었다: 시스템 요구 사항은 사용자의 몫이다.

불가피한 결과물

신규 기능을 불필요하게 추가하지 않았더라도, 소프트웨어 개발 과정에서 코드가 사장되기도 한다. 이런 경우는 불가피한 일들 때문에 생긴 것이다.

• 백엔드 지원 코드에 남아 있는 경우: 몇몇 기능이 UI에서는 제거되었고, 결코 다시 호출되지 않을것이지만 '언젠가 필요할지도 모르고, 당장 제거되지 않아도 문제를 일으키지 않기 때문'에 남는다.
• 더는 사용되지 않는 자료형 또는 클래스
• 기존 제품의 기능들이 거의 제거되지 않는 경우: 유저들이 안 써서 필요 없는 기능이지만 제거하기를 원치 않는 경우
• 코드에 대한 오랜 기간의 유지보수로 인해 함수 일부가 실행되지 않음: 루프문 위의 조건문이 추가됨으로 루프로 아예 진입조차 안하는 경우도 있다.
• 잘 사용되지 않는 이벤트 핸들러
• 전혀 사용되지 않는 함수 반환 값
• 디버그 코드: 진단용 로그나 진단용 함수

외과적 적출

죽은 코드는 그냥 잘라내면 된다. 이전 기능이 다시 필요할 때는 버전 관리 시스템을 통해 가져올 수 있다. 특히, 미래에 필요할지도 모르는 기능이라도 코드를 제거하는 것이 안전하다.

이 경우 다음과 같은 반론도 가능하다: 신입사원이 왔는데 존재여부조차도 모르는 제거 코드가 이미 버전 관리 시스템 안에 있어서, 자신만의 버그가 있거나 불완전한 버전을 작성하는 것을 어떻게 막을 수 있는가? 사실, 이런 일때문에 죽은 코드를 제거하는 정리 작업과 기능 추가 작업은 분리되어야 한다.

---

🥸 생각해보기

1. 프로그램에서 작동하지 않는 '죽은 코드'를 어떻게 식별할 수 있는가?

개인적으로는 기능을 추가하면서, 관련된 필요한 코드를 보다가 어떤 파일은 전혀 쓰이지 않는다는 사실을 깨닫고 지우거나, 동료에게 물어봐도 잘 모르겠다고 하지만 그래도 좀 불안한 경우 주석처리를 해두었다가 나중에 지웠다.

요즘은 빌드 과정에서 ESLint가 unused var등 불필요한 코드를 지울 수 있는 실마리를 잘 제공해주는 것 같다. 다만, 기능적인 측면에서 필요없는 코드는 직접 보고 식별해야할 것이다.

2. 현재 일시적으로 필요하지 않은(그러나 미래에는 필요할 지도 모르는) 코드를 제거할 때, 소스 트리에 주석 처리하여 눈에 띄게 남겨두는가? 아니면 완전히 삭제하는가? 이유는 무엇인가?

코드의 성격에 따라 달랐다. 예를 들어, 얼마전 회사의 BM을 바꿨는데 BM을 종종 바꿀것이라는 말에 이전 정책의 가격들, 혜택들 등의 히스토리를 남기는게 좋을것 같아 주석 처리했다. 지금 생각하면 굳이 그럴거 없이 다 지워도 되었다. 히스토리가 필요할것 같아 남긴 코드들 중 내가 다시 본 코드는 없었던걸로 기억한다.

그 외 기능과 관련된 부분은 괜히 더 헷갈릴 수 있으니 완전히 삭제하는 편이다.

3. 사용하지 않는 레거시 기능을 제거하는 것은 항상 적절한가? 코드 일부를 제거할 때 내재된 위험이 있는가? 불필요한 기능을 제거하는 적절한 시점을 어떻게 결정할 수 있는가?

아무래도 해당 레거시 기능이 어떻게 연관되어 있을지 몰라서 제거하는 것에는 두려움이 앞서는게 사실이다. 회사에 와서 어느 정도의 시간이 흘러 코드베이스에 꽤 자신이 생겼을 때, 어떤 코드가 아무 기능도 없다고 판단해 지웠는데 좀 지나고보니 해당 코드는 드문 케이스지만 여전히 쓰이고 있었다. 남이 쓴 코드를 지울때는 특히나 해당 코드의 작성자와 잘 상의를 해야한다는 사실을 알 수 있었다.

불필요한 기능을 제거하는 시점은 아무래도 눈에 띌때가 될 것이다. 주기적으로 모든 코드 파일들을 들여다보며 필요 여부를 따지는 것은 비현실적인것 같고, 불필요한 기능은 해당 기능을 제거할 때나 신 기능 추가시 눈에 띌때 제거하는게 현실적이라고 생각한다.

4. 현재 프로젝트의 코드베이스에서 불필요한 부분이 얼마나 되는가? 당신의 팀은 유용하다고 여겨지거나 마음에 드는 기능을 제멋대로 추가하는 문화를 가지고 있는가?

불필요한 코드가 있을것 같다는 생각은 들지만, 얼마인지는 잘 감이 잡히지 않는다. 다른건 몰라도 특히 css 관련된 부분에서 안 써도 되는데 쓴 코드가 아마 아주 많을것이라 생각한다.(부모 컴포넌트에 있는 속성을 자식 컴포넌트에서도 쓰는 등)

우리 팀은 마음에 드는 기능을 어느 정도 제멋대로 추가하는 문화를 가지고 있는데, 아무래도 스타트업이고 코드 규모가 엄청나게 크지는 않다보니 괜찮다고 생각하는 아이디어는 동료에게 의견을 간단히 물어보고 바로바로 옮기는 편이다. 이 방식은 물론 코드베이스에서 불필요한 부분들을 늘리지만, 사용자들에게는 서비스가 잘 유지보수되는 사이트라는 이미지를 줄 수 있다고 생각한다. 하지만 물론 이 방식이 오래 지속가능할것 같진 않다.