그의 작업에서 최첨단 사례를 지속적으로 무시하는 개발자와의 거래

팀의 개발자 중 한 명과 관련하여 흥미롭고 상당히 일반적인 문제가 있습니다. 이 사람은 훌륭한 개발자이며 빠르고 생산적으로 일하며 상당히 좋은 품질의 코드를 생성합니다. 좋은 엔지니어. 그러나 그에게는 문제가 있습니다. 매우 자주 코드에서 에지 사례를 해결하지 못합니다.

우리는 그에 대해 여러 번 이야기했고 그는 노력하고 있지만 나는 단지 그렇게 생각하지 않는다고 생각합니다. 결국 QA는 코드에서 많은 문제를 발견하고 다시 개발을 위해 다시 되돌려 서 최종 기한을 놓치고 팀의 모든 사람들이 불행하게 만듭니다.

나는 그와 함께 무엇을해야하며 어떻게이 문제를 극복 할 수 있는지 모른다. 아마도 더 많은 경험을 가진 사람이 조언 할 수 있습니까?

코드에 대한 자동화 된 단위 테스트를 작성하도록 요구하십시오. 단위 테스트를 작성하면 가장 어려운 경우를 생각하게됩니다.

일부 세부 사항 :

1. 그가 따로 느끼지 않도록하려면 팀 전체를 대상으로해야합니다. 모든 사람이 새로운 코드 나 수정 한 코드에 대해 자동화 된 단위 테스트를 작성해야합니다.
2. 단위 테스트 이름은 테스트중인 경우에 대한 설명이 필요합니다.
3. 코드 검토에서 자동화 된 단위 테스트를 높은 수준으로 다루십시오. 검토 자들에게 누락 된 테스트 사례 (즉, 그가 자주 놓치는 에지 사례)를 찾도록하십시오. 팀에서 누락 된 최신 사례에 대해 어느 정도의 피드백을받은 후 검토 전에 해당 사례를 고려하는 방법을 배우게 될 것입니다.
4. 전체 팀에 대해이 규칙을 시행하십시오. QA에서 버그를 발견하면 개발자는 자동화 된 테스트를 통해 오류를 확인한 다음 오류를 수정했음을 증명해야합니다. (그들이 다른 일을하기 전에)

예를 들어 체크리스트를 제공하십시오.

• 널 입력
• 매우 넓은 범위의 끝에서 입력
• 매우 작은 범위의 끝에서 입력
• 조합
• 가정 된 불변량을 위반하는 입력 (예 : x = y 인 경우)

품질 관리 담당자는 체크리스트 작성을 도울 수 있습니다.

이것뿐만 아니라 모든 개발자에게 점검표를 제공하십시오.

좋은 엔지니어.

괜찮아.

그러나 그에게는 문제가 있습니다. 매우 자주 코드에서 에지 사례를 해결하지 못합니다.

우수한 엔지니어가 공유하지 않는 품질입니다.

엣지 케이스를 관찰하는 것은 사람들에게 존재하거나 존재하지 않는 특성입니다. 엔지니어 나 프로그래머와는 아무런 관련이 없습니다. 이 특성의 발달은 문화적 배경, 생활 환경, 어린 시절 사건 및 생활 경험에 의해 영향을받습니다. 그런 다음 태도는 단순히 개인이하는 모든 일에 적용됩니다.

당신이 필요로하는 것은 당신의 남자 가이 특정 감각이 발달하지 않은 유형인지 (아마 아직은) 아닌지 알아내는 것입니다. 그는 단지 어떤 이유로 든 신경 쓰지 않을 가능성이 큽니다. 그가 자신의 직업에 만족하든 전체 상황을 분석해야합니다. 그렇지 않다면 아마도 그를 먼저 도울 무언가를해야 할 것입니다.

그가 일을 잘하지만 아직 최첨단 사례의 위험을 경험하지 않았다면 그를 교육하기 시작할 수 있습니다. 그가 진지하게 받아들이면 시간이 지남에 따라 길을 바꿀 수 있습니다. 나는 이것에 회의적이지만 여전히 시도해 볼 수 있습니다.

그러나 그가 최우선 사례에 좋지 않은 유형의 사람으로 판명되면 팀에서 그를 제거하는 것 외에는 아무것도 남지 않을 수 있습니다. 이 특성은 실제 프로그래밍에 필수적입니다. 안타깝게도 위대한 사람조차도 좋은 일을하지 못할 것입니다.

프로세스 초기에 코드 검토 또는 디자인 검토를 수행 할 수 있습니까?

시험 우선 프로그램을 가르치십시오. 그와 페어링하십시오. 테스트 사례를 작성하고 테스트를 통과하는 코드를 작성합니다.

QA가 기능 개발에 일찍 참여하게되면 처음부터 끝까지 다룰 수있는 최첨단 사례를 제공 할 수 있습니까? 일부는 개발자가 모든 것을 다룰 것으로 기대하지 않는 것으로 볼 수도 있지만, 테스터가 처음에 잘 잡을 수있는 경계 사례를 놓치려는 경우이 문제를 해결하는 방법 일 수 있습니다.

내가 가진 또 다른 아이디어는 그가이 문제를 어떻게 보느냐입니다. 그는이 패턴에 대해 정말로 짜증나고 진드기입니까, 아니면 이것을 정상으로 보았을뿐만 아니라 해결에 대해 걱정할만한 것이 아닌가? 이것이 많은 신뢰를 필요로하고 그의 관점에 대해 개방적이 되려면 여기에 그의 관점에서 사물을 볼 수 있다면 어느 정도의 공감이 있다고 생각합니다.

무한한 수의 엣지 케이스가 있으며,이를 모두 커버하는 것은 불가능합니다. 누군가가하면 어떻게 #define TRUE FALSE되나요? 그것은 엣지 케이스를 추가합니다, 당신도 그것들을 확인 하시겠습니까?

또한 개인 클래스 또는 내부 함수의 모든 기능을 바보로 생각하지 않습니다.

매우 견고하고 안정적인 코드에 대해 선택한 접근법은 다음과 같습니다.

if(conditions_met)
{
DoStuff();
}
else
{
CrashAppAndDumpMemory();
}

이렇게하면 QA에서 견고한 응용 프로그램 덤프를 얻을 수 있으며 출시 될 때까지 응용 프로그램은 견고하고 안전합니다.

오류를 해결하는 것은 좋지 않습니다. 파일 핸들이 null이고 null을 반환하는 경우 함수를 저장할 수 있지만 대부분의 경우 어딘가에 디자인 오류가 있으며 앱 충돌이 원인을 찾도록하는 더 좋은 방법입니다. 대부분의 엣지 케이스는 문제를 숨겨서 오류를 숨 깁니다. 충돌은 제품에 대한 일부 가정이 잘못되었음을 나타내며 충돌을 일으킨 논리를 수정해야합니다.

그것이 에지 케이스라면 고려되어야합니까? 엣지 케이스가 중요한 경우 엣지 케이스는 요구 사항 / 기능 / 사용자 스토리에 공급되어야합니다.

에지 케이스가 작업의 일부로 간주되고 장치를 제자리에 배치해야하는 경우, 작업 케이스의 일부 여야하며 정의에 따라 에지 케이스 처리 메커니즘이 완료 될 때까지 작업 항목이 완료되지 않습니다. 그 자리에.

이를 통해 팀 리더는 작업 후 토론 중에 작업이 완료된 후 점검 할 사항을 제공하고 개발자가 작업을 완료 할 때 점검 할 사항을 제공합니다.

최첨단 사례를 잡는 것이 QA가 존재하는 이유입니다. 프로그래머는 작업을 적시에 추진해야 할 책임이 있습니다. 엣지 케이스를 찾기 위해 모든 시간을 소비하는 것은 매우 비효율적입니다. 합리적으로 빠른 반복주기가 있다면 전혀 문제가되지 않습니다. 엣지 케이스는 무한대에 가깝습니다. "핵심"사례에 문제가 있다면 조금 걱정이 될 것입니다. 개발자가 개발 전문가 인 것처럼 테스터는 테스트 전문가 여야합니다. 테스터가 문제를 발견하면 다시 개발 부서로 보냅니다. 개발자가 문제를 해결합니다. 문제 해결됨. 개발자가 모든 에지 사례를 추적하는 데 걸리는 시간은 반복 테스트주기보다 훨씬 오래 걸립니다. 또한 테스트에 관해 이야기 할 때 화이트 박스 단위 테스트를 의미하는 것이 아니라 블랙 박스 테스트를 엄격히 의미합니다.

테스트 중심 개발이 구식이 될 것이라고 생각하는 경우 중 하나입니다. 에지 케이스 및 코드를 손상시킬 수있는 모든 측면에서 생각하는 데 도움이되기 때문입니다.