다음 시나리오를 상상해보십시오.

귀하의 (또는 다른 사람의) 프로그램에 버그가 있음을 발견했습니다. 특정 입력이 주어지면 함수가 잘못된 결과를 생성합니다. 코드를 검사하고 잘못된 것을 찾을 수 없습니다.이 입력이 주어지면 멍청한 것처럼 보입니다.

이제 두 가지 중 하나를 수행 할 수 있습니다. 실제 원인을 찾을 때까지 코드를 추가로 검사합니다. 또는 if입력이이 특정 입력인지 확인 하는 명령문 을 추가하여 붕대를 때리거나 예상 값을 리턴합니다.

나에게 붕대를 적용하는 것은 완전히 받아 들일 수 없습니다. 이 입력에서 코드가 예기치 않게 작동하는 경우 놓친 다른 입력은 이상하게 반응합니까? 그것은 단지 수정처럼 보이지 않습니다-당신은 깔개 아래에서 문제를 삽질하고 있습니다.

이 작업을 고려하지 않더라도 교수와 서적에서 "붕대"수정을 적용하는 것이 좋은 생각이 아니라는 점에 대해 얼마나 자주 상기시키는 지에 놀랐습니다. 그래서 이런 궁금증이 생겼습니다. 이런 종류의 "수정"이 얼마나 흔한가요?

시간 / 마감일 압력이 한 가지 이유입니다.

당신이 촉박 한 마감일을 맞이하고 상사가 목을 숨 쉬게했을 경우 (아마 말 그대로!), 이렇게하고 "나중에 다시 와서 고칠 게요"라고 생각하는 것은 매우 유혹적이며 당신 만이 할 수있는 유일한 것입니다 할수있다.

물론 어제 수정해야 할 새로운 문제가 있기 때문에 실제로 돌아가서 제대로 수정하는 횟수는 매우 적습니다.

프로그래머가 인정하지 않는 한, 아름답게 코딩 된 소프트웨어가 항상 회사 나 고객에게 더 많은 가치를 부여하는 것은 아닙니다. 예를 들어 소프트웨어가 사람들의 신용 카드를 두 번 충전하는 등의 재난 상황에서 이것은 사실입니다. 때로는 붕대처럼 필요한 수단으로 출혈을 멈추고 환자가 안정 된 후 회복하고 실제로 핵심 문제를 해결해야합니다.

트릭은 일단 긴급 성이 사라지면 붕대를 진정한 수정으로 우선 순위를 정하도록 누군가를 설득시키는 것이 실제로 어렵다는 것입니다. 특히 첫 번째 문제 뒤에는 또 다른 긴급한 문제가 항상 기다리고 있다는 점을 고려하십시오. 빠른 수정을 넘어서 문제를 해결하는 데주의를 기울여야합니다.

시각

내 의견으로는 1 위입니다. 문제가 코드베이스 인 경우 문제를 조사하는 데 더 많은 시간이 걸릴 수 있습니다. 종종 "붕대"수정에는 CSS 또는 UI 조정이 포함됩니다. 나는 그것들을 빨리 처리하기 위해 매우 불쾌한 인라인 CSS와 JavaScript를 작성했습니다. 돌아가서 수정하는 것은 시간이 있으면 항상 옵션입니다.

우리는 예외적으로 그렇게합니다.

개발 중 수정 사항의 경우, 근본 원인을 모르고 수정 사항이 수행되지 않도록합니다. 하나:

• 근본 원인에 대한 검색이 너무 오래 걸리거나 실속되기 시작하고 마감 기한이 매우 길고,
• 근본 원인을 해결하기위한 예외적 인 코드 변경은 전술적으로 실현 가능하지 않습니다 (변경이 너무 오래 걸리고 마감일이 다가옵니다)

이 경우 "붕대"수정을 선택합니다. 그런 다음 근본 원인을 해결하기 위해 내부 결함을 엽니 다. 그렇습니다. 이러한 내부 결함은 매우 낮은 우선 순위로 처리되는 경우가 더 많습니다.

유지 보수 스트림의 수정 사항에 대해서는 근본 원인을 모른 채 수정하지 않아야합니다. 하나:

• 매우 예외적으로 근본 원인 검색이 중단됩니다.
• 예외적으로 근본 원인을 수정하는 것이 전술적으로 실현 가능하지 않은 경우가 발생할 수 있습니다 (변경은 사소한 것이 아니며 고객은 어제 수정이 필요했습니다).

이러한 경우 먼저 "붕대"임시 수정을 선택하고 고객이 만족하면 적절한 수정 작업을 수행 한 후에 만 ​​결함을 해결합니다.

명확성.

• 특정 버그가 주어지면 특정 수정이 "붕대"인지 객관적으로 정의하는 데 상당한 어려움이 있습니다. "올바른 해결책"이 다른 사람의 "붕대"일 수 있기 때문입니다.
• 그래서 나는 다음과 같은 정의를 사용한다. 내가 전문적으로하고자하는 것보다 덜 우아하고 잘 연구되지 않은 방식으로 결함을 고치기 위해.

먼저 "붕대"수정 빈도 에 대해 :

• 새로운 코드 : 거의 없음.
• 오래된 코드 :
  • 그것들은 보통 붕대처럼 보이지 않고 모든 코드 검토에서 살아남을 정도로 우아하게 작성되었지만 (아래의 "데이터 중심 완화"참조) 일부를 찾을 수 있습니다 .
  • "보이지 않는 붕대"에도주의를 기울이십시오. 단순히 해당 기능을 호출하지 마십시오. 코드가 부족하면 버그가 존재한다는 힌트도 없습니다.
• 많은 외부 의존성을 가진 오래된 코드 :
  • 거의 가득합니다.
  • 거의 항상 사용되지 않는 버전의 종속성으로 작성되었으며, 새 버전으로 종속성을 업데이트하기 전에는 종속성의 "릴리스 정보"를 읽지 않습니다.

둘째, 나의 충고 :

개발 팀 자체 소스 코드에서 버그가 발생하는 경우 :

• 전문적인 방법으로 수정하십시오. (수정하면 소유하고 있습니다.)
• 시간이 지나면 최대한 최선을 다하십시오.
  • 수정 사항을 수락할지 여부를 결정하려면 최종 사용자 : 버그 자체 및 제안 된 수정 프로그램에 미치는 잠재적 영향을 살펴보십시오.
  • 소스 코드 관리 도구의 히스토리 정보를 사용하여 관련 코드 스 니펫을 연구하고 문제점과 솔루션을 잘 이해할 때까지 동료와 논의하십시오 (그러나 시간을 너무 많이 차지하지는 않음).
• 결함 추적 시스템으로 항상 버그를 추적하십시오 .

다른 팀의 소스 코드에서 버그가 발생하는 경우 :

• 팀을 밀어 버그를 수정하십시오.
• 항상 다른 팀의 결함 추적 시스템에 해당 버그를 제출하십시오 .

다른 회사 (또는 회사의 제품이 아님) 제품에서 버그가 발생하는 경우 :

• 이 경우 덕트 테이프 수정 (또는 데이터 기반 대안 )이 버그를 수정하는 유일한 방법 일 수 있습니다.
• 그것이 오픈 소스라면, 누군가 버그를 조사 할 수 있도록 버그를 (아마도 공개 된) 결함 추적 시스템으로 제출 하십시오.

내가 생각하는 코드베이스의 나이에 많이 달려 있습니다. 오래된 코드에서는 20 세의 COBOL 루틴이 재미 없다는 것을 다시 쓰는 것이 매우 일반적이라고 생각합니다. 프로덕션에있는 약간 새로운 코드라도 여전히 일반적입니다.

나는 그것이 매우 일반적이라고 말할 것입니다.

Joel Spolsky의 블로그 게시물 : 덕트 테이프 프로그래머 확인

나는 지금까지 진행했던 거의 모든 프로젝트에 마감일을 맞추고 작업을 완료하기 위해 일종의 붕대 또는 덕트 테이프를 적용해야한다고 쉽게 말할 수 있습니다 . 예쁘지는 않지만 깨끗하지는 않지만 업무를 계속 수행하여 비즈니스를 계속 실행할 수 있으며 프로젝트는 어떤 방식 으로든 발전 할 수 있습니다.

학계와 소프트웨어가 실제로 시간과 비즈니스 제약 조건 하에서 배송되어야하는 실제 세계에는 차이가 있습니다.

어떤 식 으로든 나중에 희망을 가질 때까지 수정을 연기하기 위해 깔개 아래에 놓는 것입니다. 안타깝게도 지연된 픽스는 절대 발생하지 않으며이 코드는 프로덕션 환경으로 전환됩니다.

더 많은 컨텍스트가 없으면 말하기가 어렵습니다-귀하의 예에서 if 문을 추가하는 것이 왜 올바른 수정이 아닌가? 어딘가에 그 입력을 처리해야 할 다른 코드 블록이 있기 때문입니까?

붕대 수정 프로그램 사용 빈도는 코드가 얼마나 복잡한 지, 코드에 가장 익숙한 사람이 있는지 여부 (Craig의 20 세 COBOL 루틴을 담당 한 사람이 몇 년 전에 회사를 떠났을 수 있음)와 같은 여러 가지 사항에 따라 다릅니다. ) 및 관련된 시간 척도.

마감 시한이 당신을 쳐다보고 있으면 근본 원인을 고치기보다는 석고를 때리는 경우에도 더 안전한 수정을 위해 때때로 통통하게 될 것입니다. 상황을 악화시키지 않는 한 괜찮습니다. 그러나 여전히 정확하지 않고 올바르게 수정해야한다는 사실을 추적하는 것이 중요합니다.

그러한 종류의 수정이 실제로는 좋고 아마도 이상적입니다 (디버그하는 데 걸리는 시간이 관련된 경우).

주 실행 파일을위한 일종의 모듈로 작동하지만 주 실행 파일의 일부 정보를 실행해야하는 20 개의 DLL이있는 시나리오를 상상해보십시오.

주 실행 파일 외부에서 해당 DLL을 사용하려면 주 실행 파일에서 일부 반환 값을 제거해야합니다. A.)이 컨텍스트에는 존재하지 않으며 B.)이 컨텍스트에는 존재하지 않기를 원합니다.

즉, 결과를 정리할 때와 실제 결과를 얻을 때 완전히 다른 코드를 실행하도록 컴파일러 지시문을 코드에 배치하는 것이 좋습니다.

if다른 사람의 함수 안에 넣는 대신 함수 {$ifdef}주위에 놓았습니다. 그러면 아무도 거기에 있어야하는 것과 혼동하지 않습니다.