이전 작업 코드가 작동을 멈추게하는 버그 인 회귀를 추적하고 수정하면 버전 제어를 통해 변경 사항을 적용한 사람을 찾을 수 있습니다.
이것을 할 가치가 있습니까? 커밋 한 사람에게 이것을 지적하는 것이 건설적인가? 실수의 본질 (변경된 코드에 대한 기본적인 오해에 대한 단순한 부주의의 규모)이 좋은 생각인지 아닌지 변화합니까?
그들에게 말을하는 것이 좋은 생각이라면, 공격을하거나 방어를하지 않으면 서 좋은 방법은 무엇입니까?
논란을 위해 CI 서버의 자동화 된 테스트에서 버그를 포착 할 수 없을 정도로 버그가 미묘하다고 가정합니다.
답변
당신이 그들에게 그들이 한 실수에 대해 이야기하기 위해 그들에게 접근한다면, 당신이 세상에서 가장 훌륭한 외교관이 아니라면 “Ha!-이 실수를 봐!” 우리는 모두 인간이며 비판하기가 어렵습니다.
다른 한편으로는, 변화가 완전히 사소하고 명백하게 잘못 되지 않는 한, 나는 일반적으로 진행되는 일을 완전히 이해하기 위해 조사의 일환으로 원래의 변화를 저지른 사람과 이야기하는 것이 유익하다는 것을 알았습니다. 이러한 상황을 처리하는 것은 말한 사람에게 가서 다음과 같은 대화를 나누는 것입니다.
나 : 나는이 버그를 연구하고 있는데 … 버그 요약 … 나는 당신이 변경 한 문제를 추적했다고 생각한다. 이 변경 사항이 무엇인지 기억하십니까? /이 변경 사항을 설명 할 시간이 있습니까?
그런 다음
그들 : 물론, 처리해야 할 상황 … 알지 못하는 상황 …
또는 다음과 같은 내용이 있습니다.
그들 : 아니, 미안하지만 기억이 안 나에게 잘못 보인다.
변경 / 버그를 함께 조사하고 조사함으로써 원래 커미터는 실수를 저지르는 것처럼 느끼지 않고 실수로부터 배우게됩니다. * 또한 무언가를 배우게 될 가능성도 매우 높습니다.
원래 커미터가 주변에 없거나 바쁘면 그냥 꼼짝 않고 스스로 알아낼 수 있습니다. 원래 변경 한 사람과 이야기하는 것이 더 빠르다는 것을 알았습니다.
* 물론 다른 사람의 도움에 정말로 관심이있는 경우에만 작동합니다. 만약 누군가가 실수 한 것에 대해 다른 사람에게 알리는 가장 위장 된 방법으로 이것을 사용한다면, 이것은 단지 그것에 대해 공개하는 것보다 더 나쁠 것입니다.
답변
공격적이지 않은 주장. “이 코드는 작동하지 않습니다”와 “코드가 작동하지 않습니다”와 유사한 것을 말하는 것이 좋습니다. 코드를 작성한 사람이 아니라 코드를 비판하십시오.
더 나은 방법은 솔루션을 생각할 수 있다면 분산 버전 제어 시스템이 있다고 가정하고 솔루션을 수정하여 적용하십시오. 그런 다음 수정 한 버그에 대한 수정이 유효한지 물어보십시오. 전반적으로, 프로그래밍에 대한 지식과 지식을 모두 높이십시오. 그러나 자아를 방해하지 않으면 서 그렇게하십시오.
물론 동일한 문제로 다른 개발자의 의견을 듣고 기꺼이 원하는 방식으로 행동해야합니다.
답변
예, 항상 . 프로그래머는 실수로부터 배우는 것이 당신의 일입니다.
그들이 실수를 저지르면 더 나은 코더가되어 미래에 실수 할 가능성을 줄일 수 있습니다. 그러나 정중하고 많은 것을 만들지 마십시오. 우리 모두는 종종 버그를 만듭니다. 예의 바른 이메일은 사람들에게 알리는 비 대립적인 방법입니다.
답변
건설적인 방법은 버그를 찾아 수정하고 향후 유사한 버그가 발생하지 않도록 조치를 취하는 것입니다.
사람들에게 버그를 도입하지 않는 방법을 설명하는 것이 포함되어 있다면 버그를 해결하십시오.
한 번은 프로젝트 관리자가 특정 개발자에게 실수를 한 적이 없다는 팀에서 일했습니다. 팀 전체와 회의를 조직하여 실수가 발생했으며 억제하기 위해 새로운 프로세스가 정의되었다고 설명했습니다. 그런 종류의 실수. 그렇게하면 아무도 낙인을 당하지 않았습니다.
답변
일반적으로 그렇습니다 .
당신이 그것에 대해 전술이라면 아무도 방어 적이되어서는 안됩니다. 이를 처리하는 쉬운 방법은 변경 사항을 트렁크에 다시 커밋하기 전에 변경 사항을 다시 확인하도록 요청하는 것입니다 (또는 버전 관리 시스템과 관련된 모든 것). 명백한 오류를 수정하여 몇 분을 절약하면 사람들은 그것을 감사하게 생각하지만, 깨지지 않은 것을 수정하고 코드를 깨 뜨리면 감사하지 않을 것입니다. 변경 사항을 검토 할 기회를 주면 발가락을 밟고 싶지 않다는 사실을 알리고 변경 사항에 반대 할 기회를줍니다.
오타가 아니라 큰 변화가있는 경우 문제를 해결하기 전에 저자에게 미리 알려주는 것이 좋습니다. “조, 어제 내 물건을 병합하고 이해가 잘 안되는 것을 발견했다. 버그처럼 보이지만 코드를 망치기 전에 실행 해보고 싶었다. 나를?”
저자와의 관계는 큰 요소입니다. 저자가 말하지 않고 코드를 수정하는 것을 신경 쓰지 않으면 기분이 상호간에 확신이 있다면 언급 할 가치가 없습니다. 더 많은 경험 / 연장 / 상태를 가진 사람이라면 코드를 변경하겠다고 알려주십시오. 그것이 적은 사람이라면 실수를 반복하지 않기 위해 들어야 할 종류인지 또는 불필요하게 당황 스러울 수 있는지 고려하십시오.
누가 “버그”를 체크인했는지 알아 내면 누가 “코드를 수정했는지”쉽게 찾을 수 있다는 것을 기억하십시오. 그들이 사실 이후에 당신의 변화에 대해 화가 나거나 화가 나거나 당황했다고 생각한다면, 반드시 미리 알려주십시오.
또한 버그 수정이 유일한 옵션은 아닙니다. 항상 이슈 트래커에서 버그를보고 할 수 있습니다. 여기서는 전술이 다시 필요합니다. 버그를보고하면 전체 팀이 버그를 더 잘 볼 수 있지만 저자는 자신의 실수를 바로 잡을 수 있습니다. 문제를 해결하는 가장 좋은 방법이 확실하지 않거나 문제를 해결할 시간이없는 경우보고가 가장 좋습니다.
답변
버그가 포함 된 커밋을하면 더 잘 말해 줄 수 있습니다. 버그가 포함 된 커밋이 발견되면 반드시 알려 드리겠습니다.
우리는 오류를 이해할 때만 향상됩니다. 이것이 미래에 더 나은 코드를 생성하는 방법입니다.
답변
여기서 훌륭한 답변을 얻고 있습니다.
실수했을 때 한 번만 관리자에게서 배운 기술을 추가 할 수있었습니다.
나는 박사와 중년 컨설턴트였습니다. 그녀는없는 젊은 매니저 였기 때문에 명성있는 그라디언트가있을 수있었습니다. 어쨌든, 그녀는 분명히이 상황에 대한 경험이 있었으며 그것을 처리하는 방법을 알고있었습니다.
그녀는 문제가있는 것 같아서 거의 사과하는 말로 나에게 언급했으며, 그것을 조사 할 시간이 있습니까?
종종, 그 실수는 내 것이었고, 그녀는 그것을 알고있었습니다. 그것은 기술이다.