누군가 사용하지 않는 코드를 삭제 (또는 유지)하는 장점을 설명 할 수 있습니까?

프로젝트에서 사용하지 않는 코드를 삭제해야한다는 말을 많이 들었습니다. 그러나 나에게 "왜?"는 명확하지 않습니다.

삭제하지 않은 포인트는 다음과 같습니다.

• 코드가 이미 작성되었으며 노력이 소요됩니다.
• 코드는 구문 및 실제 환경에서 테스트 될 수 있습니다.
• 잘 구성되어 있으면 (그룹화, 개별 패키지, 느슨하게 결합 된 등) 전체 코드 분석이나 리팩토링에 방해가되지 않습니다.
• 나중에 코드가 사용될 수 있습니다.
• 삭제되면 작성자가 불편 함을 느낄 수 있습니다.

누군가 사용하지 않는 코드를 삭제 (또는 유지)하는 장점을 설명 할 수 있습니까?

사용하지 않는 코드를 제거해야하는 몇 가지 이유는 다음과 같습니다.

• 프로젝트에 새로 작업하는 사람은 작업 코드를 이해해야 할뿐만 아니라 사용하지 않는 자료도 이해해야합니다. 이것은 낭비되는 시간이며 혼란을 야기합니다.

• 누군가가 실수로 '휴면'코드를 포함하여 버그를 유발할 수있는 변경을 수행 할 위험이 있습니다. 내가 작업 한 프로젝트에서 일어난 일이라는 것을 알고 있습니다.

• 모든 코드의 유지 관리는 관리 부담입니다. 오래된 중복 코드를 보존함으로써 부담이 증가합니다. 예를 들어, 작업 할 코드가 많고 실수 할 가능성이 더 많기 때문에 메인 브랜치의 변경 사항 병합이 더 어려워집니다.

• 시간이 지남에 따라 점점 더 오래된 사용하지 않는 코드가 코드베이스에 추가됩니다. 이것은 혼란, 잠재적 인 오해 및 관리 오버 헤드를 증가시킵니다.

• 사용하지 않은 코드가 다시 사용될 가능성은 거의 없습니다. 시간이 지나면 재사용 가능성이 감소합니다. 코드를 제거하고 충분히 중요한 것으로 간주되면 코드를 분기하여 문서화 할 수 있습니다.

• 코더가 열심히 작업 한 코드에 대한 개인적인 감정은 이해할 수 있습니다. 그러나 전문성을 갖추기 위해서는 더 나은 이익을 위해 그러한 생각을 한쪽으로 치워야합니다. 시간은 아무도를 의미하지 않으며 작동하는 코드베이스에서 기록 코드를 보존 할 장소가 없습니다.

@suspectus는 코드를 삭제하는 이유를 훌륭하게 보여주었습니다. 코드 유지에 대한 개별 총알을 다루고 싶습니다.

• 코드가 이미 작성되었으며 노력이 소요됩니다.

그러나 이미 작성된 코드가 사용되지 않는 경우 이는 (미래) 가치없이 만 비용이 발생합니다. 그것은 헛된 노력에 투자 된 것이며, 이러한 노력의 미사용 제품을 보존한다고해서 그러한 노력이 입증되는 것은 아닙니다. 우리는 코드가 유용하기 때문에 지금은 작성자의 노력을 기념하는 것이 아니라 유용합니다.

• 코드는 구문 및 실제 환경에서 테스트 될 수 있습니다.

죄송합니다. 무슨 뜻인지 모르겠습니다.

• 잘 구성되어 있으면 (그룹화, 개별 패키지, 느슨하게 결합 된 등) 전체 코드 분석이나 리팩토링에 방해가되지 않습니다.

코드베이스에 있으면 아무리 잘 구성되어 있어도 유지 관리 및 이해 부담에 기여합니다. 사실, 될 않도록 구성 할 수 있습니다 덜 부담하지만 사라의 경우는 더 부담이 전혀 없습니다.

• 나중에 코드가 사용될 수 있습니다.

애자일 학교에서는 YAGNI : You Ai n't Gonna Need It 이라고 말합니다 . 예, 당신 은 미래에 그것을 사용할 수 있을지도 모르지만 , 우리는 어떤 종류의 신뢰성으로도 그것을 예측할 수있는 내일의 필요성에 대해 오늘 충분히 알 수 없습니다. 다르게 생각하는 것은 오만함이 오만하다. 우리가 할 수 내일에 대해 알고 것은 : 우리는 우리의 코드베이스가 특징에서 코드 detracts 수정하기 쉽고, 사용되지 않는되고 싶어요.

• 삭제되면 작성자가 불편 함을 느낄 수 있습니다.

저자는 그것을 극복해야합니다. 우리는 모두 유용하지 않은 것으로 밝혀진 내용을 작성했습니다. 사용중인 코드 본문을 가리킬 수있는 것이 훨씬 낫습니다 (사용하지 않는 부분이 삭제 되었기 때문에). 몇 가지 방법, "실제로 사용 중입니다!"

코드를 집어 들고 의도를 파악하는 것이 충분히 어렵지 않습니까? 그러나 이제 사용하지 않는 부분을 파악해야합니까?

코드가 이미 작성되었으며 노력이 소요됩니다.

또한 불필요합니다. 당신이 그것을 아무것도 사용하지 않는다면, 그것이 무엇을하는지 또는 그것에 얼마나 많은 노력을 쏟았는지에 관계없이 (정의상) 쓸모가 없습니다.

코드는 구문 및 실제 환경에서 테스트 될 수 있습니다.

쓸모 없다면 테스트를해도 쓸모가 없다. 코드가 쓸모 없으면 테스트도 쓸모가 없어야합니다 (주석 코드를 그대로 유지하면 모호함이 생깁니다. 테스트를 유지합니까? 주석 코드의 클라이언트 코드가있는 경우 클라이언트 코드도 주석 처리합니까? )

잘 구성되어 있으면 (그룹화, 개별 패키지, 느슨하게 결합 된 등) 전체 코드 분석이나 리팩토링에 방해가되지 않습니다.

별로. 모든 도구 (소스 제어, 정적 분석, 문서 추출기, 컴파일러 등)는 더 많은 데이터를 처리해야하기 때문에 느리게 실행됩니다 (데이터의 더 크거나 작은 부분은 노이즈 임).

반면에 코드가 잘 구성 되지 않으면 정적 분석, 리팩토링 및 기타 문제가 발생합니다.

도구 입력에 노이즈를 도입하고 올바르게 대처하기를 바랍니다.

정적 분석 도구가 주석 / 코드 비율을 계산하면 어떨까요? 어제까지 (또는 코드가 주석 처리 될 때마다) 관련이있는 내용으로 방금 엉망으로 만들었습니다.

무엇보다도, 주석 처리 된 코드 블록은 유지 관리 및 추가 개발을 위해 코드를 이해하는 데 지연을 유발하며 이러한 지연은 거의 항상 많은 비용이 듭니다. 스스로에게 물어보십시오. 함수의 구현을 이해해야한다면 무엇을보아야합니까? 두 줄의 명확한 코드, 아니면 두 줄의 코드와 더 이상 실제가 아닌 26 개의 주석?

나중에 코드가 사용될 수 있습니다.

그렇다면 팀의 선택한 SCM에서 찾을 수 있습니다.

유능한 SCM을 사용하고 데드 코드를 유지하는 데 의존하는 경우 (소스를 복잡하게 만드는 대신) 누가 해당 코드를 삭제했는지 (커밋 작성자)뿐만 아니라 어떤 이유로 (커밋 메시지) 어떤 이유로 그것과 함께 변경되었습니다 (그 커밋에 대한 나머지 diff).

삭제되면 작성자가 불편 함을 느낄 수 있습니다.

그래서?

당신은 "X의 감정을 해치지 않고 당신이 아는 최고의 소프트웨어"가 아니라 당신이 아는 최고의 소프트웨어를 만들기 위해 돈을받는 전체 개발자 팀입니다.

작성된 대부분의 코드가 궁극적으로 폐기되는 것은 프로그래밍의 일부입니다. 예를 들어, Joel Spolsky는 어느 시점에서 그의 회사의 경우 작성된 ​​코드의 약 2 %가 생산을 본다고 말했습니다.

코드베이스의 품질보다 개발자의 자아를 우선시한다면 제품의 품질을 희생하게 될 것입니다. 정확히 무엇을 위해? 동료 개발자의 미숙함을 유지하고 계십니까? 동료의 비현실적인 기대를 보호하고 계십니까?

편집 : 주석 처리 된 코드를 소스에 남겨 두는 한 가지 유효한 이유를 보았습니다. 이는 매우 구체적인 경우입니다. 코드가 이상하고 직관적이지 않은 형식으로 작성되고 깔끔한 재 작성 방법은 그렇지 않습니다. 정말 미묘한 이유로 작동합니다. 이것은 또한 문제를 해결하기 위해 반복적 인 시도를 한 후에 그리고 시도가 동일한 결함을 다시 도입 할 때마다 적용되어야합니다 . 이 경우 주석 처리 된 직관적 인 코드를 주석으로 추가하고 작동하지 않는 이유를 설명해야합니다 (그러므로 미래의 개발자는 동일한 변경을 다시 시도하지 않을 것입니다).

// note by <author>: the X parameter here should normally
// be a reference:
// void teleport(dinosaur& X);
// but that would require that we raise another dinosaur and
// kill it every twelve hours
// as such, the parameter is passed by value
void teleport(dinosaur X);

죽은 코드가 코드를 오염시키고 있습니다

데드 코드는 이해력과 가독성을 떨어 뜨립니다.

최고의 코드는 항상 재사용되며, 데드 코드가있는 경우 재사용 가능성이 줄어 듭니다.

우리는 기계가 아닌 동료 프로그래머와의 상호 작용을 위해 코드를 디자인하는 모듈 식 코딩 방식에 의해 주도됩니다. 우리는 그가 우리 코드를 쉽게 이해할 수 있도록 최대한의 에너지를 쏟아야합니다. 어쨌든 기계는 괜찮을 것입니다.

죽은 코드 나 주석 처리 된 코드는 사람들을 혼란스럽게하는 잘못된 흔적과 같으므로 어떤 대가를 치르더라도 피하십시오.

• 두려움 . 이것은 팀이 더 많이 걱정하고 덜 생산하게 만듭니다. 더 많은 데드 코드가 도입되면 두려움의 양은 기하 급수적으로 증가합니다. "우리는 그 비트가 사용되었는지 알 수 없기 때문에 감히 제거하거나 만지지 않습니다."

• 대대적 인 변화 . 시스템의 모든 곳에서 변경해야하는 것이 데드 코드에도 존재한다면 변경 하시겠습니까? 어딘가에서 확실히 사용되지 않는지 알기가 매우 어렵 기 때문에 항상 위험합니다. 그리고 그것이 아무것도 깨뜨리지 않더라도,이 변경 후 다시 사용하도록 되돌려 놓으면 죽은 코드가 전혀 작동할까요?

  전체적인 변경을 다룰 때 개발자는 코드가 포함 된 모든 위치를 확인해야하며 데드 코드의 경우 중복됩니다. 그리고 코드가 죽었을 때 확인하는 데 시간이 오래 걸립니다. 코드가 어디에도 사용되지 않는지 확인하기 어렵 기 때문입니다.

• 정신 부하 . 무언가가 사용되는지 또는 죽은 코드에 대해 무언가를해야하는지에 대해 생각해야 할 때마다 약간의 두뇌 능력이 필요합니다.
• 기러기 추격전 . "Foobar를 사용하는 방법에 대한 예제가 필요합니다. 오, 코드베이스의이 위치에 있습니다. 첫 번째 히트를 확인하고 UI에서 이것이 어디에 있는지 알아볼 것입니다. 음 ... 어디에서도 찾을 수 없습니다."
• 부풀려진 보고서 (예 : 코드, 클래스, 루틴, 변경 사항의 수). 프로젝트의 가시성과 코드베이스의 어떤 부분에서 작업해야할지 결정하고 향후 프로젝트에 대한 예측을 왜곡합니다.
• 코드베이스에 대한 신뢰가 약화되었습니다 . 이로 인해 중복 작업에 더 많은 시간이 소요될 수 있으며 코드베이스 사용 흐름이 중단됩니다. 개발자는 사용하는 모든 것이 자신이 생각하는 방식으로 작동하는지 매우 신중하게 확인해야 할 수 있습니다.

코드베이스의 일부가 사용되지 않는다는 것을 알고 있다면 제거 할 수 있기 때문에 매우 유용 합니다. 그대로두면 미래에 실제로 사용되지 않는지 확인하는 것이 어렵거나 거의 불가능할 수 있습니다. 예를 들어, 코드를 놀라운 방식으로 사용하는 것 중 일부는 리플렉션, 문자열에서 연결된 동적으로 루틴 호출, eval, 프레임 워크 매직 등 입니다.

그러나 향후 코드가 사용될 가능성이 높은 경우 버전 관리 시스템이 아닌 다른 코드와 함께 있으면 추가하는 것이 더 쉽습니다. 잠시 후 코드에 있던 단어를 기억하지 못할 수 있으므로 VCS의 창자에서 코드를 찾기가 매우 어려울 수 있습니다. 하지만 죽은 코드는 거의 존재하지 않고 코드에 주석을 달았습니다.

• 사용하지 않는 코드는 일반적으로 코드를 스캔하는 모든 것을 읽을 수있는 더 큰 검색 공간입니다. 예를 들어 컴파일러, IDE, 파일에서 찾기, 디버깅, 정적 분석, 검토 할 항목 추가, 파일 포함, VCS에서 체크 아웃 등이 있습니다. 이로 인해 이러한 프로세스가 느려지고 상당한 노이즈가 추가됩니다.
• 사용하지 않는 코드가 항상 죽은 코드는 아닙니다. 특정 상황에서 실행될 수 있습니다. 이는 버그 및 성능 문제에 대한 벡터를 제공 할뿐만 아니라 보안 문제가 될 수도 있습니다. 성능과 관련하여 이것은 대용량 다운로드와 같은 예상치 못한 방식으로 표현 될 수 있습니다.
• 사용하지 않은 코드는 사용하지 않는 코드를 낳습니다. 함수 호출을 삭제 한 다음 해당 함수의 사용을 검색하여 여전히 필요한지 확인하면 이전에 사용하지 않은 코드와 일치하는 것을보고 유지할 수 있다고 가정 할 수 있습니다. 사용하지 않는 코드가 많을수록 코드가 사용되지 않았는지 확인하는 데 더 많은 홉이 있습니다.
• 사용하지 않는 코드는 여전히 유지 관리해야하는 경우가 많습니다. A와 B가 C에 의존한다고 가정하겠습니다. 그 중에서 B는 사용되지 않습니다. C를 변경하면 B가 필요한 C의 구조체에서 멤버를 제거했기 때문에 B가 컴파일되지 않습니다. 이제 B를 수정하거나 컴파일에서 적극적으로 제거해야합니다. 단순히 제거 했어야합니다.

이 목록은 간단 해 보일 수 있지만 이러한 각각은 전체 개발 프로세스에서 시너지 효과를주는 드래그를 추가하는 수백 가지 방법으로 나타납니다. 비 효율성은 종종 간단하고 수학적 방식으로 입증되거나 입증 될 수 있습니다.

귀하의 포인트에 대한 응답으로 ...

• 코드가 이미 작성되었으며 노력이 소요됩니다.

그러나 종종 유지되어야합니다. 파일에서 찾기와 같은 항목에도 여전히 표시됩니다.

• 코드는 구문 및 실제 환경에서 테스트 될 수 있습니다.

이게 무슨 뜻인지 잘 모르겠습니다. 지난번과 같은 것 같아요. 코드가 이미 테스트되었으며 정리하면 다시 테스트해야 함을 의미합니다. 이는 시간의 90 %를 지불하고 생산에 들어가기 전에 청소해야하는 것을 방지하기 때문에 일반적으로 그만한 가치가있는 비용입니다. 거의 모든 코드에는 두 번의 반복이 있습니다. 그 이유는 누군가가 마지막 단계를 건너 뛰었 기 때문입니다. 코드가 너무 비싸서 diff, test (사용하지 않는 많은 코드로 인해 지저분한 경우 일 가능성이 높음)를 읽고 증명할 수 없다면 그것은 또 다른 전체 문제입니다.

• 잘 구성되어 있으면 (그룹화, 개별 패키지, 느슨하게 결합 된 등) 전체 코드 분석이나 리팩토링에 방해가되지 않습니다.

어쨌든 코드는 이와 비슷해야하지만 문제를 적당히 완화 할뿐입니다. 어떤 것이 조직되어야하지만 깨끗하지 않다는 말을 듣는 것은 가장 이상한 주장입니다. 코드를 모듈화로 유지하고 종속성을 줄이는 것은 정상이지만 재사용 가능한 코드도 원하며 모든 모듈이 섬 기회라면 DRY가 아닌 것입니다. 또한 사용하지 않는 지저분한 코드의 문제를 완화하는 것 외에는 아무 일도하지 않는 과도한 분리를 수행 할 수도 있습니다.

• 나중에 코드가 사용될 수 있습니다.

많은 사람들이 작성된 코드를 가치있게 생각합니다. 지금 사용하지 않는다면 그것은 무겁고 실제로이 경로를 따라갈 때 종종 사용되지 않는 코드의 일부만 사용 된 코드가됩니다. 모든 가능성에서 사용되지 않는 코드는 사용 가능하거나 사용되지 않을 가능성이 높습니다. 재사용 가능성이 가장 높은 코드는 이미 사용중인 코드입니다.

더 나쁜 것은 사용하지 않는 코드에는 목적이 없다는 것입니다. 누군가가 와서 사용하지 않는 코드에 영향을 미치는 무언가를 변경해야 할 때, 그들은 목적없이이 사용되지 않는 코드가 무엇을해야하는지 알아 내려고 거기에 앉아 어리둥절하게 될 것입니다.

코드를 시작할 때 많은 노력이 필요하기 때문에 사람들이 쉽게 느낄 수 있습니다. 그러나 유창하고 익숙해지면 자전거를 타는 것과 같습니다. 이러한 코드를 작성하는 데 드는 비용이 유지하는 데 드는 비용이 급감함에 따라 알게 될 것입니다.

• 삭제되면 작성자가 불편 함을 느낄 수 있습니다.

이것이 저자의 문제입니다. 한편으로 다른 사람들이 처리해야 할 사용하지 않는 코드를 남겨 두는 것은 이기적입니다. 다른 한편으로 작성자가 코드 품질에 대한 감정을 표현한다면 아마도 코딩을하지 말아야 할 것입니다. 당신은 그들의 감정을 상하게 할 것이기 때문에 그것이 깨졌을 때 그들의 코드를 고칠 수 없습니다. 누군가가 코드가 좋다 기보다는 자신의 것이기 때문에 코드에 집착한다면 좋은 징조가 아닙니다. 작성자는 코드가 정리되는 것에 만족해야합니다. 이것은 누군가가 당신을 위해 당신의 쓰레기를 꺼내서 쓰레기통에 버리는 것과 같습니다.

누군가 나를 위해 그렇게했다면 나는 달을 넘을 것입니다. 그러한 감정을 극복하기 쉽게 만드는 것은 다른 사람이 그것을하기를 기다리는 대신 스스로 해보는 것입니다. 수행 한 코드를 반복적으로 다시 작성하여 성능을 향상시키고 간결하게 이동하고 과잉과 유연성을 줄이면서 매번 코드를 줄이십시오. 코드의 양에 대해 기분이 좋지 않지만 적은 코드로 얼마나 많은 것을 얻을 수 있는지에 대해 생각하십시오. 이것은 레벨 업을 위해 갈고 닦는 것이며 일단 그렇게하면 모든 코드가 좋은 레벨로 나오므로 자주 레벨을 올릴 필요가 없습니다.

우선 항상 소스 제어 도구를 사용하여 프로젝트를 관리해야하므로 사용하지 않는 코드를 제거하는 것이 좋습니다. 제거 된 코드를 얻기 위해 항상 소스 제어를 사용하여 돌아갈 수 있기 때문입니다. 저에게 사용되지 않는 코드를 제거하는 이유는 코드가 사용되지 않았 음을 아는 사람 만 알고 있기 때문입니다. 팀의 다른 사람이 해당 코드를 발견하여 코드가 무엇을하는지, 전체 애플리케이션에 어떻게 적용되는지 파악하려고합니다. 코드가 전혀 사용되지 않을 정도로 많은 노력 끝에 실망 할 것입니다. :)

이 토론은 몇 년이 지났지 만 방금 만났습니다 ...

내가 언급하지 않은 한 가지는 사용하지 않는 코드를 제거하기 위해 발생해야하는 작업입니다. 대부분의 경우 사용하지 않는 코드를 제거하는 데 드는 시간과 노력은 본질적으로 사소한 일이 아니며 일반적으로 리팩터링 된 시스템을 테스트하고 문서화하는 데 추가 비용이 발생합니다. 의사 결정 과정에서 고려해야 할 또 다른 사항입니다.

두 가지 경우가있을 수 있다고 생각합니다.-응용 프로그램 코드 : 사용하지 않으면 시간이 지남에 따라 테스트되지 않고 관리되지 않을 수 있습니다. "내부 코드 저장소"로 이동할 수 있습니다.-API 코드 : 라이브러리를 작성하는 경우 IMHO 유지하기위한 더 나은 선택이지만 적극적인 개발 프로세스 내에서

코드가 사용되지 않았습니까?

코드가 여전히 컴파일되는지 확인하는 것만으로는 충분하지 않습니다. C ++에서 컴파일러 오류가 발생하지 않는 것처럼 "사용하지 않는" 암시 적으로 정의 된 메서드 를 제거 operator=하면 클래스는 (잠재적으로 잘못된) 기본 구현을 사용하기 시작합니다. Java 또는 C #에서는 리플렉션을 통해 코드를 사용할 수 있습니다. 객체 지향 언어에서는 상속이 역할을 할 수 있습니다 (이제 기본 클래스가 호출 될 수 있음). 거의 모든 언어에서 다른 오버로드 된 함수가 인계되었을 수 있습니다.

사용되지 않았는지뿐만 아니라 버전 관리에서 코드의 수명을 확인하십시오. 사용되지 않은 것처럼 보이지만 방금 커밋 된 코드를 보았습니다. 실제로 다른 개발자 프로젝트의 첫 번째 단계였습니다.

사용하지 않는 코드를 적극적으로 제거

코드 유지 비용 :

• 깨진 빌드 수정 (엔지니어링 시간). 최근에 우리는 #include사용하지 않는 코드에 새로운 오버로드를 도입하여 수십 명의 개발자로 구성된 팀의 모든 엔지니어에게 상당한 규모의 골칫거리로 이어지는 복잡한 변경 체인을 겪었습니다 .
• 테스트의 머신 리소스에서 (자체 테스트 연속 빌드가 있다고 가정). 우리 팀은 최근에 가장 느린 테스트를 모두 살펴 보았고 그 중 상당수는 사용하지 않는 코드를 검토했습니다. 로컬에서 또는 지속적 통합의 일부로 테스트를 실행하는 엔지니어는 사용되지 않는 코드에 대한 테스트를 기다리고 있습니다.
• 가독성 측면에서 (다시 엔지니어링 시간). 헤더 파일은 API를 나타냅니다. 아무도 사용하고 싶지 않지만 모든 사람이 읽어야하는 기능이 포함되어 있다면 코드의 학습 곡선이 훨씬 더 어려워집니다.
• 코드 검색에서 (엔지니어링 시간 다시). 집, 하드 드라이브 또는 Google 드라이브를 청소 하시겠습니까? 도메인을 더 많이 검색할수록 오탐 (또는 웹 검색 엔진과 같은 더 정교한 검색을 사용)을 방지하기 위해 관련 콘텐츠가있는 것이 더 중요합니다.

나는 본질적으로 평균 개발자가 작성하는 모든 코드가 5 년 동안 사용되지 않아이 활동이 멈추지 않는다고 말하고 싶습니다 . 이것이 당신이되게하지 마십시오. 고품질의 절대적으로 필요한 코드 만 작성하십시오.