3. 코드 적게 쓰기

많은 양의 코드 작성이 곧 다량의 소프트웨어 개발을 의미하지는 않는다. 소프트웨어의 어떤 코드들은 사용자 경험의 질을 떨어뜨리거나 결함을 발생시켜 결과적으로 전체 개발량에 부정적 영향을 미친다. 

소프트웨어를 개선하는 최고의 방법 가운데 하나는 바로 코드를 제거하는 것이다.

1. 코드에 신경써야하는 이유

• 소프트웨어 시스템이 기능하는 한 코드들은 유지 보수 되어야 한다. 각 줄의 코드마다 비용이 든다. 코드를 길게, 많이 쓸수록 유지 보수 비용은 높아진다.
• 수많은 코드란 읽고 이해해야 할 내용이 많음을 의미한다. 이는 프로그램을 파악하기 더 어렵게 만든다.
• 코드가 많을수록 수정해야 할 부분도 많아진다.
• 코드는 버그를 품고 있다. 코드가 많을수록 버그가 숨을 수 있는 공간도 많아진다.
• 중복 코드는 특히 치명적이다. 하나의 버그를 고쳐도 다른 곳에 똑같은 작은 버그들이 남아 있을 수 있다.

2. 허술한 논리

무의미한 코드의 간단하고 흔한 사례로 조건문과 중복적 논리 구조의 남발을 꼽을 수 있다.

시시한 말들을 잘라내고 명백하고 간결하게 표현하라.

3. 중복

코드가 중복되는 것은 보통 잘라내기와 붙여넣기를 통해 발생한다.

코드를 복사한다는 것은 존재하는 버그는 모두 복사하되 반복 구조는 숨긴다는 뜻이다. 한 부분에서 일부의 버그를 잡았다 해도, 복사된 다른 부분에 같은 양의 버그가 그대로 남아있다. 리팩토링은 중복된 코드를 하나의 함수로 만드는 일이다.

DRY( Don`t Repeat Yourself )라는 말이 있다. 우리는 불필요한 중복 없는 DRY코드를 목표로 한다. 비슷한 코드를 하나의 공토함수에 넣으면 해당 함수를 사용하는 코드들은 긴밀한 결합도를 가지게 된다는 사실을 알아야한다.

이 코드들은 모두 공유된 인터페이스에 의존하는데, 인터페이스 수정 시 수정된 내용은 연계된 코드에 모두 적용되어야 한다. 대부분의 경우 완벽하게 들어맞지만 항상 원하는 결과가 나오는 것은 아니며 장기적으로 더 많은 문제를 초래할 수 있다.

4. 죽은 코드

유지 보수를 거치지 않은 코드는 서서히 부식하고 심지어 죽을 수도 있다. 죽은 코드란 실행되거나 호출되지 않는 생명력 없는 코드를 말한다. 생명을 불어넣어주지 않으면 코드는 사라져버린다.

아래와 같은 징후를 나타낸다면 그 코드는 현재 죽어가고 있는 코드다.

• 한 번도 호출되지 않는 함수
• 선언되었지만 할당되지는 않는 함수
• 내부 메서드에 전달되었지만 사용되지는 않은 매개 변수
• 전혀 사용되지 않는 열거형, 구조체, 클래스, 인터페이스

5. 주석

좋은 코드는 작동법을 설명하는 대량의 주석을 필요로 하지 않는다.  변수, 함수, 클래스 이름의 적절한 선택과 올바른 구조는 코드를 더 명확하게 만든다. 주석에서 모든 정보를 복사해 표현하는 것이야말로 불필요한 중복이다.

( 모든 주석이 코드에 가치를 더하지는 않는다는 것을 명심하자. 코드는 그 자체로 무엇을 하고 어떻게 작동하는지를 나타낸다. 주석은 그 이유를 설명하는 것으로, 코드만으로는 이유가 명확하게 드러나지 않을 때만 주석을 달아야 한다. )

복잡한 코드베이스에 들어가 주석 처리로 삭제된 이전 코드를 보는 일도 흔하다. 절대 하지 말아야 하는 행동이다. 그것은 완벽히 코딩할 자신이 없는 개발자, 혹은 자신이 무엇을 하고 있는지 이해하지 못했거나 나중에 다시 코드를 이식해야 한다고 생각한 사람이 남긴 표식이다. 불필요한 코드는 완벽히 제거해야한다.

6. 정황한 내용

많은 코드가 쓸데 없이 수다스럽다. 내용이 장황해지는 만큼 작성자의 의도를 파악하기는 더더욱 어려워 진다.

변수의 선언 부분과 정의 부분을 같은 위치에 작성하자. 코드 이해에 필요한 노력을 최소화하고 초기화되지 않은 변수로 인한 잠재적 에러를 줄이기 위함이다.

7. 나쁜 설계

가끔은 설계상의 문제가 발생할 수도 있다. 나쁜 설계는 분명한 이유 없이 수많은 여분의 데이터를 정렬하는 것과 같은 컴포넌트 간의 불 필요한 의사소통을 조래할 수 있다. 데이터가 많아질수록 더 많은 오류가 발생할 것이다.

시간의 흐름과 더불어, 컴포넌트는 사용되지 않는 많은 코드를 남겨둔 채로 원래의 의도와 다르게 변화해 간다. 이러한 현상이 발생할 경우 죽은 숲을 갈아엎는 것을 두려워 하지 말아야 한다. 오래된 컴포넌트를 필요한 것만 가지고 있는 간결한 컴포넌트로 바꿔야 한다!

8.그래서 ?

불쾌한 코드는 고의성을 띠지 않는다. 대부분의 개발자는 힘들고, 중복되며, 무의미한 코드를 의도적으로 작성하지 않는다. 이러한 문제는 오랜시간 동안 많은 사람에 의해 유지 보수되고 확장되며, 공유되고 디버깅된 코드 레거시로 해결될 수 있다.

그렇다면 어떻게 해야할까.. 책임감을 느껴야 한다. 불필요한 코드를 쓰지 ㅁ라고, 레거시 코드를 작업할 때는 경고 표시에 주의해야한다. 또한 철저해져야 할 떄가 필요하다. 공백을 개선하고 어지러운 코드를 줄이며 균형을 유지하자.

단, 정돈은 다른 기능적 변화와는 별개로 전개되어야 한다는 간단한 규칙에 유의하자. 그래야만 소스 관리 시스템에서 어떤 일이 일어 났는지 명확하게 파악할 수 있다. 기능적 수정과 불필요한 구조 변화가 섞여 있는 경우 불필요한 것들을 추적하기 어려워진다.

9. 결론

소프트웨어 기능은 코드의 라인수나 컴포넌트 수와는 관계없다. 더 많은 줄의 코드가 더 좋은 소프트웨어를 의미하지는 않는다. 따라서 필요하지 않다면 코딩하지 말자. 적게쓰고 더 재미난 것을 만들자.

※리팩토링

리팩토링이라는 용어는 1990년대 들어 프로그래머 사전에 등장했다. 마틴 파울러의 저서인 [ 리팩토링: 프로그램의 가치를 높이는 코드 정리기술 ]을 통해 유명해 졌다. 요즘들어 이 리팩토링이라는 용어가 가끔씩 잘못 사용되는 경우가 종종있다.

이 용어는 결과의 변경 없이 기존 코드의 구조를 재조정하는 것 으로 설명 할 수 있다. 

즉 리팩토링은 작동은 그대로 유지한 채 소스코드를 바꾸는 것을 가리킨다. 프로그램의 작동 방식을 바꾸는 것은 개선 이지 리팩토링이 아니다. UI의 조정 또한 정돈 이지 리팩토링이 아니다.

리팩토링은 코드의 가독성을 높이고, 내부 구조를 향상하며, 유지 보수를 원활히 하기 위한 것이다.

더 나은 로직 조각들 안으로 기능성을 분산시키는 클래스 추출, 및 메서드 추출,

적절한 위치로 옮겨 가도록 해주는 메서드 명 변경, 상하향 처리 등이 포함된다.

제대로된 리팩토링은 훈련이 필요하며, 의심스러운 코드를 커버하는 적절한 단위 테스트를 통해 단순화 할 수 있다.