버그를 수정하거나 고객이 찾을 때까지 기다 립니까?


35

다른 사람들이 버그를 보았을 때 문제를 해결합니까, 아니면 수정하기 전에 충돌 / 데이터 손실 / 사람이 죽을 때까지 기다 립니까?

실시 예 1

 Customer customer = null;
 ...
 customer.Save();

이 코드는 분명히 잘못되었으며 그 주위에 방법이 없습니다-null 참조에서 메소드를 호출합니다. Save인스턴스 데이터에 액세스하지 않기 때문에 충돌이 발생하지 않습니다 . 정적 함수를 호출하는 것과 같습니다. 그러나 아무 데나 작은 변화가 있으면 갑자기 코드가 깨져서 충돌하지 않습니다.

그러나 코드를 수정하는 것도 생각할 수 없습니다 .

Customer customer = null;
...
customer = new Customer();
try
   ...
   customer.Save();
   ...
finally
   customer.Free();
end;

소개 충돌; 하나는 완전한 적용 범위를 가진 단위 테스트와 수동 사용자 테스트를 통해 발견되지 않았습니다.

실시 예 2

float speed = 0.5 * ((G * mass1 * mass2) / R) * Pow(time, 2);

물리학을 아는 사람들은 그것이 분모에서 R 2 이어야한다는 것을 인식 할 것 입니다.

코드가 잘못되었습니다. 절대적으로 잘못되었습니다. 그리고 속도를 과대 평가하면 레트로 로켓이 너무 빨리 발사되어 우주선의 모든 탑승자를 죽일 수 있습니다.

그러나 속도를 과대 평가하여 다른 문제를 숨기고있을 가능성도 있습니다. 셔틀이 너무 빨리 움직이는 동안 에어백을 배치 할 수 없습니다. 코드를 갑자기 수정하면 :

float speed = 0.5 * ((G * mass1 * mass2) / Pow(R, 2)) * Pow(time, 2);

이제 속도가 정확하고 갑자기 에어백이 전개되어서는 안됩니다.

실시 예 3

다음은 최근에 문자열에 유효하지 않은 문자가 포함되어 있는지 확인한 예입니다.

if (StrPos(Address, "PO BOX") >= 0)
{
   //Do something
}

Do something지점에 버그가 있다고 판명되면 어떻게해야 합니까? 명백히 잘못된 코드 수정 :

if (StrPos("PO BOX", Address) >= 0)
{
   //Do something
}

코드를 수정하지만 버그가 발생합니다.


내가 보는 방식에는 두 가지 가능성이 있습니다.

  • 코드를 수정하고 그것을 깨뜨린 것에 대한 비난을 받는다
  • 코드가 충돌하기를 기다렸다가 버그가 있다고 비난받습니다.

무엇을 당신은 정치적으로합니까?


예 4-오늘날의 실제 버그

객체를 생성하고 있지만 잘못된 생성자를 호출합니다.

Customer customer = new Customer();

"매개 변수없는"생성자는 상속 체인에서 다시 매개 변수화 된 생성자임이 밝혀졌습니다.

public Customer(SomeObjectThatNobodyShouldBeUsingDirectly thingy = null)
public Customer(InjectedDependancy depends)

그것을 호출하는 것은 실수입니다. 왜냐하면 모든 후속 생성자를 무시하기 때문입니다.

위험한 생성자를 노출시키지 않도록 객체의 계보를 변경할 수 있지만 이제 코드를 다음과 같이 변경해야합니다.

Customer customer = new Customer(depends);

그러나 나는이 변화가 아무것도 깨지지 않을 것이라고 보장 할 수 없습니다. 위의 예제 1 과 마찬가지로 어딘가에 어떤 난해한 조건 하에서 누군가 Customer가 유효하지 않고 정크로 가득 차도록 구성 되어 있습니다.

아마도 Customer객체가 올바르게 구성되었으므로 이전에는 없었던 코드를 실행할 수 있으며 충돌이 발생할 수 있습니다.

부인의 인생은 그럴 수 없어

그리고 여기에서 화요일까지 시험해 볼 수 있습니다. 나는 회귀를 소개하지 않은 딸의 삶을 맹세 할 수 없습니다.

나는 :

  • 코드를 수정하고 그것을 깨뜨린 것에 대해 비난 받습니까? 또는
  • 버그를 남겨두고 고객이 발견하면 비난을 받습니까?

33
무언가를 망가뜨릴 수 있기 때문에 어떤 것도 바꾸고 싶지 않다면 코드의 다른 부분에서 일어날 수있는 일을 살펴볼 자격이 없다고 생각한다면 여기서 무엇을하고 있습니까? 작성하려는 코드 줄이 잘못되어 키보드가 마비 되었습니까?
David Thornley

3
확실히 잘 연구 된 질문
Muhammad Alkarouri

2
"Do Something"은 종종 여러분이 작성한 다른 함수 나 라이브러리에서 함수를 호출하는 것입니다. 절차 자체도 단위 테스트를 통해 매우 낮은 버그를 고칠 때 새로운 버그가 발생할 가능성을 남겨두고 있습니다. 다리를 만들면 다리를 걷는 사람들이 죽지 않도록 작은 규모로 먼저 테스트합니다. . 버그가 걱정 될 때 단위 테스트를 수행하지 않으면 잘못 수행 한 것입니다. 어쨌든 그것을 고치는 것은 당신을 비난하기 때문에 고치는 대신 그것을 막을 수 있고 전혀 비난받을 수 없습니다.
Tamara Wijsman

2
‘사람이 죽기 전까지 기다렸다가 고쳐라’! 이런 암소, 나는 이것에 대한 답이 하나만 있기를 진심으로 바랍니다.
Chris Knight

3
당신이 한 말에 대해 구체적으로 언급하자면, 당신은 코드의 다른 부분을 알지 못하는 경우, 난해한 행동에 의존합니다. 누군가 코드에서 핵으로 명확하게 잘못된 범위 지정 규칙을 남용하는 경우 코드가 잘못되었습니다. 좋은 OOP는 그 버그를 막았지만, 나쁜 습관을 사용했기 때문에 고치지 않으면 문제가 더 복잡 해져서 더 남용을 위해 열어두고 시스템을 더욱 불안정하게 만듭니다. 버그 수정, 테스트에서 문제가 발견되기를 바랍니다. 그렇지 않은 경우 더 많은 버그를 수정하십시오. 제품의 장기적인 안정성은 중요한 지표입니다.
CodexArcanum

답변:


34

상황, 버그, 고객 및 회사에 따라 크게 다릅니다. 구현을 수정하는 것과 잠재적으로 새로운 버그를 도입하는 것 사이에는 항상 고려해야 할 상충 관계가 있습니다.

무엇을해야할지 결정하기위한 일반적인 지침을 제공한다면 다음과 같이 될 것입니다.

  1. 선택한 추적 시스템에 결함을 기록하십시오. 필요한 경우 관리 / 동료와상의하십시오.
  2. 잠재적으로 심각한 결과를 초래할 수있는 결함 (예 : 예 # 2) 인 경우, 권한을 가진 사람이 통지를받을 때까지 달리고 비명을 지르고 위아래로 이동하여 버그 수정과 관련된 위험을 완화 할 적절한 조치를 결정하십시오. 이로 인해 출시일이 뒤로 밀리고 생명을 구하고 창문을 씻을 수 있습니다.
  3. 중단되지 않는 결함이거나 해결 방법이있는 경우 수정의 위험이 수정의 이점보다 큰지 평가하십시오. 어떤 상황에서는 고객이 제품을 가져 오기를 기다리는 것이 좋습니다. 그 이유는 100 % 필요하지 않을 때 물건을 수정 / 재검사하는 데 시간을 소비하지 않기 때문입니다.

이 점은 릴리스에 가까울 때만 적용됩니다. 전체 개발 모드 인 경우 결함을 추적하여 추적하고 수정 한 후 완료 할 수 있습니다. 수정하고 확인하는 데 30 분 이상 걸리는 것이 있다면 관리자 / 팀장에게 가서 결함을 현재 릴리스주기에 맞추거나 나중에 예약해야하는지 확인합니다.


매우 사실입니다. 그렇기 때문에 (일부) 회사에는 기술 관리자, 버그 크롤링 등이 있습니다. 나는 주도권을 갖지 말라고 말하는 것이 아니라 전혀 판단하지 말아야합니다. 잘못된시기에 잘못된 계획을 취하는 것을 "느슨한 대포"라고하며 회사를 죽일 수 있습니다. 또한 특정 버그의 중요성은 회사마다 다릅니다. 일부 프로그램의 경우 대화 상자의 오타는 향후 릴리스에서 수정 될 우선 순위가 낮은 미용 버그이며 다른 프로그램에서는 정지 선박 긴급 상황입니다.
밥 머피

6
결함을 로그하려면 +1 다른 결함이 우선시 될 수 있습니다 ...
SHug

35

고객은 항상 버그를 찾습니다 . 고객의 숨어있는 버그는 없습니다. 결국 당신이 소개하는 버그는 항상 당신에게 돌아올 것입니다. 그것들을 고치지 않는 것은 단순히 나쁜 전문 관행입니다. 전문가들은 이것을하지 않습니다.

고객이 버그를 발견하면 개별 개발자가 아닌 회사가 나빠 보입니다. 이것은 회사에게는 훨씬 나쁘므로 변경해야 할 경우가 있습니다. 다른 버그를 도입 할까봐이 변경에 대해 확신이 없다면 상급 개발자, 프로젝트 기술 책임자 또는 그러한 변경에 대한 결정을 내리고 그 결과를 처리 할 수있는 다른 사람에게 문의하십시오.


2
슬픈 사실입니다. 우리는 미친 것처럼 테스트 한 프로젝트를 제공해야했지만 여전히 고객은 3 분 안에 프로젝트를 중단 할 수있었습니다.
Oliver Weiler

4
@Helper Method : 아마도 당신이 제정신 사람들처럼 테스트했다면 더 좋았을 것입니다.
Vinko Vrsalovic

@Helper Method : 좀 더 심각하게 말하면 실제로 3 분이면 테스터가 고객이 기대하는 실제 사용 사례를 모르는 것처럼 보입니다.
Vinko Vrsalovic

8
@Helper 메소드 : 테스트에 고객을 참여 시키십시오 (가정 고객 == 클라이언트). 코드를 작성하고 테스트하는 개발자는 소프트웨어를 같은 방식으로 사용하지 않는 것이 문제입니다. 개발자는 온화합니다. 그것은 그들의 작품입니다. 그들의 예술 : 고객들은 파니 오에서 원숭이처럼 쾅쾅칩니다. 가능하면 테스트 노력을 공유하여 책임을 공유하십시오. 이것은 모든 환경에 맞지는 않지만, 팀이 아닌 고객과 함께 일하는 것은 조언자가 아니라 더 나은 소프트웨어를 가져올 수 있습니다.
brian chandley

어, 더 나빠? (filler)
Hello71

24

버그 수정

우리는 전문가입니다. 코드에서 충돌 또는 잘못된 동작을 유발하는 실패한 경로를 찾으면이를 수정해야합니다. 팀의 절차에 따라 결함을 제출하고 회귀 테스트를 작성하고 선박주기의 올바른 시간에 수정 사항을 확인해야 할 수 있습니다. 우선 순위가 낮은 버그 인 경우 이정표 시작 부분 근처의 수정 사항을 확인하는 것이 좋은시기입니다. 회귀를 일으키는 경우 이정표의 릴리스주기에 영향을 미치지 않기 때문입니다.

성능 버그와 관련이없는 리팩토링 또는 성능 향상과 혼동하지 마십시오.

'작은 버그 수정'의 별도 저장소를 보관하고 마일스톤의 시작 부분에서 쉽게 병합 할 수있는 분산 소스 제어 시스템이 여기에 큰 도움이됩니다.


4
+1. 고치세요 수정 사항이 다른 항목을 중단 한 경우 다른 항목이 손상된 경우에도 수정하십시오. 테스트에서 이러한 중단이 발견되지 않으면 테스트가 중단 된 것입니다. 수정하십시오. 당신은 할 수없는 자신이 무언가를 파괴의 공포하여 코드를 변경 떨어져 무서워하자 - 만 완전한 파멸에 도로 리드.
Tom Anderson

21

고객은 무엇을 말합니까?

여기에 이것이 어떻게 나오는지 상상해보십시오.

고객 : x를 수행 할 때 충돌이 발생합니다.

프로그래머 : 오 예! 나는 그것을 다시 본 것을 기억합니다. 나는 그것이 큰 문제가 아니라고 생각했기 때문에 거기에 두었습니다.

고객 : [무딘 대상에 도달]

예. 버그를 수정하십시오. 당신은 악화되는 경험에서 고객을 구하고 비상 사태가되기 전에 고객을 고칠 수 있습니다.

수정 프로그램이 실제로 충돌을 일으킬 수 있다고 생각되면 아직 수정 프로그램을 찾지 못한 것입니다.


8

당신이 준 모든 예제에는 공통 스레드가있는 것 같습니다. 완전히 이해하지 못하는 버그를 수정하고 싶은 것 같습니다. 나는 당신이 각각에 의도하지 않은 결과의 가능성에 주목하기 때문에 말합니다.

나는 아마도 큰 실수라고 말하고 Ben Laurie가 쓴 것처럼 당신이 이해하지 못하는 버그를 수정하지는 않습니다 . 이 유명한 예에서 데비안 팀은 분석 도구의 결과를 따랐을 때 데비안 및 데비안과 같은 파생물에 대한 OpenSSL의 암호화를 해제했습니다.

코드를보고 결함이 있다고 생각되면 고객이 볼 수있는 방식으로 결함을 재현 할 수 있는지 확인하십시오. 당신이 왜 다른 것을 고치기 위해 자원을 소비하지 않는 경우.


7

기술 부채를 최대한 빨리 깎아 내십시오 .

귀하의 예는 분명히 기술 코드 가 많은 레거시 코드 처럼 보이고 변경에 대한 두려움이 있음을 느낍니다 (BTW, 이것은 비판이나 판단이 아닙니다). 팀 전체가이 기술 부채가 있다는 것을 인정해야하며 (그러므로 귀하는 스스로 책임을지지 않습니다), 어떻게 처리 할 것인지 결정할 수 있습니다.

예 1에서 Save()인스턴스 데이터에 액세스하지 않으면 정확히 어떤 고객 데이터를 저장합니까? 그것을 고치고 시험을 시작하십시오.

예제 2에서는 속도 계산기를 테스트로 쉽게 다루고 모든 주요 예제에서 결과를 올바르게 계산할 수 있습니다.

예제 3에서는 데드 코드를 다시 작동시킬 위험이 있습니다. 그 코드를 모두 제거해야합니까? 그 경우 부울 조건의 의도는 무엇입니까? 문자열에 유효하지 않은 문자가 포함되어 있지 않은가? 또는 "PO BOX"가 포함되어 있는지 확인하십시오. 그러한 질문을 빨리 시작할수록 좋습니다.

이러한 여러 가지 문제를 해결 한 후에는 팀과 회고 적 / 사후 부류를해야합니다. 향후 결함 주입 속도를 줄일 수 있도록 경험을 통해 배우는 것이 중요합니다.


5

이미 좋은 답변이 있습니다. 나는 무언가가 충돌하는 것을 두려워하는 문제에 대해 뭔가를 추가 할 것입니다.

첫째, 이상적인 상황에서 소프트웨어는 모듈 식이며 올바르게 설계되었으며 우려가 잘 분리되어 있습니다. 이 경우 모든 관련 코드를 제어 할 수 있으므로 변경 사항이 적용되지 않을 가능성이 크며 숨겨진 놀라움은 없습니다.

불행히도 이상적인 상황은 허구입니다. 커플 링이 느슨해지는 정도에 관계없이 커플 링이 발생하여 다른 무언가가 파손될 가능성이 있습니다.

이에 대한 해결책은 두 가지입니다.

  1. 코드를 가능한 한 체계적으로 만드십시오.
  2. 코드가 분리되어 다른 것이 끊어지지 않는다는 것을 알면 수정하십시오.

코드를 체계적으로 만드는 것은 전체 코드를 새로운 아키텍처 디자인으로 다시 작성하는 것이 아닙니다 . 오히려 테스트에 의해 안내되는 리팩토링 이 당신의 친구입니다. 이 단계에서는 기능을 변경하지 않습니다.

두 번째 단계는 버그를 수정하는 것입니다.

몇 가지 사항이 관련됩니다.

  1. 이 프로세스에는 버전 관리 가 절대적으로 필요합니다.
  2. 리팩토링 단계와 버그 수정 단계는 별도의 커밋으로 버전 제어에 더 잘 헌신하므로 각각 잘 정의 된 히스토리 기능이 있습니다.
  3. 다른 버그를 만들 가능성을 고치지 마십시오. 아무것도하지 않습니다. 오히려 코드를 개선하는 것을 생각하십시오. 다시 말해, 버그를 줄이지 않고 늘리는 것을 알지 못한다면 그렇게해야합니다.
  4. 마지막 요점과 관련 : 미래를 예측하려고하지 마십시오. 인간은 예측에 매우 능숙하다고 생각하도록 편향되어 있습니다. 실제로 우리의 예측력은 단기적입니다. 막연한 정의되지 않은 미래 버그에 대해 걱정하지 마십시오. 이것도 YAGNI 의 기본 원리 입니다.
  5. 버그 세계에서 버전 관리에 해당하는 도구는 버그 추적기 입니다. 그것도 필요합니다.
  6. 다음 두 가지 이유로 버그를 수정해야합니다. 고객을 만족시키기 위해; 개발을 진행할 수 있습니다. 예제 3 (물리적 것)을 사용하려면 : 프로그램이 이러한 깨진 방정식으로 고객을 만족시키는 경우이 버그를 완화하기 위해 잘못 개발 된 소프트웨어의 다른 부분 (예 : 에어백 배포)이 있습니다. 이 소프트웨어에 버전 2 (또는 1.1)가 필요한 경우이 결함이있는 코드를 기반으로 올바른 코드를 개발하는 것이 점점 더 어려워 질 것입니다. 그런 다음 큰 재 작성 또는 중대한 실패로 향하고 있습니다. 둘 다 피해야합니다.

이것들은 이미 몇 점 이상이므로 여기서 멈출 것입니다.


3

먼저 버그의 정의를 고려해야합니다.

  1. 읽은 코드가 올바른 것으로 인식되지 않습니다
  2. 소프트웨어가 작업을 제대로 수행하지 못합니다

# 1에 집중하고있는 것으로 보입니다. 여기서 # 2는 앉기 가장 좋은 장소입니다. 물론 프로그래머는 코드가 옳아 지기를 원하지만 (# 1) 사람들은 코드가 작동하도록 비용을 지불 합니다 (# 2).

실수로 새로운 버그를 유발할 수있는 코드베이스에서 할 수 있거나하지 않는 것은 현재 소프트웨어에 대한 # 2의 관점과 관련이 없습니다. 그러나 # 1은 본인이나 다음에 오는 유지 보수 프로그래머에게 중요합니다. 때로는 결정하기가 어렵지만 # 2와 # 1이 충돌 할 때 # 2가 더 중요하다는 것을 알아야합니다.


2

둘 다. 세 번째 방법이 있습니다. "문제가있는 코드"가 실제로 비즈니스 관점에서 문제를 일으키고 있음을 증명하는 방법을 찾으십시오. BA / QA 또는 최소한 관리자에게 찾은 내용을 확인하십시오. 그런 다음 모든 사람이 문제를 알고있을 때 수정 사항을 계획하십시오.

언급 한 경우 유효한 버그 이외의 가능한 시나리오가 더 있습니다.

  1. 당신이보고있는 코드는 죽은 코드입니다. 아마도 ysolik이 말한 것처럼 고객이 항상 버그를 찾습니다. 그렇지 않은 경우 코드가 실행되지 않을 수 있습니다.
  2. 명백한 오류가 목적을 가진 WTF 상황이있었습니다. (우리는 생산 코드에 대해 이야기하고 있습니다.
  3. 비즈니스 / 고객은 이미이 문제에 대해 알고 있었지만 해결해야 할 필요는 없습니다.
  4. 어쩌면 더...

위의 경우에 내가 관리자 인 경우 개발자가 자신의 판단을 사용하여 "오류"를 수정하기를 원하지 않습니다. 오류를 제자리에 수정하면 대부분 도움이 될 수 있지만 잘못되면 좋은 의도보다 더 많은 문제가 발생할 수 있습니다.


1
자신의 판단을 사용하지 않는 개발자 만 고용하고 싶다면 거기에는 평범한 사람들이 많이 있습니다. 자신의 능력에 자신감이있는 실제 선한 사람을 고용하는 데 어려움을 겪을 것입니다.
David Thornley

1
@David : 내 의견을 부적절한 정도로 확장하지 마십시오. 개발자에게는 반드시 판단이 필요하지만 경계가 있어야합니다. 이 경우 개발자는 자신의 판단을 사용하여 잠재적 인 버그를 발견하고이를 해결하기위한 추가 단계를 수행합니다.
Codism

2

내가 할 :

  • 코드를 수정하고 그것을 깨뜨린 것에 대해 비난 받습니까? 또는
  • 버그를 남겨두고 고객이 발견하면 비난을 받습니까?

버그를 수정하고 단위 테스트를 시작한 후 성공하면 수정을 체크인합니다.

또는 단위 테스트에 시간이 오래 걸리는 경우 수정 프로그램을 먼저 확인한 다음 커밋에 문제가 발생하여 CI 도구에서 메일을 보낼지 여부를 기다립니다.


1
또는 게이트 체크인을 사용하는 경우이를 설정하여 실제로 깨진 코드를 체크인하지 않도록하십시오.
Adam Lear

3
오랜 시간이 걸린다고해서 뻔뻔스런 코드를 저지를 이유는 없습니다.
Toby

@Toby : 변명에 대해 누가 이야기하고 있었습니까? 저는 현재 소규모 팀에서 일하고 있으며 심지어 십여 명의 개발자조차도 아닙니다. 프로젝트의 단위 테스트는 1 시간이 걸립니다. Google의 정책은 귀하가하는 일과 관련 이있는 것으로 보이는 테스트를 실행 한 다음 CI를 확인하여 관련이없는 것으로 보이는 것을 파산했는지 확인하도록하는 것입니다. 이것은 큰 팀에서는 작동하지 않지만 작은 팀에서는 많은 시간을 절약합니다.
sbi

1

충돌 / 데이터 손실 버그 인 경우 수정하십시오. 알려진 데이터 손실 버그가있는 프로그램을 배송하는 것은 완전히 악의적이고 변명 할 수 없습니다.

버그가 장식 적이거나 중요하지 않은 경우 (피할 수있는 경우) 문서화하고 해결 방법을 제공해야합니다. 이상적으로는 수정해야하지만 때로는 현재 릴리스에서 수정하기에는 너무 비쌉니다.

더 큰 소프트웨어 프로젝트마다 ReadMe의 '알려진 문제'섹션에 보통 정확히 다음과 같은 목록이 있습니다. 알려진 버그.

버그를 알고 통신하지 않는 것은 실제로 사소한 / 화장품 버그에만 허용됩니다.


1

이를 수정하고 테스트하십시오. 더 많은 버그를 찾기를 두려워해서 알려진 버그를 유지하기로 결정한 경우, 프로그램은 시한 폭탄을 너무 빨리 똑딱 거리게하여 생각보다 빨리 복구 할 수 없게됩니다.

당신은 주인이고 코드는 종속이기 때문에, 당신이 그것을 볼 때 그것을 바꾸는 것을 두려워하지 않을 수 있습니다. 코드에 대한 두려움 ( "어딘가에 침입하여 보복 할 수 있음")은 용납 할 수 없습니다.


0

크래커 또는 무언가 잘못된 것이 있으면 수정해야합니다. 사양에 모호함이있는 경우, 즉 "고객 이이를 기대할 있지만 버그 일 있습니다"라고 생각하거나 사양에 문제가있는 경우 (예 : "이를 요청했습니다") 그러나 그것은 짜증나 "그러면 무엇을해야하는지 찾아야합니다. 벽에 코드를 던지거나 고객 피드백을 기다리는 것은 좋지 않습니다. 제품 관리자에게 문의하거나 제품을 배포하기 전에 고객에게 요청할 수 있습니다.

"우리는 그 문제에 대해 알고 있으며 차후 릴리스에서 고칠 것입니다"는 "우리는 그 문제에 대해 알고 있지만 문제를 다루지 않도록 충분히 신경 쓰지 않습니다"와 동의어입니다.


0

올바른 행동 과정은 버그를 무시하거나 그 자리에서 "수정"하는 것이 아닙니다. 질문에서 확인한 바로 그 이유 때문입니다.

코드를 먼저 이해해야 한다고 생각합니다 . 보고있는 코드의 수명이 길어 아직 아무도 "버그"를 발견하지 못한 경우 그 이유가있을 수 있습니다. 이 이유를 찾아보십시오. 결정을 내리기 전에 살펴보고 싶은 것은 다음과 같습니다.

  • 역사 : 버전 제어 소프트웨어를 사용하여 질문에 답하십시오. 누가 코드를 만졌습니까? 그들은 무엇을 바 꾸었습니까? 그들은 어떤 커밋 메시지로 체크인 했습니까? 코드가 왜 그렇게 보이는지 추측 할 수 있습니까?

  • 사용 : 어떤 코드가 잘못된 코드를 사용합니까? 그리고 어떻게? 코드가 죽었습니까? 잘못된 행동에 의존하는 다른 코드가 있습니까?

  • 저자 : 위의 정보를 사용하여 신속하게 결론에 도달하지 못하면 코드 작성자에게 코드가 왜 그렇게 보이는지 물어보십시오 (적어도 가능하다면). 일반적으로 "Oups, 수정해야합니다!" 또는 "아니요! 바꾸지 마십시오 !!! 그렇게해야합니다!" 곧.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.