민첩한 사례 : 코드 검토-검토 실패 또는 문제 제기?

2 주 스프린트가 끝나면 작업에 코드 검토가 있습니다. 검토에서 우리는 작동하고 읽을 수있는 기능을 발견하지만 읽을 수는 있지만 꽤 길고 코드 냄새가 약간 있습니다. 쉬운 리팩터링 작업.

그렇지 않으면 작업이 완료의 정의에 적합합니다.

우리는 두 가지 선택이 있습니다.

• 이 스프린트에서 티켓이 닫히지 않도록 코드 검토에 실패하고 티켓을 전달할 수 없기 때문에 사기에 약간의 영향을 미칩니다.
• 리 팩터는 작은 작업으로, 다음 스프린트에서 (또는 시작하기 전에) 작은 반점 이야기로 끝날 것입니다.

내 질문은 : 리뷰 대신 티켓을 올리는 데 내재 된 문제 나 고려 사항이 있습니까?

내가 찾을 수 있고 상세 코드 리뷰를 100 % 또는 전혀 읽지 않은 리소스는 일반적으로 현실적이지 않다는 것을 알았습니다.

리뷰 대신 티켓을 올리는 데 내재 된 문제 나 고려 사항이 있습니까?

본질적으로 아닙니다. 예를 들어, 현재 변화의 구현은 이미 있었지만 지금까지 알려지지 않았던 문제를 발굴했을 수 있습니다. 실제로 설명 된 작업과 관련이없는 것으로 인해 티켓을 실패하면 불공정하게됩니다.

검토에서 우리는 기능을 발견

그러나 여기의 기능이 현재 변경으로 추가 된 것으로 가정합니다. 이 경우 코드가 냄새 테스트를 통과하지 못하여 티켓이 실패해야합니다.

이미 그린 위치가 아니라면 어디를 그리겠습니까? 이 코드가 현재 형태로 코드베이스에 머무르기에 충분하다고 생각하지 않습니다. 그렇다면 왜 티켓을 패스하는 것을 고려 하시겠습니까?

이 스프린트에서 티켓이 닫히지 않도록 코드 검토에 실패하고 티켓을 전달할 수 없기 때문에 사기에 약간의 영향을 미칩니다.

이 티켓을 코드베이스의 품질에 이익이 아니라 팀 사기에 도움이 될 수 있도록 패스하려고한다고 간접적으로 주장하는 것처럼 보입니다.

이 경우 우선 순위가 섞여 있습니다. 깨끗한 코드의 표준은 단순히 팀을 더 행복하게 만들기 때문에 변경해서는 안됩니다. 코드의 정확성과 청결은 팀의 분위기에 달려 있지 않습니다.

리 팩터는 작은 작업으로, 다음 스프린트에서 (또는 시작하기 전에) 작은 반점 이야기로 끝날 것입니다.

원래 티켓의 구현으로 인해 코드 냄새가 나면 원래 티켓에서 해결해야합니다. 코드 냄새가 원래 티켓에 직접 기인 할 수없는 경우에만 새 티켓을 만들어야합니다 (예 : "낙타의 등을 부러 뜨린 밀짚"시나리오).

내가 찾을 수 있고 상세 코드 리뷰를 100 % 또는 전혀 읽지 않은 리소스는 일반적으로 현실적이지 않다는 것을 알았습니다.

합격 / 불합격은 본질적으로 이진 상태 이며 본질적으로 전부 또는 아무것도 아닙니다.

당신이 여기서 말하는 것은 코드 리뷰가 완벽한 코드 를 요구 하거나 그렇지 않으면 실패한다고 해석하는 것 이상 이 아니라고 생각합니다.

이 코드는 성가신 것이 아니며, 팀 / 회사에서 사용하는 합리적인 청결 표준을 준수해야합니다. 이 표준을 준수하는 것은 이진 선택입니다. 준수 (통과) 또는 실패 (실패)입니다.

문제에 대한 설명을 바탕으로 이것이 예상 코드 표준을 준수한다고 생각하지 않기 때문에 팀 사기와 같은 불가피한 이유로 전달해서는 안됩니다.

그렇지 않으면 작업이 완료의 정의에 적합합니다.

"작업 완료"가 코드 품질에 대한 최고의 벤치 마크라면, 깨끗한 코드와 좋은 연습의 원칙을 발명 할 필요가 없었을 것입니다. 컴파일러와 단위 테스트는 이미 자동화 된 검토 프로세스입니다. 코드 검토 나 스타일 인수가 필요하지 않습니다.

2 주 스프린트와 작업의 끝에 코드 검토가 있습니다 [...] 쉬운 리 팩터 작업.

스프린트 끝에 왜 팝업이 나타 납니까? 코드 검토는 코드가 완료되었다고 생각되 자마자 (또는 이전에) 수행 되어야합니다. 당신은 당신이 끝내는 각 이야기로 완료의 정의를 확인해야합니다.

데모 / 스프린트 검토 직전에 스토리를 마무리하여 "작은"작업을 수행 할 수없는 경우 작업을 더 잘 추정해야합니다. 네, 그 이야기는 끝나지 않았습니다. 코드 검토 때문이 아니라 코드 검토의 변경 사항을 통합하지 않았기 때문입니다. "올바른 프로그래밍을하면 제대로 작동합니까?" 그것이 작동하는 방식이 아닙니다. 테스트는 오류를 발견하고 코드 검토는 변경해야 할 사항을 찾습니다. 그렇지 않으면 시간이 많이 걸릴 것입니다.

요약하자면, DoD는 이진입니다. 합격 또는 불합격 코드 검토는 이진이 아니며 진행중인 작업과 비슷해야합니다. 당신은 실패 할 수 없습니다 . 그것은 과정이며 결국 끝났습니다. 그러나 제대로 계획하지 않으면, 그 "완료"단계에 도달하지 못하고 스프린트 종료시 "완료"영역에 갇혀있을 것입니다. 그것은 사기에는 좋지 않지만 계획에서 그 점을 고려해야합니다.

단순 : 변경 사항을 검토합니다 . 그렇지 않으면 프로그램 상태를 검토하지 않습니다. 3,000 줄 함수에서 버그를 수정하면 변경 사항으로 버그가 수정되는지 확인한 것입니다. 그리고 내 변경 사항으로 버그가 해결되면 변경 사항을 수락합니다.

함수가 너무 길다고 생각되면, 변경을 수락 한 후 변경 요청을 작성하여 함수를 더 짧게 만들거나 분할하면 해당 변경 요청의 중요성에 따라 우선 순위를 지정할 수 있습니다. 팀에 더 중요한 일이 있다고 결정되면 나중에 처리됩니다.

코드 검토 중에 개발 우선 순위를 결정할 수 있다면 어리석은 일이며 그러한 이유로 내 변경을 거부하면 개발 우선 순위를 결정하는 시도가 될 것입니다.

요약하면, 코드 변경을 수락하고 변경 사항을 검토 할 때 확인한 내용에 따라 즉시 티켓을 올리는 것이 절대적으로 허용됩니다. 경우에 따라 변경 자체로 인해 문제가 발생한 경우에도이 작업을 수행 할 수 있습니다. 문제를 해결하는 것보다 지금 변경하는 것이 더 중요한 경우 . 예를 들어 변경 사항을 기다리는 다른 사람이 차단 된 경우 코드를 개선 할 수있는 동안 차단을 해제하려고합니다.

이 스프린트에서 티켓이 닫히지 않도록 코드 검토에 실패하고 티켓을 전달할 수 없기 때문에 사기에 약간의 영향을 미칩니다.

이것은 문제인 것 같습니다.
이론적으로는해야 할 일을 알고 있지만 마감일이 가까워서해야 할 일을하고 싶지 않습니다.

답은 간단합니다. 스프린트 첫날에 코드 검토를 위해 동일한 코드를 가지고 있다면 무엇이든 할 수 있습니다. 그것이 받아 들여질 수 있다면 지금해야합니다. 그렇지 않다면 지금은 그렇지 않습니다.

프로세스의 큰 부분은 무슨 일 이 있었는지 결정하고 총을 고집하는 것입니다. 또한 과도하게 커밋하지 않고 동료 검토를 제 시간에 완료하여 테스트를 통해 기능이 완벽하게 완료되었는지 확인할 수도 있습니다.

코드 검토 문제와 관련하여 처리 할 수있는 몇 가지 방법이 있으며 올바른 선택은 몇 가지 요소에 따라 다릅니다.

• 당신은 할 수 있습니다 자신까지 코드를 청소 하고 사람이 당신이 무슨 짓을했는지 알려 주시기 바랍니다. 멘토링 기회를 제공하지만 몇 분 안에 수행 할 수있는 매우 간단한 작업이어야합니다.
• 당신은 무엇이 잘못되었는지에 대한 의견을 가지고 반발 할 수 있습니다 . 오류 처리가 제대로 수행되지 않거나 개발자가 동일한 실수를 계속 반복하면 이것이 보증 될 수 있습니다.
• 티켓을 만들고 기술 부채가 발생할 수 있습니다 . 티켓은 나중에 지불하도록하기 위해 존재합니다. 시간이 오래 걸리고 변경 사항을 검토하는 과정에서 변경과 직접적인 관련이없는 더 큰 문제가 발생할 수 있습니다.

결론은 작업을 마쳤을 때 작업을 완료해야한다는 것입니다. 개발자가 작업 한 것보다 큰 문제가 있으면 플래그를 올리고 계속 진행하십시오. 그러나 스프린트가 끝나기 몇 시간 전에 위치에 있으면 안되며 지금은 동료 검토를 받고 있습니다. 리소스를 과도하게 커밋하거나 동료 리뷰를 미루는 것 같은 냄새가납니다. (프로세스 냄새).

코드 검토 문제의 우선 순위를 결정하는 데 내재 된 문제는 없지만 팀으로서 동의해야하는 주요 문제는 다음과 같습니다.

1. 코드 검토의 목적은 무엇입니까?
2. 코드 검토 결과는 작업 항목에 대한 완료 정의와 어떤 관련이 있습니까?
3. 코드 검토가 게이팅 테스트로 적용되는 경우 어떤 문제가 '차단제'로 간주됩니까?

이 모든 것은 팀이 Done의 정의로 동의 한 것에 달려 있습니다. 작업 문제에 대해 0 이슈로 코드 검토를 통과 한 것이 정의 된 경우이 요구 사항을 충족하지 않는 항목을 닫을 수 없습니다.

단위 테스트 중 단위 테스트가 실패한 것과 같습니다. 단위 테스트를 통과하는 것이 완료가되어야한다면 버그를 수정하고 단위 테스트를 무시하지 마십시오.

팀이 코드 검토를 완료로 정의하는 데 동의하지 않은 경우 코드 검토는 작업 항목의 게이팅 수락 테스트가 아닙니다. 이들은 필요한 추가 작업을 찾기 위해 백 로그 프로세스의 일부인 팀 활동입니다. 이 경우 발견 한 모든 문제는 원래 작업 항목의 요구 사항과 관련이 없으며 팀이 우선 순위를 지정할 새로운 작업 항목입니다.

예를 들어, 팀이 변수 이름 "myObkect"를 보는 것을 싫어하더라도 팀이 일부 변수 이름의 오타 수정을 우선 순위 해제하는 것이 허용 될 수 있습니다.

여기에서 투표권이 높은 답변은 매우 좋습니다. 이것은 리팩토링 각도를 해결합니다.

대부분의 경우 리팩토링 작업의 대부분은 기존 코드를 이해하고 있습니다. 그 후에 변경하는 것은 일반적으로 두 가지 이유 중 하나 때문에 작업의 작은 부분입니다.

1. 코드를 더 명확하고 간결하게 만들면 필요한 변경이 명백합니다. 더 깔끔해 보이는 변경 사항을 시도하고 실제로 작동했는지 또는 더 복잡한 코드에서 미묘한 부분을 놓친 경우를 확인하여 코드에 대한 이해를 얻었습니다.

2. 새로운 기능을보다 쉽게 ​​구축하는 데 필요한 특정 디자인이나 구조를 이미 염두에 두었습니다. 이 경우, 그 디자인을 개발하는 작업은 그 필요성을 제기 한 이야기의 일부였습니다. 해당 설계에 도달하기 위해 리팩토링을 수행해야하는 것은 독립적입니다.

기존 코드를 배우고 이해하는 것은 비 영구적 인 이익을 위해 상당한 양의 작업입니다 (지금부터 누군가가 코드를 계속 읽거나 사용하지 않으면 코드에 대해 많은 것을 잊었을 가능성이 있음). 문제를 일으키는 코드 영역이나 가까운 장래에 변경하려는 코드 영역을 제외하고는이 작업을 수행하는 것이 합리적이지 않습니다. 결과적으로 이것은 리팩토링의 주요 작업이므로 현재 문제를 일으키거나 가까운 시일 내에 코드를 변경할 계획이 아니라면 코드에서 리팩토링을 수행해서는 안됩니다.

그러나 한 가지 예외가 있습니다. 누군가가 현재 시간이 지남에 따라 누출 될 코드에 대해 잘 이해하고 있다면, 그 이해를 사용하여 나중에 코드를 더 명확하고 더 빨리 이해하도록하는 것이 좋은 투자가 될 수 있습니다. 바로 이야기 개발을 마친 누군가가 처한 상황입니다.

리 팩터는 작은 작업으로, 다음 스프린트에서 (또는 시작하기 전에) 작은 반점 이야기로 끝날 것입니다.

이 경우 리팩토링에 대한 별도의 이야기를 만드는 것은 여러 가지 측면에서 경고 신호입니다.

1. 리팩토링을 코딩의 일부로 생각하지 않고 별도의 작업으로 생각하면 압력이 가해질 수 있습니다.

2. 다음에 누군가와 함께 작업해야 할 때 이해하는 데 도움이되는 코드를 개발 중이므로 스토리가 더 오래 걸립니다.

3. 많은 이익을 얻지 못하는 시간과 에너지 리팩토링을 낭비하고있을 수 있습니다. (나중에 변경이 발생하면 누군가는 여전히 코드를 다시 이해해야합니다. 리팩토링 작업과 더 효율적으로 결합됩니다. 나중에 변경이 발생하지 않으면 리팩토링은 아무 것도 제공하지 않았습니다. 미학적 목적을 제외하고는 전혀 목적이 없습니다.)

따라서 여기에 대한 대답은 프로세스에서 무언가 실패했음을 분명히하기 위해 항목을 실패하는 것입니다 (이 경우 개발자 또는 팀이 검토를 위해 시간을 할당하지 않고 검토에서 나온 변경 사항을 구현하지 않아야 함)하고 개발자가 즉시 작업을 계속하도록합니다 품목에.

다음 반복에 대한 추정으로 이동하면 검토를 통과하고 다음 반복에 추가하지만 이전 반복의 추정을 유지하기 위해 남은 작업량에 따라 기존 스토리 를 다시 추정 하십시오 . 다음 반복이 끝날 때 스토리가 완료되면 기록 된 총 작업량을 첫 번째 및 두 번째 추정값의 합계로 설정하여 실제로 예상 된 작업량이 얼마나되는지 알 수 있습니다. 이를 통해 현재 프로세스 상태에서 유사한 스토리를보다 정확하게 추정 할 수 있습니다. (즉, 당신의 명백한 과소 평가가 다시는 일어나지 않을 것이라고 가정하지 말고, 적은 일을하면서도 비슷한 이야기를 성공적으로 마칠 때까지 다시 일어날 것이라고 가정하십시오.)

코드 검토 "실패"라는 개념에 대한 답변과 의견에 대한 답변이 부족하다는 사실에 놀랐습니다. 개인적으로 친숙한 개념이 아니기 때문입니다. 나는 그 개념을 사용하거나 우리 팀의 어느 누구도 그 용어를 사용하는 데 익숙하지 않을 것입니다.

귀하의 질문은 명시 적으로 "민첩한 관행"을 요구하므로 민첩한 선언문 (강조 광산)을 다시 살펴 보겠습니다.

우리는 소프트웨어를 수행하고 다른 사람들이 소프트웨어를 개발하도록함으로써 소프트웨어를 개발하는 더 좋은 방법을 발견하고 있습니다. 이 사업을 통해 우리는 가치를 얻게되었습니다.

• 프로세스 및 도구에 대한 개인 및 상호 작용
• 포괄적 인 문서에 대한 작업 소프트웨어
• 계약 협상을 통한 고객 협업
• 계획에 따라 변경 에 응답

즉, 오른쪽에있는 항목에는 가치가 있지만 왼쪽에있는 항목은 더 중요하게 생각합니다.

팀과 이야기하십시오. 문제의 코드를 토론하십시오. 비용과 이점을 평가하고 응집력있는 전문가 그룹으로서이 코드를 지금, 나중에 리팩토링할지, 아니면 리팩토링할지 결정합니다.

협업을 시작하십시오. 코드 검토 실패를 중지하십시오.

리뷰에서 우리는 작동하고 읽을 수있는 기능을 발견하지만 꽤 길며 코드 냄새가 약간 있습니다 ...

리뷰 뒷면에서 티켓을 올리는 데 실패하지 않고 내재 된 문제 나 고려 사항이 있습니까?

(팀 의견으로는) 문제 없습니다. 코드가 티켓에 명시된 수락 기준을 충족한다고 가정합니다 (즉, 작동). 길이와 코드 냄새를 처리하기 위해 백 로그 항목을 작성하고 다른 티켓처럼 우선 순위를 정하십시오. 실제로 작은 경우 다음 스프린트에 우선 순위를 매기십시오.

우리가 말한 것 중 하나는 "지연된 완전성보다 점진적인 개선을 선택하십시오"입니다.

우리는 매우 유동적 인 프로세스를 가지고 있으며 개발 및 테스트를 통해 만들지 만 내부 이해 관계자 검토를 지나치지 않는 상당히 많은 수의 '개념 증명'기능 (스프린트 당 1 또는 2)을 구축합니다. ?), 알파 또는 베타 ... 일부는 생존하지만 일부는 그렇지 않습니다.

현재 프로젝트에서, 우리가 특정 기능을 몇 번이나 구축했는지, 이해 관계자의 손에 넣었는지, 그리고 스프린트 (Sprint) 또는 두 번 후에 제품 방향이 변경되었거나 요구 사항이 발생하여 완전히 제거했습니다. 기능이 어떻게 구현되어야하는지에 대한 완전한 리 캐스트. 삭제 된 피처에 대한 나머지 '정제'작업 또는 새로운 요구 사항에 맞지 않는 백 로그 그루밍의 일부가 삭제됩니다.

내 의견으로는이 문제를 보는 두 가지 방법이 있습니다.

1. 학문적 인 방법
2. 실제 방법

학문적으로 말하면, 대부분의 코드 검토 프로세스는 코드 품질 표준이 충족되지 않을 때 PBI (제품 백 로그 항목)의 배포에 실패합니다.

그러나 현실 세계의 어느 누구도 (다수의 이유로) T에 대해 민첩성을 따르지 않으며, 산업마다 요구 사항이 다릅니다. 따라서 현재 코드를 수정하거나 기술 부채 (새로운 PBI를 생성 할 가능성이 높음)는 사례별로 결정해야합니다. 스프린트 또는 릴리스를 손상 시키거나 불합리한 양의 위험을 초래할 경우 비즈니스 이해 관계자가 결정에 참여해야합니다.

둘 다 . 코드 검토에 실패하면 작업이 완료되지 않은 것입니다. 그러나 개인적인 의견으로는 코드 검토에 실패 할 수 없습니다. 코드는 통과합니다. 다음 작업으로 넘어갑니다.

쉬운 호출이어야하며 코드 검토에 대한 충분한 서면 규칙이 명확하지 않다는 것을 암시하지 않습니다.

1. "기능이 꽤 깁니다". 적어 두십시오 : 함수는 X 줄보다 작아야합니다 ( 함수 길이에 대한 규칙이 좋은 것이라고 제안 하지는 않습니다 ).

2. "코드 냄새가 있습니다." 쓰기 : 공용 함수는 기능 및 성능에 대한 단위 테스트를 가져야하며 CPU 및 메모리 사용량은 x 및 y 제한 미만이어야합니다.

코드 검토를 통과하기위한 규칙을 수량화 할 수없는 경우 기본적으로 '좋지 않은 코드'에 해당하는 사례가 표시됩니다.

'좋아하지 않은 코드'에 실패해야합니까? 나는 아니오라고 말할 것입니다. 코드가 아닌 측면에 따라 자연스럽게 통과 / 실패하기 시작합니다. 사람을 좋아합니까? 그들은 자신의 사건에 대해 강력하게 주장합니까, 아니면 그냥 말한대로합니까? 그들은 당신을 검토 할 때 코드를 전달합니까?

또한 추정 프로세스에 정량화 할 수없는 단계를 추가합니다. 프로그래밍 방식에 따라 작업을 추정하지만 결국에는 코딩 스타일을 변경해야합니다.

얼마나 오래 걸립니까? 동일한 검토자가 후속 코드 검토를 수행하고 첫 번째 검토 자와 동의하거나 추가 변경 사항을 찾습니까? 변경 사항에 동의하지 않고 다른 의견을 찾거나 사례를 주장하는 동안 변경을 중단하면 어떻게 되나요?

작업을 빠르게 수행하려면 가능한 한 구체적으로 작성해야합니다. 막연한 품질 게이트를 추가해도 생산성에 도움이되지 않습니다.

다시 : 규칙을 적어 둘 수 없습니다!

그렇게 어렵지는 않습니다. 당신은 정말로 "나는 '좋은'코드로 의미하는 것을 표현할 수 없다"를 의미한다 . 당신이 그것을 인식하면, 당신은 누군가의 작업이 처음부터 끝나지 않았다고 말하기 시작하면 분명히 HR 문제라는 것을 알 수 있지만 그 이유를 말할 수는 없습니다.

규칙을 적고 코드를 '좋은'것으로 만드는 것에 대해 맥주에 대해 토론하십시오.