소스의 무의미한 코드

나는 수석 코더들로부터 이것에 대한 이야기를 들었고 그 중 일부를 직접 보았습니다. 무의미한 코드를 작성하는 프로그래머가 몇 명 이상인 것 같습니다. 나는 다음과 같은 것을 볼 것이다 :

• 가치가없는 메소드 또는 함수 호출.
• 중복 검사는 별도의 클래스 파일, 객체 또는 메서드에서 수행됩니다.
• if 항상 참으로 평가되는 진술.
• 회전하고 아무 것도하지 않는 스레드.

몇가지 말하자면. 프로그래머가 의도적으로 코드를 혼란스럽게하여 조직에 자신의 가치를 높이거나 계약 또는 외주 작업의 경우 반복적 인 비즈니스를 보장하기를 원하기 때문입니다.

내 질문은 다른 사람이 이런 코드를 본 적이 있습니까? 왜 그 코드가 있었는지에 대한 결론은 무엇입니까?

누군가 이와 같은 코드를 작성했다면 이유를 공유 할 수 있습니까?

코딩 성과를 실제보다 더 복잡하게 만들려는 개발자의 이야기를 들었습니다. 아무도 이것을 인정하는 것을들은 적이 없지만, 의도적으로 서두르지 않거나 열악한 관행으로 만들어졌으며 방해 행위가 아닌 기준에 맞는 코드를 보았습니다. 악성 코드를 둘러싼 코드는 특정 기능이 더 이상 유용하지 않은 지점으로 변경되었을 수 있습니다.

실제로이 개발자 만 복잡성을 관리 할 수 ​​있다는 결론에 도달하기 전에 누군가이 코드를 직접보아야합니다. 대부분의 관리자와 다른 비즈니스 사람들은 어떤 종류의 코드도 이해하지 못하고 입장을 다시 채우고 싶지 않기 때문에이 결론에 도달했습니다.

나는 이와 같은 코드를 보지 못했지만 다른 이유로 무의미하거나 무의미한 코드를 보았습니다.

1. 하위 호환성. 훨씬 더 좋은 방법을 찾았지만 일부 타사 모듈 이이 API / 기능을 사용하기 때문에 오래된 API / 기능을 유지해야합니다. 함수가 유용한 기능을 수행하지 않더라도 코드가 없으면 일부 코드가 손상 될 수 있습니다.

2. 방어 적 코딩. 이 코드의 검사는 다른 곳에서 이미 검사되었으므로 의미가 없습니다. 그러나 누군가가 다른 곳 에서이 코드를 변경하고 수표를 제거하거나 변경하여 더 이상 사전 조건과 일치하지 않으면 어떻게됩니까?

3. 유기적 성장. 큰 프로젝트에서 수년에 걸쳐 많은 것들이 변하고 이전에 사용 된 일부 방법은 더 이상 사용되지 않지만이 특정 방법의 사용 여부를 추적 한 사람이 아무도 없기 때문에 아무도 제거하지 않아도됩니다. 그들의 코드 조각과 우연히 그들은이 방법을 사용하기를 중단했습니다. 또는 한 번 의미가 있었지만 적용이 다른 곳에서 리팩토링되어 조건이 항상 사실 이었지만 아무도 그것을 제거하려고하지 않았습니다.

4. 과잉 설계. 사람들은 "필요한 경우에 대비하여"어떤 것을 코딩하고 실제로는 필요하지 않을 수도 있습니다. "오프라인으로 작업해야하는 경우 스레드를 생성하자"와 같이 아무도 오프라인에서 작업을 요청하지 않으며 프로그래머는이를 잊어 버리고 다른 프로젝트 (또는 다른 회사)로 이동하여 해당 코드가 남아 있습니다. 왜 그것이 존재하는지 또는 그것을 제거하는 것이 안전한지 아무도 모르기 때문에 영원히.

따라서 업무 보안에 대한 악의적이거나 잘못 안내 된 접근 방식으로 수행 된 것을 본 적이 없지만 소프트웨어 개발의 자연스러운 결과로 발생하는 경우는 수없이 많습니다.

내 질문은 다른 사람이 이런 코드를 본 적이 있습니까? 왜 그 코드가 있었는지에 대한 결론은 무엇입니까?

1) 예.

2) 내가 본 경우에는 다음과 같이 다양하게 내려 놓았습니다.

• 프로그래머 미경험
• 프로그래머가 수정하려고하는 특히 복잡하거나 잘못 실행 된 디자인을 이해하지 못함
• 프로그래머는 리 팩터 도중에 중단됩니다.
• 부주의

아마 나는 그것에 대해 자선을 받고 있을지 모르지만, 나의 일반적인 접근 방식은 손가락을 가리키고 품질이 좋지 않은 것을 취하는 것보다 이러한 것들에 대해 용서하거나 대립하지 않는 것이 낫다는 것입니다. 분명히, 일이 이루어져야 할만큼 상황이 나빠질 수 있지만, 올바른 방향으로 부드럽게 움직여도 충분합니다.

물론 품질 / 실수가 "비즈니스"에 심각한 영향을 미치는 경우에는 이러한 공정한 접근 방식을 취할 수 없습니다. 그러나 이러한 상황 에서는 포괄적 인 테스트 절차와 함께 모든 것에 대한 의무 적이고 부지런한 코드 검토 가 필요 합니다.

내 경험에 따르면 사람들은 품질이 좋지 않은 코드 (적어도 부분적으로)가 개인 표준에 위배되기 때문에 "엄격한"경향이 있습니다. (개인적으로) 완벽을 추구하는 것은 매우 좋지만, 다른 사람들에게 당신의 개인적인 표준을 투영하는 것은 다소 비합리적입니다. 사물의 소리에 의해 (예를 들어 예시의 본질에서), 이것이 당신이하는 일입니다.

IMO는 생산적이지 않으며 동료와의 좋은 협력 관계에 도움이되지 않습니다.

이러한 모든 것들은 종종 프로젝트가 어떻게 진행되는지에 대한 증상입니다.

 1. 가치가없는 메소드 또는 함수 호출. 일부 코드가 그대로 그대로 남아있는 경우가 많습니다 ( 더 이상 사용되지 않는 경고가 있지만, 대부분의 언어에는 해당 경고가 없으므로 항상 따르지는 않습니다 ...). 진정한 목적을 가지고 있으며 문제의 행을 제거하면 어떤 일이 일어날 지 아무도 모릅니다.

나는 dailywtf에서 이것을 기억하는 것 같습니다 :

@deprecated // he might have been crazy enough to use reflection...
boolean getTrue() {
    return false; 
}

 2. 중복 검사는 별도의 클래스 파일, 객체 또는 메소드에서 수행됩니다. 의사 소통의 층도 불완전합니다 (신화적인 남자의 달? 종종 한 사람이 무언가를 연구하고 프로젝트를 떠난 다음에 다음 사람이 기괴한 벌레를 찾아 여기저기서 추가 점검을하여 제거하려고합니다. 버그가 제거 될 때 검사는 문제가되지 않습니다. 문제가 해결되지 않은 경우에는 수정하지 마십시오.

 3. 항상 true로 평가되는 if 문. 아, 이거 했어요 한 번 프로젝트를 받았는데 아마도 10-15 개의 if / else 블록 이 있었을 것입니다 . 동작을 변경하기 위해 간단히 true||첫 번째 블록 에을 넣습니다 . 몇 달이 지나야 몇 년이 지나서야 다시 와서 말했습니다. "아,이 코드는 파괴 된 적이 있지만

 4. 튀어 나와 아무런주의를 기울이지 않는 스레드. 나는 다음과 같은 생각을 상상할 수 있습니다.

1. 알아! 이 두 가지 문제를 비동기 적으로 처리 할 수 ​​있습니다! 스레드 foo와 bar를 만들 것입니다.
2. (2 개월 후) 허, bar의 기능은 foo에서 조금 더 좋습니다. 좀 넘어가겠습니다.
3. (1 년 후)이 다른 것들을 foo에 넣는 것이 합리적입니다.
4. (많은, 몇 년 후) "이 bar스레드는 무언가를하고있는 것처럼 보이지 않습니다. 제거 할 수 있습니까?" "더욱, 몇 년이 지났지 만 ..."

나는 좀 더 낙관론자입니다. 코드가 부주의하게 리팩토링 될 때 자주 설명하는 것이 발생한다고 생각합니다.

옛 동료들은 컨설턴트들이 그들이 생산 한 코드 라인 수만큼을 지불했을 때를 말해주었습니다 . 그래서 그들은 놀랍도록 긴 바람의 구조를 사용하여 이익 을 극대화했습니다 .

요즘 나는 항상 그 남자가 일을하면서 언어 를 배우고 있다고 가정 합니다 . 그리고 그는 서두르고 있습니다.

대부분의 답변은 다음 두 가지 간단한 사실로 요약됩니다.
[1] 코드는 코드의 기록을 나타내며
[2] 코드는 코드의 예상 미래를 반영합니다.

CURRENT SPECIFICATION을 고려한 CURRENT APPLICATION ENVIRONMENT에서 가치가없는 기능을 작성했지만 앞으로 필요할 수 있습니다.

AT PRESENT에서 항상 true로 평가되는 if 문을 작성했습니다. 그러나 과거에는 잘못되었을 수 있습니다.

중복 검사에 관해서는 다른 코드를 믿지 않으며 내 코드를 믿지 않습니다. 모듈이 N이 1 또는 2 또는 3에 의존하는 경우 잘 확인해야하며 그렇지 않은 경우 유익하게 충돌합니다. 모듈 A가 망 쳤기 때문에 모듈 B가 폭발하는 것은 불법입니다. 모듈 B가 모듈 A가 망했다고 불평하는 것은 합법적입니다. 그리고 다음 달에 그 매개 변수는 아직 작성되지 않은 모듈 C에서 올 수 있습니다.

나는 이것을 몇 번 보았습니다. 실제로 어제 보스 코드 중 일부를 새로운 앱에 병합해야합니다. 그의 경우에는 기술과 이해의 일반적인 부족과 그가 자신이 숙련 된 개발자라고 생각한다는 믿음에 달려 있습니다.

'가치가없는 방법이나 함수 호출.' 그리고 '항상 참으로 평가되는 if 문'은 그의 코드에서 중요한 문제입니다.

많은 사람들 이 이러한 문제 가 있는 코드를 보았지만 동일한 코드를 작성 하는 데 주력하는 사람은 거의 없을 것으로 생각합니다 . 어쩌면 당신이보고있는 것은 누적 된 소프트웨어 부패입니다-누군가가 실제로 작동하지 않는 무언가를 추가하면, 다음 관리자는 체인에 보호 코드를 더 추가하여 첫 번째에서 올바르게 확인되지 않은 상태를 방지합니다 장소; 그런 다음 누군가가 문제 보고서를 받고 문제의 특정 인스턴스에 대해 더 많은 방어 기능을 추가합니다. 다른 사람은보다 일반적인 검사를 추가하고 이전에 추가 된 오래된 코드 중 일부를 제거하여 더 구체적인 증상 등을 처리하지 않습니다.

그런 다음 코드 정리 문제가 있습니다. 죽은 코드 인 것으로 보이는 것을 제거 할 특별한 동기가없고, 그렇게하지 않는 엄청난 동기 가 없습니다. 코드를 완전히 이해하지 못하면 코드가 "죽었다"는 평가로 인해 결함이 있으면 시스템이 고장날 수 있습니다.

• 가치가없는 메소드 또는 함수 호출.

반드시 나쁘지는 않습니다. 기본 클래스의 메소드는 종종 서브 클래스에 대한 대체 지점을 의미하는 빈 메소드를 호출합니다. 예 : Cocoa Touch의 UIView에는 -didAddSubview:기본 버전에서 아무것도하지 않는 것으로 문서화 된 방법이 있습니다. 서브 클래스가 무언가를 수행하기 위해 구현할 수 있기 때문에 UIView의 -addSubview:메소드는 -didAddSubview:아무것도 수행하지 않아도 호출 해야합니다. 물론 아무 것도하지 않는 방법과 그 이유를 문서화해야합니다.

비어 있거나 쓸모없는 기능 / 방법이 역사적 이유로 분명히 존재하는 경우 제외해야합니다. 확실하지 않은 경우 소스 코드 저장소에서 이전 버전의 코드를 살펴보십시오.

• 중복 검사는 별도의 클래스 파일, 객체 또는 메서드에서 수행됩니다.

문맥이 없으면 괜찮다면 말하기가 어렵습니다. 동일한 이유로 점검이 명확하게 수행 된 경우, 책임이 명확하게 분리되지 않았으며, 특히 두 점검 모두 동일한 조치가 수행 될 때 일부 리팩토링이 필요함을 의미 할 수 있습니다. 두 점검으로 인한 조치가 동일하지 않은 경우, 조건이 동일하더라도 두 가지 점검이 다른 이유로 수행되고있을 가능성이 높습니다.

• 항상 참으로 평가되는 if 문.

다음과 같은 큰 차이가 있습니다.

if (1) {
    // ...
}

과:

if (foo() == true) {
    // ...
}

어디 foo()에서 항상 반환 true됩니다.

첫 번째 경우는 사람들이 디버깅 할 때 많이 발생합니다. 그것은 사용하기 쉬운 if (0) {...(가) 변경 후 버그를 분리하려고 노력하는 동안 일시적으로 코드의 덩어리를 제거하고, 0에 1그 코드를 복원 할 수 있습니다. 는 if당신은 물론, 완료되면 제거해야하지만, 그 단계를 잊지하거나 여러 장소에서 일을 한 경우 하나 또는 두 개의를 그리워 쉽습니다. (나중에 검색 할 수있는 주석으로 이러한 조건을 식별하는 것이 좋습니다.) 유일한 해는 미래에 발생할 수있는 혼란입니다. 컴파일러가 컴파일 타임에 조건의 값을 결정할 수 있으면 완전히 제거합니다.

두 번째 경우도 가능합니다. foo()코드로 표현 된 조건을 코드의 여러 곳에서 테스트해야하는 경우, foo()항상 현재 상황이 발생 하더라도 별도의 함수 나 메소드로 분해하는 것이 올바른 방법 인 경우가 많습니다 . foo()결국 return을 생각할 수 있다면 false메소드 또는 함수에서 해당 조건을 분리하는 것이 코드가 해당 조건에 의존하는 모든 위치를 식별하는 한 가지 방법입니다. 그러나 이렇게하면 foo() == false조건이 테스트되지 않고 나중에 문제를 일으킬 수 있는 위험이 있습니다 . 해결책은 false케이스 를 명시 적으로 테스트하는 단위 테스트를 추가하는 것 입니다.

• 회전하고 아무 것도하지 않는 스레드.

이것은 역사의 인공물처럼 들리며 코드 검토 중이나 소프트웨어의 주기적 프로파일 링을 통해 식별 할 수있는 것 같습니다. 의도적으로 만들 수 있다고 생각 하지만 누군가가 실제로 의도적으로 그렇게 할 것이라고 상상하기가 어렵습니다.

일어난다. 실제로 자주.

때때로 이러한 코딩 막 다른 골목은 더 효율적인 / 현대 / 고속 고속도로가 그들 주위에 설치 될 때 쇠약해진 오래된 염소 전차와 비슷합니다.

다른 경우 (그리고 아마도 유죄 일 수도 있음), 브리핑을 받았지만 확인되지 않은 일련의 기능 / 요청이있을 때 소프트웨어 확장을위한 기초입니다. (때때로 "볼트 온 (bolt-on)"할 계획 인 이후 작업을 위해 핸들을 제공하는 초기 빌드에서 약간의 작업을 수행하면 인생이 더 쉬워 질 때, 더 힘들거나 어려워 질 수 있습니다. eventuate.)

그리고 그것의 많은 부분은 오래된 "왜냐면 깨지지 않으면 맞지 않는 것"때문입니다. 때로는 이해하지 못하거나 사용하지 않는다고 생각되는 코드를 찢어 버리면 프로그래밍 버전의 "나비 효과"가 발생할 수 있습니다. 한두 번 그런 일이 있었어.

때로는 전역 부울을 true로 설정하고 나중에 내 코드에서 if (bool)를 설정 한 다음 런타임 동안 if 문에서 중단 점을 설정하고 부울을 전환하여 무언가를 테스트 할 수 있습니다.

나는 if true무의식적으로 "무의미한 코드"로 분류되는 진술에 반대한다 .

if (1) { ... }C 코드에서 블록 을 사용하는 것이 합법적 인 경우가 있는데, 변수 정의가 함수의 시작 부분이되어야한다고 주장한 C 표준과 호환되거나 로컬 변수가 가능한 한 로컬로 정의되기를 원합니다.

switch (i) {
    case 23:
        if (1) {
            /* I can declare a local var here! */
        }
        break;
}

내 교수는 언젠가 이전 고용주가 그들이 완료 한 줄 수에 따라 돈을 지불한다는 이야기를 우리에게 이야기했다. 그래서 그들은 결코 호출되지 않은 수십 줄의 함수를 썼습니다. 무의미한 코드를 작성해야하는 좋은 이유 인 것 같습니다.

@Andy가 언급했듯이, 내가 본 큰 구성 요소는 YAGNI를 깨뜨리고 있습니다.

누군가는 많은 요소가 필요한 것 대신에 모든 요소가 무엇인지에 대한 가정부터 시작 합니다 . 이는 "a" 와 "a" 관계 의 혼동입니다 .

이러한 혼동으로 인해 상속 구조가 엄격 해지며 실제로 호출되지 않기 때문에 구현되지 않은 상태로 유지되는 방법이며, 부분을 조정할 필요가있는 반복 된 논리와 일반적으로 비즈니스 모델에 맞지 않는 이상한 워크 플로입니다.

다른 많은 사람들과 마찬가지로, 나는 이것이 악의적으로 수행되는 것을 보지 못했지만 좋은 디자인에 대한 지식이 부족하고 다른 사람들에게 그렇게 보이도록하려는 시도는 없었습니다. 웃긴 것은 최소한 코드가 지나치게 설계 한 광고 naseum이 아니기 때문에 개발자가 지식이 부족한 것 같습니다. ( 키스 원리 )