프로그래머가 다른 사람의 실패한 빌드를 수정해야합니까? [닫은]

한 프로그래머가 SVN 저장소에 일부 작업을 수행 한 후 집으로 돌아갔습니다. 그가 떠난 후 Hudson 자동 빌드는 실패했습니다. 다른 프로그래머가 이것을보고 코드 변경을 검토 한 후 문제가 라이브러리 하나가 없다는 것을 발견했습니다. 그는이 라이브러리를 SVN에 추가했고 다음 빌드는 성공적으로 완료되었습니다.

두 번째 프로그래머가 옳은 일을 했습니까 아니면 첫 번째 프로그래머가 문제를 해결할 때까지 기다려야 했습니까?

그것은 당신의 팀이 일반적으로 어떻게 작동하는지에 달려 있지만, 괜찮습니다. 빌드 작업을 유지하면 다른 모든 시간이 절약됩니다.

두 번째 프로그래머는 라이브러리의 특정 버전이 필요하거나 다른 합병증이있는 경우를 대비하여 첫 번째 전자 메일을 삭제하여 자신이 한 일을 설명하는 것이 예의입니다. 또한 그들이 빌드를 깨뜨렸다는 것을 지적하는 약간 더 미묘한 방법입니다.

따라 다릅니다.

• 라이브러리를 추가하는 것이 문제를 해결하는 방법이라는 버그가 너무 명백합니까? 때때로 수정은 해당 라이브러리가 필요없는 해결 방법을 찾는 중입니다.

• 모든 변경 사항이 기존 티켓에 연결되어야하는 단계에 프로젝트가 있습니까? 그렇다면 티켓을 제출하셨습니까? 그 티켓이 당신에게 할당 되었습니까?

어쨌든 책임을지는 것이 아니라 버그를 수정하는 데 집중하십시오.

네 괜찮습니다. 그러나 빌드가 컴파일 될 때 테스트하기 전에 원래 프로그래머가 집에 돌아가는 것은 비전문가입니다.

당신의 평판은 100 % 통제력입니다. 이와 같은 것들이 당신의 명성을 손상시키고, 변색 된 명성을 연마하는 것은 매우 어렵습니다.

소통하다

해당 시나리오에 대한 엄격한 규칙 (자신의 팀 규칙 외에)은 없습니다.

Dev2는 dev1에게 자신의 실수를 고칠 수 있다고 말할 수 있어야하며, 이들 중 누구도이 교환으로 인해 발생하는 것을 두려워해서는 안되며 팀의 일부입니다.

왜 안돼? 비난을 고치는 것보다 당신의 제품이 더 중요하다면, 확실히 괜찮습니다. 라이브러리 변경으로 인한 빌드 실패는 상당히 불충분하기 때문에 개발자가 테스트하지 않은 것에 대해 질책해야합니다.

빌드 실패가 발생합니다. 매일 빌드 해야하는 것이 중요하다면 문제를 해결 한 다음 깨진 코드를 체크인 한 개발자가 다음 날 수정 사항을 검토하고 코드가 정상적으로 작동하는지 확인하도록 요청합니다.

이미 말했듯이, 그것을 고친 사람은 아마 그것을 고친 사람에게 전자 메일을 보내고 수정 사항이 무엇인지 자세히 설명해야합니다.

내 좌우명은 오후 3시 이후에 SVN에 헌신하지 않으므로 항상 자신의 빌드 실패를 해결할 수 있습니다.

빌드 실패를 해결하지 않으면 다른 모든 빌드도 실패합니다. 장기적으로 시간을 절약하기 위해 문제를 해결할 것이지만, 문제를 해결해야한다는 것을 알고 있어야합니다.

일종의 '비난의 손가락을 가리킴'스크립트를 사용하는 것이 이것을 수행하거나 빌드를 깨는 사람이 도넛을 사도록 만드는 좋은 방법입니다!

누군가는 그것을 고쳐야하며 첫 번째 프로그래머는 먼저 빌드를 깨지 않았는지 확인하지 않고 집에 가서는 안됩니다. 그러나 쉽게 해결할 수있는 문제의 경우, 문제를 직접 해결하기 위해 다시 전화하는 것은 극단적 일 것입니다.

나는 설명적인 이메일을 보내는 루크 그레이엄의 제안에 동의한다. 비록 그것이 정중 한 것이 아니라 기본 커뮤니케이션이다.

예 예 예! 그것은 집단적 코드 소유권을 장려하고, 높은 표준을 유지하고 깨진 창 시나리오가 개발되지 않도록 팀에 건전한 동료 압력을 설정합니다. 다른 개발자에게 알리는 약간의 의사 소통은 좋은 생각입니다.

나는 명백한 것들을 고치는 것이 좋다고 생각한다. 즉, 만약 당신이 고치고있는 코드를 가진 사람이 동일하거나 실질적으로 같은 고침을 만들 것이라고 100 % 확신한다면. 수정 프로그램이 더 복잡한 경우 일반적으로 수정하려는 코드를 가진 사람에게 이야기하는 것이 예의입니다. 의도를 잘못 이해했거나 파손 이유가 생각했던 것과 다르거 나 다른 수정을 의도했을 수 있습니다. 그러나 어떤 이유로 든 아직 커밋 할 수 없었습니다 (생명이 발생합니다. :).

일반적으로 규칙은 일반적으로 다음과 같습니다. 빌드를 중단합니다. 빌드를 수정하지만 예외가 있습니다. 특히 수정이 명백하거나 책임있는 사람이 접근 할 수없는 경우에 예외가 있습니다.

물론 직렬 빌드 차단기의 경우 (특히 "체크인, 집에 갔고, 며칠 동안 고장난 빌드"패턴을 사용하는 경우) 담당자는 CI 시스템 및 테스트가 존재하는 이유와 그 방법에 대해 이야기해야합니다. 체크인하기 전에 확인 :)

일이 일어난다. Subversion에 새 코드 파일 (소스 또는 컴파일 된)을 추가하지 못하면 개발자 컴퓨터에서 빌드되었다고 가정 할 때 빌드가 손상되는 가장 일반적인 원인 일 수 있습니다. CI 환경에 대한 나의 마지막 직업에서, 심지어 가장 선임자들조차도 때때로 잊어 버렸습니다.

다른 사람이 빌드를 수정하여 팀을 흥얼 거리게 할 수 있다면 괜찮습니다. 집에 온 프로그래머는 최소한 무슨 일이 있었는지 알려주는 전자 메일이 필요하다고 생각하고 커밋 전에 새 코드가 추가되도록 상기시켜야합니다. 이런 일이 자주 발생하면,“부끄러움의 춤”에 의해 처벌 될 수있는 사소한 범죄가 발생을 줄이고 분위기를 약화시킬 수 있습니다.

팀 역학에 의존하지만 이상적인 세계에서는 팀의 모든 사람이 전체 프로젝트, 모든 코드 및 결과적으로 모든 버그를 "소유"합니다. 따라서 문제를 발견하면 문제를 해결하고 코드에 특정 값이 추가 된 경우에만 버그의 작성자와 통신하십시오.

이것이 정기적으로 발생하지 않는 한 문제를 해결하는 것이 좋습니다.이 경우 상사가 그에게 전화하여 돌아와서 스스로 고치게하십시오.

그것은 달려있다 ...

프로그래머로서 우리의 일은 사람들을 판단하는 것이 아니라 일을하는 것입니다. 그래서 당신이 할 수있는 최선의 방법은 그것을 고치거나 명확하지 않은 경우 변경 사항을 롤백하고 첫 번째 프로그래머에게 알려 주면 나중에 고칠 수 있다는 것입니다.

어쨌든, 이상한 모자를 쓰고 빌드를 깨뜨린 최신 기사를 보유하는 것만으로도 다음 번에 더 많은 관심을 기울일 수 있습니다 ^ _ ^

일부 환경에서는 매우 무례하며 좋은 이유가 있습니다. 다른 환경에서는 예상 할만한 이유가 있습니다.

다른 환경에서는 매우 무례하거나 매우 나쁜 이유로 예상됩니다.

고장난 빌드의 중요성과 검증 된 올바른 빌드의 중요성에 크게 좌우됩니다. 그리고 어느 정도까지는 수정이 올바른 수정이고 유일한 수정이라는 것이 얼마나 명백한가에 달려 있습니다.

첫째, '집으로 갔다'는 시대 착오이다. 프로그래머는 더 이상 집에 가지 않고 온라인 또는 오프라인 상태입니다. 핑하고 기다릴 수 있습니다.

더 심각한 것은 실제로 두 가지 부분이 있습니다. '코드 변경을 살펴 보는 것'은 괜찮습니다. 휴식이 옳은 일이 아닐 수도 있습니다. 누락 된 도서관에 대한 그의 판단이 틀렸다면?