누군가의 커밋으로 인해 회귀가 발생했다고 말해야합니까?

이전 작업 코드가 작동을 멈추게하는 버그 인 회귀를 추적하고 수정하면 버전 제어를 통해 변경 사항을 적용한 사람을 찾을 수 있습니다.

이것을 할 가치가 있습니까? 커밋 한 사람에게 이것을 지적하는 것이 건설적인가? 실수의 본질 (변경된 코드에 대한 기본적인 오해에 대한 단순한 부주의의 규모)이 좋은 생각인지 아닌지 변화합니까?

그들에게 말을하는 것이 좋은 생각이라면, 공격을하거나 방어를하지 않으면 서 좋은 방법은 무엇입니까?

논란을 위해 CI 서버의 자동화 된 테스트에서 버그를 포착 할 수 없을 정도로 버그가 미묘하다고 가정합니다.

당신이 그들에게 그들이 한 실수에 대해 이야기하기 위해 그들에게 접근한다면, 당신이 세상에서 가장 훌륭한 외교관이 아니라면 "Ha!-이 실수를 봐!" 우리는 모두 인간이며 비판하기가 어렵습니다.

다른 한편으로는, 변화가 완전히 사소하고 명백하게 잘못 되지 않는 한, 나는 일반적으로 진행되는 일을 완전히 이해하기 위해 조사의 일환으로 원래의 변화를 저지른 사람과 이야기하는 것이 유익하다는 것을 알았습니다. 이러한 상황을 처리하는 것은 말한 사람에게 가서 다음과 같은 대화를 나누는 것입니다.

나 : 나는이 버그를 연구하고 있는데 ... 버그 요약 ... 나는 당신이 변경 한 문제를 추적했다고 생각한다. 이 변경 사항이 무엇인지 기억하십니까? /이 변경 사항을 설명 할 시간이 있습니까?

그런 다음

그들 : 물론, 처리해야 할 상황 ... 알지 못하는 상황 ...

또는 다음과 같은 내용이 있습니다.

그들 : 아니, 미안하지만 기억이 안 나에게 잘못 보인다.

변경 / 버그를 함께 조사하고 조사함으로써 원래 커미터는 실수를 저지르는 것처럼 느끼지 않고 실수로부터 배우게됩니다. * 또한 무언가를 배우게 될 가능성도 매우 높습니다.

원래 커미터가 주변에 없거나 바쁘면 그냥 꼼짝 않고 스스로 알아낼 수 있습니다. 원래 변경 한 사람과 이야기하는 것이 더 빠르다는 것을 알았습니다.

* 물론 다른 사람의 도움에 정말로 관심이있는 경우에만 작동합니다. 만약 누군가가 실수 한 것에 대해 다른 사람에게 알리는 가장 위장 된 방법으로 이것을 사용한다면, 이것은 단지 그것에 대해 공개하는 것보다 더 나쁠 것입니다.

공격적이지 않은 주장. "이 코드는 작동하지 않습니다"와 "코드가 작동하지 않습니다"와 유사한 것을 말하는 것이 좋습니다. 코드를 작성한 사람이 아니라 코드를 비판하십시오.

더 나은 방법은 솔루션을 생각할 수 있다면 분산 버전 제어 시스템이 있다고 가정하고 솔루션을 수정하여 적용하십시오. 그런 다음 수정 한 버그에 대한 수정이 유효한지 물어보십시오. 전반적으로, 프로그래밍에 대한 지식과 지식을 모두 높이십시오. 그러나 자아를 방해하지 않으면 서 그렇게하십시오.

물론 동일한 문제로 다른 개발자의 의견을 듣고 기꺼이 원하는 방식으로 행동해야합니다.

예, 항상 . 프로그래머는 실수로부터 배우는 것이 당신의 일입니다.

그들이 실수를 저지르면 더 나은 코더가되어 미래에 실수 할 가능성을 줄일 수 있습니다. 그러나 정중하고 많은 것을 만들지 마십시오. 우리 모두는 종종 버그를 만듭니다. 예의 바른 이메일은 사람들에게 알리는 비 대립적인 방법입니다.

건설적인 방법은 버그를 찾아 수정하고 향후 유사한 버그가 발생하지 않도록 조치를 취하는 것입니다.

사람들에게 버그를 도입하지 않는 방법을 설명하는 것이 포함되어 있다면 버그를 해결하십시오.

한 번은 프로젝트 관리자가 특정 개발자에게 실수를 한 적이 없다는 팀에서 일했습니다. 팀 전체와 회의를 조직하여 실수가 발생했으며 억제하기 위해 새로운 프로세스가 정의되었다고 설명했습니다. 그런 종류의 실수. 그렇게하면 아무도 낙인을 당하지 않았습니다.

일반적으로 그렇습니다 .

당신이 그것에 대해 전술이라면 아무도 방어 적이되어서는 안됩니다. 이를 처리하는 쉬운 방법은 변경 사항을 트렁크에 다시 커밋하기 전에 변경 사항을 다시 확인하도록 요청하는 것입니다 (또는 버전 관리 시스템과 관련된 모든 것). 명백한 오류를 수정하여 몇 분을 절약하면 사람들은 그것을 감사하게 생각하지만, 깨지지 않은 것을 수정하고 코드를 깨 뜨리면 감사하지 않을 것입니다. 변경 사항을 검토 할 기회를 주면 발가락을 밟고 싶지 않다는 사실을 알리고 변경 사항에 반대 할 기회를줍니다.

오타가 아니라 큰 변화가있는 경우 문제를 해결하기 전에 저자에게 미리 알려주는 것이 좋습니다. "조, 어제 내 물건을 병합하고 이해가 잘 안되는 것을 발견했다. 버그처럼 보이지만 코드를 망치기 전에 실행 해보고 싶었다. 나를?"

저자와의 관계는 큰 요소입니다. 저자가 말하지 않고 코드를 수정하는 것을 신경 쓰지 않으면 기분이 상호간에 확신이 있다면 언급 할 가치가 없습니다. 더 많은 경험 / 연장 / 상태를 가진 사람이라면 코드를 변경하겠다고 알려주십시오. 그것이 적은 사람이라면 실수를 반복하지 않기 위해 들어야 할 종류인지 또는 불필요하게 당황 스러울 수 있는지 고려하십시오.

누가 "버그"를 체크인했는지 알아 내면 누가 "코드를 수정했는지"쉽게 찾을 수 있다는 것을 기억하십시오. 그들이 사실 이후에 당신의 변화에 ​​대해 화가 나거나 화가 나거나 당황했다고 생각한다면, 반드시 미리 알려주십시오.

또한 버그 수정이 유일한 옵션은 아닙니다. 항상 이슈 트래커에서 버그를보고 할 수 있습니다. 여기서는 전술이 다시 필요합니다. 버그를보고하면 전체 팀이 버그를 더 잘 볼 수 있지만 저자는 자신의 실수를 바로 잡을 수 있습니다. 문제를 해결하는 가장 좋은 방법이 확실하지 않거나 문제를 해결할 시간이없는 경우보고가 가장 좋습니다.

버그가 포함 된 커밋을하면 더 잘 말해 줄 수 있습니다. 버그가 포함 된 커밋이 발견되면 반드시 알려 드리겠습니다.

우리는 오류를 이해할 때만 향상됩니다. 이것이 미래에 더 나은 코드를 생성하는 방법입니다.

여기서 훌륭한 답변을 얻고 있습니다.

실수했을 때 한 번만 관리자에게서 배운 기술을 추가 할 수있었습니다.

나는 박사와 중년 컨설턴트였습니다. 그녀는없는 젊은 매니저 였기 때문에 명성있는 그라디언트가있을 수있었습니다. 어쨌든, 그녀는 분명히이 상황에 대한 경험이 있었으며 그것을 처리하는 방법을 알고있었습니다.

그녀는 문제가있는 것 같아서 거의 사과하는 말로 나에게 언급했으며, 그것을 조사 할 시간이 있습니까?

종종, 그 실수는 내 것이었고, 그녀는 그것을 알고있었습니다. 그것은 기술이다.

이 질문에 더 깊은 문제가 있다고 생각합니다. 그렇습니다. 제출자는 변경 사항의 결과를 반드시 알고 있어야하므로 무슨 일이 있었는지 다시 이해하고 같은 일을 다시는 할 수 없습니다. 그러나 질문의 ​​맥락에 따르면 원래 제출자에게 문제가 있음을 알리지 않고 수정 프로그램 을 준비하여 제출 했음을 나타냅니다 . 거기에 더 깊은 문제가있다 : 왜 제출자는 이미 회귀에 대해 알고하지 않습니다 그리고 그들은 그들 자신을 왜 해결되지 않았다? 설명 된 상황은 원래 제출자 측에 대한 책임 또는 경계가 없음을 나타낼 수 있으며 이는 전반적인 성능 및 동기와 관련하여 잠재적 인 관심사입니다.

저의 소프트웨어 엔지니어링 경험은 제가 책임지고있는 프로젝트뿐만 아니라 생산까지의 모든 코드 변경 사항을 소유하도록 가르쳐 주었으며, 여기에는 빌드 시스템 및 (분명히) 제품 동작에 대한 영향을 인식하는 것이 포함됩니다.

누군가의 변화가 문제를 일으킨다 고해서 그 사람이 나쁜 엔지니어라는 의미는 아니지만 일반적으로 그들이 잘못한 것을 고치기 위해 책임을지고 관여해야합니다. 예를 들어 코드가 "결함이없는"경우에도 코드가 코드베이스에 존재하는 근본적인 버그를 노출 한 경우에도 변경에 대한 문제를 처음으로 인식하는 사람 중 하나 여야합니다. 원래 제출자가 버그를 수정하는 데 적합한 사람이 아니더라도 변경의 수명주기와 밀접한 관련이 있어야합니다.

귀하의 질문에 대한 좋은 견인! 모두가 무엇을하는지 알려줍니다. 말해야합니까? 예! 질문이 "더 많은 의사 소통을해야합니까?"라고 물으면 대답은 거의 항상 그렇습니다!

그러나 다른 것을 추가하려면 전제에 결함이 있습니다.

동료가 커밋을하여 CI를 위반하지는 않았지만 문제를 발견하게했습니다.

축하합니다! 회귀가 아닌 새로운 버그를 발견했습니다. 진지하게, 커밋 할 때 자동화 된 (또는 표준화 된 수동) 테스트에서 다루지 않는 모든 시나리오와 코드 라인을 수동으로 테스트합니까?

꼭 동료에게 문제를 해결하고 다시는 일어날 수 없는지 테스트하십시오. 당신은 둘 다 영웅입니다! 그러나 말이나 행동에 책임이 없다면, 가장 나쁜 조직 질병 중 하나 인 책임없는 책임을 영속해야합니다.

정말 경건한 것을 찾아야한다면, 원래 코드를 깨뜨린 사람에 대해 생각하고 의심의 여지가없는 친구를 위해 함정을 남겼습니다 (분명히 테스트 범위가 없음). 잘만되면 그것은 당신이 아니었다!

항상 상대방을 당신보다 나은 사람으로 생각하고, 항상 다른 사람의 좋은 특성을보고, 실수를 할 수 있다는 것을 항상 알고 있습니다.

둘이서 만 말해줘

당신이 그에게 실수했다고 말했을 때 누군가가 화를 낸다면, 그는 그가 지구상에서 가장 현명하다고 생각하고 실수하지 않으며, 비판을받을 때, 우리가 폴란드에서 말한 것처럼 그의 머리'.

따라서 누군가 실수했다는 말을 주저하지 말아야합니다. 보통이다. 모두가 실수를 저지르고 심지어 최고입니다! 아무것도하지 않는 사람들 만 실수하지 않습니다.)

다른 사람들이 말한 것 외에도 실제로 버그를 일으킨 커밋인지 확인하십시오. 확실히 자신의 실수로 다른 사람을 비난하지 마십시오. 아무리 재치있게 접근하더라도,하지 않은 것에 대해 비난했다면 여전히 화를 낼 것입니다. (다른 사람들의 버그에 대해 끊임없이 비난받은 ​​사람이라고 말하면, 누군가 누군가 나에게 와서 완전히 바보 같은 짓을하고 커밋 로그를 가져와 마지막 코드를 만지는 사람이 나를 비난하는 사람. 어쨌든 그는 내가 원래 줄을 썼기 때문에 여전히 내 잘못이라고 생각하는 것 같았습니다.)

여기서 질문에 대한 최고 투표 의견을 반영하는 단일 답변이 보이지 않습니까?

예, 절대적으로 말하지만 팀 전체 앞에서는하지 마십시오

개발자 1 : 1에게 접근하여 버그를 지적하십시오. 많이 만들지 마십시오. 나는 항상 전체 팀 앞에서 오류를 지적하는 것이 나쁜 생각이라고 생각했습니다. 일부 개발자에게는 효과가 있지만 모든 사람에게는 효과가 없으며 부정적인 영향을 줄 수 있습니다. 우리는 어느 시점에서나 모두 신발을 신었고 두 번째로 가장 많이 나온 답변에서 알 수 있듯이 실수를 통해 배우는 것을 기억하십시오

나는 일반적으로 칭찬으로 시작한 다음 오류가 발생했을 때 가장 잘 작동한다는 것을 알았습니다. , b, c,하지만 x, y, z를 일으키는 것 같습니다. "

간단한 대답 : 그렇습니다.

더 긴 대답 : 저의 마지막 직업은 SVDD 리포지토리에있는 것이 항상 잘 작동하는 코드를 보장하기 위해 CI 도구와 함께 TDD를 사용하는 Agile 회사였습니다. 무언가가 커밋되면 TeamCity 서버는 사본을 받아서 컴파일하고 단위 테스트를 실행했습니다. 또한 매시간 통합 테스트를 실행했습니다. CI가 실패한 원인이 커밋되면 모든 사람이 특정 사람의 커밋을 기반으로 빌드가 손상되었다는 내용의 전자 메일을 받았습니다.

항상 모든 것을 잡는 것은 아닙니다. 우리에게 화가 났지만, 우리는 코드 적용을 강요하지 않았으며, 단위 또는 통합 테스트에 의해 무언가가 포함되어 있어도 그 코드를 충분히 행사 하지 못할 수 있습니다 . 이 문제가 발생하면 알려진 문제 (QA가 발견 한 경우) 또는 결함 (dun-dun-dun, 고객이 수행 한 경우)을 수정하는 작업을 수행 한 사람은 "비난"( 코드 파일)과 범인을 결정합니다.

깨진 코드를 체크인하기 위해 누군가를 불러내는 것이 반드시 나쁜 것은 아닙니다. 그들은 제대로 업무를 수행하지 못했고, 자신이나 다른 사람이 돌아가서 실수를 해결해야했습니다. 이것은 항상 일어난다. 얼마나 큰 문제는 해결이 얼마나 쉬운 지, 실수로 인해 해당 코드를 컴파일하거나 실행하지 않았는지 여부와 전체 회사 문화에 따라 달라집니다. 전체적으로 중요한 것은 실수를 한 사람이 무언가를 배운다는 것입니다. 같은 사람으로 인해 빌드가 계속 끊어지면 그 사람에게 더 큰 문제가 있습니다. 항상 깨는 빌드는 팀의 커뮤니케이션 또는 프로세스 지식에 문제가 있음을 나타냅니다.

예. 담당자에게 코드 수정 사항을 검토하도록 요청하십시오. 때로는 다른 사람의 버그가 실제로 코드의 까다로운 부분이라는 것을 발견했습니다. 버그가 단순히 수정 된 경우 보이지 않는 다른 결과가 있습니다.

플레이 할 요소가 많이 있습니다.

• 버그는 얼마나 심각합니까?
• 당신과 차단기의 선임 관계는 무엇입니까?
• 팀이 얼마나 바쁘거나 스트레스를 받습니까?
• 차단기가 코드베이스 또는 귀하의 역할을 수행하고 있습니까?
• 그것이 실제로 버그 였다는 것이 얼마나 확실합니까? 그리고 당신의 수정이 맞다는 것이 얼마나 확실합니까?

문제가 사소한 경우 (오타 / thinko / 잘라 내기 및 붙여 넣기 버그)-차단기가 바쁜 동료이고 문제 평가에 확신이있는 경우에는주의를 기울일 필요가 없습니다. (예 :) foo.x = bar.x; foo.y = bar.y, foo.z = bar.y.

대부분의 경우 문제를 언급하는 것이 좋습니다. 심각하지 않은 경우에는 수행중인 작업을 중단 할 필요가 없습니다. 점심을 먹거나 휴게실에서 뛸 때까지 기다립니다.

그러나 오류의 본질이 (구현 플랫폼, 로컬 정책 또는 프로젝트 사양에 대한) 심각한 오해를 나타내는 경우 최대한 빨리 제기하십시오.

평가가 확실하지 않은 경우 특히 익숙한 코드가 아닌 경우 수정 사항을 검토하도록 요청하십시오. (어쨌든 체크인하기 전에 다른 사람이 모든 변경 사항을 검토하는 '코드 친구'정책을 개발자 팀이 채택하는 것이 좋습니다.)

말하지 않으면 어떻게 되나요?

단점

문제를 일으키는 지 이해하지 못하기 때문에 다른 장소에서도 같은 실수를 할 수 있습니다. 그뿐만 아니라 같은 실수를 반복적으로 고치는 데 불필요한 시간이 더 필요할 것입니다. 당신은 당신이 모르는 실수에서 배울 수 없습니다.

둘째, 그들은 자신보다 더 나은 일을하고 있다고 생각합니다. 사람들이 자신의 문제를 인식하지 못하는 경우, 자신이 그렇지 않을 때 자신이 잘하고 있다고 생각한다고해서 비난받을 수는 없습니다. 문제가 부주의 한 실수 일지라도 사람들은 실수가 눈에 aware다는 것을 알고있을 때 더 적은 실수를합니다.

다음으로 누군가가 누가 그 일을했는지 ​​찾지 않으면, 항상 부주의하거나 제품에 대한 기본적인 오해가있는 특정 문제 직원이 있는지 어떻게 알 수 있습니까? 책임있는 사람이 자신이 속한 팀에서 계속되기를 원합니까?

당신이 그것을 논의하지 않고 수정하고 계속한다면, 당신은 그것을 올바르게 고쳤습니까? 요구 사항이 변경 될 때 변경해야하는 테스트 인 경우도 있습니다. 그것이 아주 작은 오타가 아닌 다른 것이라면, 당신 중 하나가 올바른 해결책을 가지고 있다고 확신 할 수 있습니까? 당신은 컨설팅없이 대가로 코드를 깨뜨릴 수 있습니다.

프로

사람들은 자신의 실수를 지적한 것에 대해 당황하거나 짜증을 내지 않습니다.

나는 그들에게 말하고 있지만 개인적으로 훌륭하게 수행하는 측면에서 강하게 내려온 것 같습니다. 공공 굴욕이 필요하지 않습니다. 그 사람이 반복해서 같은 실수를하거나 이해력이 부족한 중대한 실수를 저지르는 경우, 감독자도 인식해야합니다.