[A Philosophy of Software Design] chapter 16. Modifying Existing Code

2 minute read

개요

우리는 끊임없이 소프트웨어를 수정하고 점진적으로 발전시킬 것이다. 그러는 과정 중에 디자인이 변경될 수 있다.

우리는 이번 장에서 기존에 존재하는 코드 혹은 디자인을 변경할 때 복잡성을 줄이는 방법에 대해서 이야기해보자.

전술 프로그래밍과 전략 프로그래밍이 존재한다. 전술 프로그래밍은 일단 해당 요구사항을 돌아갈 수 있도록 만드는 것이다. 이것은 시스템을 더욱 복잡하게 만든다. 우리는 전략 프로그래밍으로 좋은 디자인 설계를 계속 유지하도록 노력해야 한다.

우리는 요구사항을 받았을 때 전략적이 아닌 전술적으로 생각하여 최소한에 변경에 대해서만 집중하게 된다. 그렇게 되면 자연스럽게 복잡성을 올라간다.

우리는 전략 프로그래밍을 사용하는데 있어서 여러 변명을 한다. 많은 변경은 오히려 버그를 만든다는 것인데 그러면서 자연스럽게 전술적으로 프로그래밍한다.

우리가 좋은 디자인 설계를 유지하기 위해서는 많은 저항이 있다. 현실적으로 많은 시간이 투자될 수도 있다. 그렇다고 하더라도 이런 마음을 가지고 꼭 전략적으로 좋은 디자인을 유지하도록 노력해라. 이것도 투자마인트 큰 부분이다.

If you’re not making the design better, you are probably making it worse.

코드를 수정하게 되면 자연스럽게 코멘트가 맞지 않은 경우가 존재합니다. 그런 상황이 반복되면 개발자들은 코멘트를 불신하게 될 것입니다. 이런 것을 방지하기 위해서 이야기를 나눠봅시다.

코멘트를 업데이트하는 가장 좋은 방법은 연관된 코드와 코멘트를 가까이 나두는 것입니다. 멀어지면 멀어질수록 업데이트하기가 어려워 집니다.

구현과 관련된 주석은 파일 첫번째가 아닌 실제로 구현과 관련된 메소드 첫번째 줄에 작성하십시오.

일반적으로 코멘트와 코드가 멀어지는 경우에는 코드보다 더욱 추상적인 경우이며 추상적이기 때문에 변경이 자주 일어나지 않을 가능성이 높습니다.

가장 많이 하는 실수 중에 하나는 코멘트로 남겨야될 내용을 커밋 로그로 남기는 것입니다. 개발자가 해당 커밋 로그를 볼 수 있지만 해당 정보를 찾아보기 위해서 찾는 경우가 매우 드물것입니다.

그 뿐만 아니라 해당 정보가 commit에 있는지를 알지 못할 것입니다.

만약 향후 해당 정보가 사용될 것 같다고 생각하는 경우 commit log가 아닌 코멘트와 함께 코드에 작성하십시오.

코멘트를 최신화로 유지하는 두번째 방법은 중복을 제거하는 것입니다. 한곳에서 문서화를 진행했다고 중복적으로 다른 곳에서 문서화하지 마십시오.

만약 여러 곳에서 사용되고 있다면 가장 문서(코멘트)를 잘 볼 수 있는 곳에 작성하십시오. 여러 곳에서 사용되는 변수 같은 경우 해당 변수가 만들어지는 곳에 코멘트를 작성하면 좋을 것입니다.

만약 좋은 장소가 없다면 13.7에서 이야기한 designNotes 파일을 관리하여 코멘트를 작성하십시오.

한 모듈에 대한 설계 결정을 다른 곳에서도 사용하지 마십시오. A라는 메소드를 호출하는 B에 A에 대한 설명을 적지 마십시오. 정말 궁금하다면 A 메소드를 통해서 정보를 얻을 수 있을 것입니다.

변경 사항을 적용하기 전에 변경된 모든 정보를 가볍게 읽어보십시오. 그런 이후 코멘트나 문서가 잘 정리되었는지 확인하고 수정하십시오.

이런 과정은 빠트린 이슈나 정리해야될 코드 및 코멘트를 발견할 수 있을 것입니다.

높은 추상화 수준에 코멘트는 구체적인 코드 사항을 설명하고 있지 않기 때문에 작은 코드 변화에 대해서 코멘트를 수정할 필요가 없다.

13장에서 봤듯이 구체적인 코멘트를 작성해야 되는 경우를 제외하고 일반적인 설명을 통해서 코멘트를 작성하는 경우 수정이 많이 이루어지지 않아 관리하기 쉽다.