지금까지 문제를 일으키지 않은 버그 수정


20

최근에 일부 코드가 이전보다 훨씬 자주 실행되도록 변경했습니다. 이로 인해 버그가 발견되었습니다. 이 버그는 코드가 실행될 때마다 발생할 가능성이 있었지만 코드가 실행되지 않았기 때문에 전혀 노출되지 않았습니다.

내가 이것을 수석 개발자의 관심을 끌게했을 때 그는 속담을 인용 한 버그를 수정하기보다는 버그가 노출 된 변경 사항을 취소하기를 원했다.

우리가 지금까지 운이 좋았다는 것은 나에게 분명하지만 그는 이성을 듣지 않을 것입니다.

어쨌든 고쳐야합니까?

최신 정보

리드는 기술적으로 저에 대한 권한이 없습니다. 단지 임기. 그는 1 년 전까지 수년 동안이 프로젝트의 유일한 개발자였으며 ​​건설적인 비판을 잘받지 못한다고 생각합니다. 그만한 가치가 있기 때문에 나는 그를 비난하지 않았습니다. 방금 버그가 나타나지 않았다고해서 버그가 없다는 것을 의미하지는 않았습니다.


스레딩 관련 버그 또는 다른 것입니까?
TheLQ

3
그는 이유의 보스입니다. 똥이 팬을 때리면 그는 구운 것입니다. 그가 요구 한 것을하지 않았기 때문에 그가 구워지면 큰 패들이 필요할 것입니다.
Martin York

3
변경을 취소 한 후에도 버그가 발생하는 경우를 구성 할 수 있습니까? 그렇지 않은 경우, 버그가 아닐 수 있으며 문서화되지 않은 한계입니다.
Steve314

3
흠, "파손 된 경우 다른 것을 고정 해제하십시오." 글쎄, 그것은 참신한 해석입니다, 나는 그에게 줄 것입니다.
Orbling

1
"파손되지 않았다면 고치지 마십시오"? 그러나 파산했다.
StuperUser

답변:


26

버그 추적이있는 경우 제출하십시오. 그것이 중요하다면 그것을 높이고 그의주의를 끄십시오. 당신의 뛰어난 추적기에서 그것을 강등 시키십시오. 일이 잘못되면 종이 흔적이 생깁니다.


9
기억하십시오 : 당신의 엉덩이를
가리십시오

1
그렇게 운이 좋지 않습니다. 모든 것은 바지입니다. 버그 추적, 요구 사항 수집, 테스트 없음 경영진이 주장하지 않으면 버전 관리 기능이 없을 것입니다.
Kenneth Cochran

18
작업 환경에 대한 설명을 바탕으로, 수석 개발자가 문제를 해결하지 말라고했을 때 고개를 끄덕이고 미소를 지으십시오.
Carson63000

2
그리고 다음에 그런 질문을하지 마십시오 :-)
gruszczy

2
@codeelegance : "버그 추적, 요구 사항 수집, 테스트 없음. 경영진이 주장하지 않으면 버전 관리 기능이 없을 것입니다." -신의 마리아 마리아 !! 1 !! 그 환경은 사용자 이름에 매우 역설적입니다. :)
Bobby Tables

8

가치보다 더 많은 노력이 필요하지 않은 한 개인적으로 문제를 해결하려고합니다. "파산하지 않으면 해결하지 마십시오"는 소프트웨어에 적용하기가 끔찍합니다.

만약 당신의 수석 개발자가 당신의 상사이고 그것을 만지지 말라고한다면, 나는 그렇지 않을 것입니다.


2
주기가 얼마나 늦습니까? 이것은 잠재적 인 자살 일 수 있습니다.
Job

8
"부러지지 않은 경우 수정하지 마십시오"는 소프트웨어가 중단 된 경우가 아니라 소프트웨어에 적용하기에 완벽한 규칙입니다.
Steve314

고장 나지 않은 경우 고장난 코드의 정의에 따라 소프트웨어에 적용되지 않습니다. 당신이 앉아서 수정해야 할 코드를 쳐다 보는 순간, 그것은 깨지게됩니다. 깨진 코드에 대한 해결 방법을 구현하기 시작한 순간, 실제로 뒤로 작업하고 있으며 시간이 지남에 따라 깨진 코드를 수정하기가 더 어려워 질 것입니다 ...
Ernelli

2

대부분의 답변과 의견은 버그 보고서를 작성하고 다른 사람이 전화를 걸도록하여 결정에 대한 책임을 완화 할 것을 제안했습니다.

나는 버그 추적기가 없기 때문에 (내가 아닌 다른 사람이 그것을 사용할 것이라고 의심한다) 나는 다음으로 최선을 다했다. 나는 수석 개발자의 머리 위로 갔다. 경영진에게 상황을 설명하고 나서 그들은 내 방식을 보았습니다. 그들은 그것을 올바르게 고치고 리드의 요구 요청을 무시하라고 나에게 말했다 . 그들은 그가 서브 퍼지 (subterfuge)를 발견하고 불평 한 경우에 주름진 깃털을 부드럽게 할 것이라고 말했다.

이상적인 해결책은 아니지만 적어도 버그가 올바르게 수정되었습니다.


당신은 지휘의 사슬 안에서 일했고, 따라서 엉덩이를 덮었습니다. 버그 추적 소프트웨어를 사용하는 것은 회사에서 고려해야 사항으로, 적어도 이와 같은 내용과 기능 요청 등을 추적하는 데 도움이됩니다.
Berin Loritsch

2

"클라이언트가 눈치 채지 못했다면 고치지 마십시오"가 아니라 "고장 나지 않았다면 고치지 마십시오"라는 문구를 상기시킵니다.


1

변경 한 사항에 대해 어떤 정당성이 있습니까? 사용자가 겪게 될 변화 나 기술 부채가 무엇인지 지적 할 수 없다면, 변경 사항을 철회한다는 측면에서 리드 개발자와 협의 할 것입니다.


내 마음에 적어도 두 가지 다른 옵션이 있습니다.

계속 진행하여 버그를 수정하면 믹스에 버그를 추가하여 내 마음에 역효과를 줄 수 있습니다. 경험이 얼마나 많고 여기에 내 가이드가 될 수있는 불쾌한 놀라움을 피할 것이라는 자신감에 달려 있습니다.

당신이하라는 말을한다면 문제가되는 것이 죄책입니까, 아니면 그 이상입니까? 원칙과 가치로 알려진 것 이외의 문제가 무엇인지 궁금합니다. 나는 약간의 농담 으로이 아이디어에 어떤 문제가 있는지에 대한 정직한 점으로 의미합니까?


다른 버그를 수정하기 위해 변경이 필요했습니다. 리드는 버그의 원인을 수정하기보다는 코드 실행 빈도를 제한하는 조건을 설정하도록 제안했습니다. 내가 고친 버그와 내가 발견하지 못한 버그는 모두 쇼 스토퍼입니다.
Kenneth Cochran

3
이 경우 올바르게 수정해야합니다. 문제를 둘러싼 조건을 사용하면 재앙이 지연 될뿐 아니라 잘못된 코드가 더 많이 추가됩니다. 나쁜 (어리석은) 솔루션입니다.
quick_now

1

압도적 인 본능은 문제를 숨기지 않는 버그를 수정하는 것이지만, 코를 잡고 문제를 숨기는 시나리오가 있습니다.

  1. 내부적으로 코드가 사용되기도하고 회사 내부에서 버그의 결과를 관리 할 수 ​​있습니다.
  2. 오늘날 배송을 요구하는 압도적 인 상업적 고려 사항과 버그 수정은 2 주 후에 최소한의 결과로 출시 될 수 있습니다.

전문적으로, 나는이 답변을 좋아하지 않으며, 이러한 상황에서 에테르가 발생하고 있음을 내부적으로 분명히하고 있습니다.


0

궁극적으로, 당신은 당신의 상사가 명시 적으로 말하지 않은 행동을해서는 안됩니다. 귀하의 입장에서 할 수있는 가장 좋은 일은 귀하가 가지고있는 버그 추적 데이터베이스에 버그 보고서를 작성하는 것입니다. 이런 식으로 최소한 모든 사람이이 문제를 알고 있으며 더 많은 권한을 가진 사람이이 문제를 어떻게 처리할지 결정할 수 있습니다.


0

버그가있는 함수를 복사하고 수정 사항을 적용한 후 이름을 바꾸고 약간 위장한 다음 대신 호출하십시오.

두 개의 showtopper bugs 의견에 따라 법의 서한을 따르지만 그 정신을 무시하는 것이 가장 좋습니다.

분명히 잘라 내기 및 붙여 넣기 코딩 단점이 있지만 문제가 가장 적은 것처럼 들립니다.


1
나쁜 생각, 내가 프로그래머 중 한 명과 같은 일을 잡았다면 그 자리에서 그를 해고 할 것입니다. 이는 코드와 코드를 유지 해야하는 사람에게 손상을 줄 수있는 확실한 방법입니다.
Miki Watts

@ 미키-이 경우 나쁜 생각이 아닌 것이 무엇인지 정확히 말해 주시겠습니까? 다른 버그 (어쨌든 있던)가 더 잘 보이도록 버그를 다시 넣는 방법을 설명해주세요. 그 자리에서 발사하는 것에 관해서는 개발자가 거의 선택하지 않았기 때문에 건설적인 해고를 주장합니다.
Steve314
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.