내 경험에 따르면 패턴은 다음과 같습니다.

• 종종 몇 년 동안 시스템 작동
• 오류가보고되었습니다
• 개발자는 오류를 조사하고 완전히 결함이있는 것처럼 보이는 코드를 찾아서 “작동하지 않았을 것”이라고 선언합니다.
• 버그가 수정되고 작동하지 않았지만 수년 동안 할 수 없었던 코드의 전설이 커짐

여기서 논리적으로합시다. 결코 작동 할 수 없었던 코드 … 결코 작동하지 않았을 수 있습니다 . 그것이 효과 가 있었다면 진술은 거짓입니다.

따라서 설명 된 것과 같은 버그 (결함이있는 코드가 작동을 멈추는 것을 관찰하는 것)는 특허 적으로 의미가 없다고 말할 것입니다 .

실제로 일어난 일은 다음 두 가지 중 하나입니다.

1) 개발자는 코드를 완전히 이해하지 못했습니다 . 이 경우 코드는 일반적으로 엉망이며 코드의 어딘가에 외부 조건에 대한 중요하지만 분명하지 않은 감도가 있습니다 (일부 기능은 작지만 중요한 방식으로 작동하는 특정 OS 버전 또는 구성). 이 외부 조건은 변경되어 (예 : 서버 업그레이드 또는 관련이없는 것으로 변경됨) 코드가 손상됩니다.

그런 다음 개발자는 코드를 살펴보고 기록 컨텍스트를 이해하지 못하거나 가능한 모든 종속성 및 시나리오를 추적 할 시간이 없어서 코드가 작동하지 않고 다시 작성할 수 없다고 선언했습니다.

이 상황에서 여기서 이해해야 할 것은 “한 번도 할 수 없었습니다”라는 생각이 틀렸다는 것입니다.

그것은 다시 쓰는 것이 나쁜 일이라고 말하는 것은 아닙니다. 종종 잘못된 일이 무엇인지 정확히 아는 것이 좋지만 시간이 많이 걸리고 코드 섹션을 다시 쓰는 것이 더 빠르며 문제가 해결되었는지 확인할 수 있습니다.

2) 실제로는 작동하지 않았으며 아무도 눈치 채지 못했습니다 . 이것은 특히 대규모 시스템에서 놀랍게도 일반적입니다. 이 경우 새로운 누군가가 이전에 아무도하지 않은 방식으로 일을 시작하거나 비즈니스 프로세스가 변경되어 이전에 사소한 우연한 사례를 주요 프로세스로 가져 왔으며 실제로는 전혀 작동하지 않았거나 전혀 작동하지 않은 일부 시간)을 찾아보고합니다.

개발자는이를보고 “작동 한 적이 없었습니다”라고 선언하지만 사용자는 “넌센스, 우리는 몇 년 동안 사용해 왔습니다”라고 말하지만 옳은 것이지만 관련이없는 것으로 간주합니다 (일반적으로 개발자들은 “아, 네, 우리가해야합니까 가고있는 시점에서 정확한 상태를 발견 한 것을 지금 전에하지 않았다”변경되었습니다).

여기서 개발자는 옳습니다. 결코 작동하지 않았으며 작동하지 않았습니다.

그러나 어느 경우 든 두 가지 중 하나가 사실입니다.

• “그것은 결코 일할 수 없었습니다”라는 주장은 사실이며 결코 효과가 없었습니다.
• 그것은 효과가 있었고 “그것은 결코 일할 수 없었습니다”라는 진술은 거짓이며 코드와 그 의존성에 대한 이해가 부족합니다 (보통 합리적인)

답변

Function CalculateMonthlyInterest([...], IsYearlyInterestMode As Boolean, [...]) As Double
    [about 30 lines of code]
    If IsYearlyInterestMode Then
        [about 30 lines of code]
        If Not IsYearlyInterestMode Then
            [about 30 lines of code (*)]
        End If
    End If
End Function

int pipeFDs[1];

int pipeResult = pipe(pipeFDs);