주니어 프로그래머가 테스트를 작성하게하는 방법? [닫은]

우리에게는 충분한 테스트를 작성하지 않는 주니어 프로그래머가 있습니다.
나는 2 시간마다 "시험을 봤니?"라고 잔소리를해야합니다.
우리는 시도했습니다 :

• 디자인이 더 단순 해짐을 보여줌
• 그것을 보여주는 것은 결함을 예방합니다
• 나쁜 프로그래머 만이하지 않는다고 자아로 만들기
• 이번 주말에는 그의 코드에 NULL 참조가 있고 테스트하지 않았기 때문에 2 명의 팀원이 출근해야했습니다.

내 작업에는 최고 품질의 안정적인 코드가 필요하며 일반적으로 모든 사람이 '알고'테스트를 진행할 필요가 없습니다. 우리는 그가 테스트를 작성하도록 할 수 있다는 것을 알고 있지만 유용한 테스트는 당신이 그것에 들어갈 때 작성된 것입니다.

더 많은 동기를 알고 있습니까?

이것은 가장 어려운 일 중 하나입니다 . 사람들 이 그것을 얻도록 .

때때로 주니어 레벨 프로그래머가 '그것을 얻도록'도와주고 선배들로부터 올바른 기술을 배우는 가장 좋은 방법 중 하나는 약간의 페어 프로그래밍을하는 것입니다.

다음을 시도해보십시오 : 다가오는 프로젝트에서 주니어 남자를 자신 또는 다른 선임 프로그래머와 짝을 이루십시오. 그들은 차례로 "운전"(키보드에 타이핑하는 것)과 "코칭"(운전자의 어깨 너머로보고 제안, 실수 등을 지적)을하면서 함께 일해야합니다. 자원 낭비처럼 보일 수 있지만 다음을 찾을 수 있습니다.

1. 이 사람들이 함께 코드를 빠르고 고품질로 만들 수 있습니다.
2. 만약 당신의 후배가 그를 올바른 길로 안내하는 시니어 남자와 함께 "그것을 얻을"수있을만큼 충분히 배운다면 (예 : "좋아, 이제 계속하기 전에이 함수에 대한 테스트를 작성 해보자.") 당신이 자원할만한 가치가있을 것이다. 그것을 약속하십시오.

그룹의 누군가가 단위 테스트 101을 가 Kate Rhodes 프레젠테이션을하도록 할 수도 있습니다. 잘 전달된다면 사람들이 테스트에 대해 흥미를 갖게하는 좋은 방법이라고 생각합니다.

당신이 할 수있는 또 다른 일은 당신의 Jr. Devs가 볼링 게임 Kata 를 연습하게하여 그들이 Test Driven Development를 배우는 데 도움이 될 것입니다. Java로되어 있지만 모든 언어에 쉽게 적용 할 수 있습니다.

모든 커밋 전에 코드를 검토하고 (1 분 동안 "이 변수 이름을 변경했습니다"라도) 코드 검토의 일부로 모든 단위 테스트를 검토합니다.

테스트가 완료 될 때까지 커밋에서 사인 오프하지 마십시오.

(또한-그의 작업이 테스트되지 않은 경우-처음에 프로덕션 빌드에 있었던 이유는 무엇입니까? 테스트되지 않은 경우 들여 보내지 마십시오. 그러면 주말에 작업 할 필요가 없습니다.)

나 자신을 위해 내가 발견하고 수정 한 모든 버그는 테스트로 표현되어야한다고 주장하기 시작했습니다.

1. "흠, 맞지 않습니다 ..."
2. 가능한 문제 찾기
3. 테스트를 작성하고 코드가 실패했음을 보여줍니다.
4. 문제를 해결
5. 새 코드가 통과했음을 보여줍니다.
6. 원래 문제가 지속되면 반복

나는 물건을 치는 동안에도 이것을 시도하고, 이미 부분적인 테스트 스위트가있는 상태에서만 거의 같은 시간에 완료된다.

(저는 상용 프로그래밍 환경에 살지 않으며 종종 특정 프로젝트를 수행하는 유일한 코더입니다.)

내가 마르코라는 모의 프로그래머라고 상상해보세요. 내가 얼마 전에 학교를 졸업했고 실제로 시험을 치를 필요가 없었다고 상상해보십시오. 내가 이것을 강제하거나 요구하지 않는 회사에서 일한다고 상상해보십시오. 확인? 좋은! 이제 회사가 테스트를 사용하는 것으로 전환하고 있다고 상상해보십시오. 지금까지 언급 한 항목에 대해 조사를하지 않은 듯 다소 은밀한 반응을 보일 것입니다.

제작자와 함께 시작해 보겠습니다.

디자인이 더 단순 해짐을 보여줍니다.

어떻게 더 많이 쓰고 더 간단하게 만들 수 있습니까? 나는 이제 더 많은 케이스를받는 등 계속 감시해야 할 것입니다. 이것은 당신이 저에게 물어 보면 더 복잡해집니다. 확실한 세부 사항을주세요.

그것을 보여주는 것은 결함을 예방합니다.

알아요. 이것이 그들이 테스트라고 불리는 이유입니다. 내 코드는 훌륭하고 문제가 있는지 확인했기 때문에 해당 테스트가 도움이 될 곳을 알 수 없습니다.

나쁜 프로그래머 만이하지 않는다는 자존심으로 만드는 것.

오, 당신은 내가 많이 사용되는 테스트를하지 않기 때문에 내가 나쁜 프로그래머라고 생각합니다. 나는 당신을 모욕하고 긍정적으로 짜증이납니다. 나는 말보다는 도움과 지원을 받고 싶습니다.

@ Justin Standard : 새로운 propect를 시작할 때 주니어 남자를 자신이나 다른 선임 프로그래머와 짝을 지어줍니다.

오, 이건 너무 중요해서 제가 일이 어떻게 진행되는지 확인하고 일이 어떻게 진행되는지에 대한 도움을받을 수 있도록 리소스가 소비 될 것입니다. 이것은 도움이되며 더 많은 작업을 시작할 수 있습니다.

@ Justin Standard : Kate Rhodes의 Unit Testing 101 프레젠테이션을 읽어 보세요.

아, 흥미로운 프레젠테이션이었고 테스트에 대해 생각하게했습니다. 그것은 내가 고려해야 할 몇 가지 요점을 망치고 내 견해를 약간 흔들었을 수도 있습니다.

더 매력적인 기사와 이것이 일을하는 올바른 방법이라고 생각하는 데 도움이되는 다른 도구를보고 싶습니다.

@ Dominic Cooney : 시간을내어 테스트 기술을 공유하세요.

Ahh, 이것은 기술에 관한 한 나에게 기대되는 것을 이해하는 데 도움이되며 지식 가방에 더 많은 항목을 넣어 다시 사용할 수 있습니다.

@ Dominic Cooney : 질문, 예제 및 책에 답변합니다.

질문에 답할 수있는 사람 (사람)이 있으면 도움이되며, 시도 할 가능성이 더 높아질 수 있습니다. 좋은 예는 훌륭하며 목표로 삼고 참조 할만한 것을 제공합니다. 이와 직접 관련된 책은 훌륭한 참고 자료입니다.

@ Adam Hayle : 서프라이즈 리뷰.

내가 완전히 준비되지 않은 무언가를 뽑아 냈어. 불편하지만 최선을 다하겠습니다. 이 문제가 다시 발생하는 것을 이제 무서워하고 약간 걱정할 것입니다. 감사합니다. 그러나 공포 전술은 효과가 있었을 수도 있지만 비용이 있습니다. 그러나 다른 방법이 작동하지 않으면 이것이 필요한 푸시 일 수 있습니다.

@ Rytmis : 항목은 테스트 케이스가있을 때만 완료된 것으로 간주됩니다.

오, 흥미 롭군요. 지금 당장해야 할 일이 있습니다. 그렇지 않으면 아무것도 완료하지 않습니다. 이것은 의미가 있습니다.

@ jmorris : 제거 / 희생.

눈부심, 눈부심, 눈부심 -배울 수있는 기회가 있으며 지원과 도움을 받으면 팀에서 매우 중요하고 기능적인 부분이 될 수 있습니다. 이것은 지금 내 핸디캡 중 하나이지만 오래 걸리지 않을 것입니다. 그러나 내가 이해하지 못하면 나는 갈 것임을 이해합니다. 나는 그것을 얻을 것이라고 생각한다.

결국 우리 팀의 플레이 지원이이 모든 일에서 큰 역할을했습니다. 시간을내어 도움을주고 좋은 습관을들이도록 도와주는 것은 언제나 환영합니다. 그러면 나중에 좋은 지원 망이 있으면 좋을 것입니다. 나중에 누군가가 몇 번 와서 코드를 검토하여 리뷰 자체가 아니라 친근한 방문으로 모든 것이 어떻게 흐르는 지 확인하는 것이 항상 감사 할 것입니다.

추론, 준비, 교육, 후속 조치, 지원.

많은 프로그래머가 합리적 수준에서 테스트의 가치를보고 있음을 알았습니다. "예, 테스트해야한다는 것을 알고 있지만이 작업을 빨리 완료해야합니다."와 같은 말을 들어 본 적이 있다면 무슨 뜻인지 알 것입니다. 그러나 감정적 인 수준에서 그들은 실제 코드를 작성할 때만 무언가를한다고 느낍니다.

따라서 목표는 테스트가 실제로 어떤 것이 "완료"되었을 때를 측정 하는 유일한 방법 이라는 것을 이해하게하여 테스트 작성에 대한 본질적인 동기를 부여하는 것입니다.

그래도 그래야만하는 것보다 훨씬 더 어려울 것 같습니다. "정말 서두르고 있습니다. 나중에 다시 작성 / 리팩토링 한 다음 테스트를 추가하겠습니다."라는 많은 변명을 듣게 될 것입니다. 물론 후속 조치는 발생하지 않습니다. '다시 다음 주 바쁜처럼 .

내가 할 일은 다음과 같습니다.

• 처음으로 ... "우리는이 프로젝트를 공동으로 수행 할 것입니다. 테스트를 작성하고 여러분은 코드를 작성할 것입니다. 테스트를 작성하는 방법에주의를 기울이십시오. 그게 내가 당신에게 기대하는 것입니다. "

• 그 다음에는 ... "끝났어? 좋아! 먼저 개발을 주도하고있는 테스트를 살펴 보자. 테스트가 안 돼? 완료되면 알려 주시면 코드를 다시 예약하겠습니다. 테스트를 공식화하는 데 도움이 필요하면 알려주세요. 도와 드리겠습니다. "

그는 이미이 일을하고 있습니다. 정말. 그는 그것을 기록하지 않습니다. 확신이 없습니까? 그가 표준 개발주기를 거치는 것을 지켜보십시오.

• 코드 작성
• 컴파일
• 그것이 무엇을하는지보기 위해 실행
• 다음 코드 작성

3 단계는 테스트입니다. 그는 이미 테스트를하고 있으며 수동으로 만 수행합니다. "오늘의 코드가 여전히 작동하는지 내일 어떻게 알 수 있습니까?" 그는 다음과 같이 대답 할 것입니다. "이것은 코드의 양이 너무 적습니다!"

질문 : "다음 주에 대해?"

그가 답을 얻지 못했을 때, "어제 효과가 있었던 일이 변경되었을 때 프로그램이 어떻게 알려주시겠습니까?"라고 질문하십시오.

이것이 자동 단위 테스트의 전부입니다.

주니어 프로그래머로서 나는 여전히 테스트를 작성하는 습관을 가지려고 노력하고 있습니다. 분명히 새로운 습관을 고르는 것은 쉽지 않습니다. 그러나 이것이 저에게 효과가있는 이유를 생각하면서 코드 리뷰와 코칭 / 페어 프로그래밍에 대한 댓글을 +1해야합니다.

또한 테스트의 장기적인 목적을 강조 할 가치가 있습니다. 어제 효과가 있었던 것이 오늘, 다음 주, 다음 달에도 여전히 효과가 있는지 확인하는 것입니다. 나는 대답을 훑어 보면서 언급 된 것을 보지 못했기 때문에 그렇게 말합니다.

코드 리뷰를 할 때 (당신이 그렇게하기로 결정했다면) 당신의 어린 개발자가 그를 내려 놓는 것이 아니라 코드를 더 좋게 만드는 것임을 알고 있는지 확인하십시오 . 그렇게하면 그의 자신감이 손상 될 가능성이 적기 때문입니다. 그리고 그것은 중요합니다. 반면에 당신이 아는 것이 얼마나 적은지 아는 것입니다.

물론 나는 아무것도 모른다. 하지만 그 말이 도움이 되었기를 바랍니다.

편집 : [ 저스틴 표준 ]

자신을 내려 놓지 마십시오. 당신이 말해야 할 것은 거의 옳습니다.

코드 리뷰에 대한 당신의 요점 : 당신이 찾을 수있는 것은 주니어 개발자가 그 과정에서 배울뿐만 아니라 리뷰어들도 배울 것이라는 것입니다. 코드 검토의 모든 사람은 공동 작업 프로세스로 만들면 학습합니다.

당신이 넣어가있는 경우 솔직히, 그 그가 뭔가를 얻기에 많은 노력을 당신은 그가 단지 팀에 적합하지 않을 수 있습니다, 그리고 이동해야 할 수도 있다는 생각과 타협 할 수 있습니다. 자, 이것이 반드시 그를 해고하는 것은 아닙니다 ... 그것은 그의 기술이 더 적합한 회사를 찾는 것을 의미 할 수 있습니다. 하지만 다른 곳이 없다면 ... 무엇을해야할지 알고 있습니다.

나는 그가 상당히 신입생 (1 년 미만)이고 아마도 최근에 학교를 졸업했다고 가정하고 있는데,이 경우 그는 기업 환경에서 일이 어떻게 작동하는지에 익숙하지 않을 수 있습니다. 우리 대부분이 대학에서 벗어날 수있는 것과 같은 것.

이것이 사실이라면, 제가 찾은 한 가지는 "놀라운 신입 사원 검토"라는 것입니다. 전에 한 번도 해본 적이 없더라도 상관 없습니다 ... 그는 그것을 모를 것입니다. 그냥 앉아서 그에게 그의 공연을 살펴보고 실제 수치를 보여줄 것이라고 말하십시오 ... 정상적인 리뷰 시트를 가지고 (공식적인 리뷰 프로세스가 있습니까?) 원한다면 제목을 변경하십시오. 공무원에게 그가 서있는 곳을 보여줍니다. 테스트를하지 않는 것이 그의 성능 평가에 부정적인 영향을 미친다는 것을 매우 공식적인 환경에서 보여 주면 그가 "잔소리"하는 것과는 대조적으로 그는 요점을 알 수있을 것입니다. 당신은 그의 행동이 현명한 지 여부에 관계없이 실제로 그에게 영향을 미칠 것이라는 것을 보여줘야합니다.

공식적이지 않기 때문에이 일을하지 않기를 원할 수도 있습니다.하지만 그렇게 할 이유가 있다고 생각하며 그를 해고하고 새로운 사람을 모집하는 것보다 훨씬 저렴할 것입니다.

나는 주니어 프로그래머로서 이드가 당신의 주니어 개발자와 비슷한 상황에 처했을 때의 모습을 밝힐 것이라고 생각했습니다.

내가 처음 유니에서 나왔을 때 나는 그것이 현실 세계를 다룰 수있는 능력이 거의 없다는 것을 알았다. 네, JAVA의 기본과 철학 (묻지 마세요)을 알고 있었지만 그게 다였습니다. 내가 처음 직장을 구했을 때 최소한의 말을하는 것은 조금 힘들었습니다. 내가 아마도 가장 큰 카우보이 중 하나 였을 것입니다. 코멘트 / 테스트 / 문서없이 약간의 버그 수정 / 알고리즘을 해킹하여 문 밖으로 발송할 것입니다.

나는 종류의 감독하에 될 운이 충분했다 매우 환자 수석 프로그래머. 운 좋게도 그는 나와 함께 앉아 1 ~ 2 주 동안 해킹 된 togethor 코드를 살펴보기로 결정했습니다. 그는 내가 어디로 잘못 갔는지, c와 포인터의 더 세밀한 요점을 설명 할 것이다 (소년이 나를 혼란스럽게했다!). 우리는 약 일주일 만에 꽤 괜찮은 클래스 / 모듈을 작성했습니다. 내가 말할 수있는 모든 것은 수석 개발자가 올바른 길을 따라 나를 도울 시간을 투자하지 않았다면 아마도 나는 오래 지속되지 않았을 것입니다.

다행히 2 년이 지나면 동료 중 일부가 나를 평범한 프로그래머로 생각할 수도 있기를 바랍니다.

홈 포인트 가져 가기

1. 대부분의 대학은 학생들을 실제 세계에 대비하는 데 매우 열악합니다.
2. 짝을 이룬 프로그래밍이 정말 도움이되었습니다. 그것은 모든 사람에게 도움이 될 것이라고 말하는 것은 아니지만 나를 위해 일했습니다.

그것이 당신의 관심사라면 "최고 품질의 안정적인 코드"가 필요하지 않은 프로젝트에 할당하고 jr. 개발자가 실패합니다. 그들에게 '주말에 와서'버그를 수정하도록하십시오. 점심을 많이 먹고 소프트웨어 개발 관행에 대해 이야기하십시오 (강의가 아니라 토론). 시간이 지나면 할당 된 작업을 수행하기위한 모범 사례를 획득하고 개발할 것입니다.

아는 사람은 팀이 현재 사용하는 기술보다 더 나은 것을 생각 해낼 수도 있습니다.

주니어 프로그래머 나 누군가가 테스트에서 가치를 보지 못한다면, 그들이 그것을하도록하기가 어려울 것입니다.

나는 주니어 프로그래머가 버그를 고치기 위해 주말을 희생하도록 만들었을 것입니다. 그의 행동 (또는 부족)은 그에게 직접적인 영향을 미치지 않습니다. 또한, 테스트 기술을 향상시키지 않으면 승진 및 / 또는 임금 인상을 보지 못할 것임을 분명히하십시오.

결국, 당신의 모든 도움, 격려, 멘토링에도 불구하고 그는 당신의 팀에 적합하지 않을 수 있으므로 그를 보내서 그것을 얻을 수있는 사람을 찾으십시오.

나는 모든 커밋을 검토하는 코드에 대한 RodeoClown의 의견을 두 번째로 들었습니다. 그가 공정한 몇 번을 수행하면 그는 물건을 테스트하는 습관을 갖게 될 것입니다.

그래도 그런 커밋을 차단 해야하는지 모르겠습니다. 내 직장에서는 모든 사람이 모든 것에 무료로 커밋하고 모든 SVN 커밋 메시지 (diff 포함)가 팀에 이메일로 전송됩니다.

참고 : 이 작업을 계획하는 경우 Thunderbird 색상 차이 애드온 을 정말로 원합니다 .

내 상사 또는 나 (2 명의 '선임'코더)는 결국 커밋을 읽게 될 것이고, "단위 테스트를 추가하는 것을 잊었다"와 같은 내용이 있으면 이메일을 튕기거나 그 사람에게 가서 채팅을하여 이유를 설명합니다. 필요한 단위 테스트 또는 무엇이든. 다른 모든 사람들도 커밋을 읽는 것이 좋습니다. 이것은 무슨 일이 일어나고 있는지 보는 좋은 방법이기 때문입니다.하지만 주니어 개발자들은 그렇게 많이 언급하지 않습니다.

"이봐, 밥, 내가 오늘 아침에했던 커밋을 봤니? 뭐든지 할 수있는 깔끔한 트릭을 찾았 어. 커밋을 읽고 볼 수있는이 멋진 트릭을 찾았 어. 작동 원리! "

NB : 2 명의 '선임'개발자와 3 명의 주니어 개발자가 있습니다. 확장되지 않거나 더 많은 개발자와 함께 프로세스를 약간 조정해야 할 수도 있습니다.

1. 코드 커버리지를 리뷰의 일부로 만드십시오.
2. "버그를 노출하는 테스트 작성"을 버그 수정의 전제 조건으로 만드십시오.
3. 코드를 체크인하려면 특정 수준의 적용 범위가 필요합니다.
4. 테스트 주도 개발에 대한 좋은 책을 찾아서 테스트 우선이 개발 속도를 높이는 방법을 보여줍니다.

많은 심리학과 도움이되는 "멘토링"기술이 있지만, 솔직히 말해서 이것은 "내일 여전히 직업을 갖고 싶다면 테스트를 작성하는 것"으로 귀결됩니다.

적절하거나 가혹하거나 부드럽다 고 생각하는 어떤 용어로든 소파에 넣을 수 있습니다. 상관 없습니다. 하지만 사실, 프로그래머는 코드를 모아서 체크인하는 데 돈을받는 것이 아닙니다. 조심스럽게 코드를 모으고 테스트를 모은 다음 코드를 테스트하고 모든 것을 확인하는 데 돈을받습니다. (적어도 귀하의 설명에서 그게 들리는 것입니다.)

따라서 누군가가 자신의 일을 거부 할 경우 내일 집에 머물 수 있다고 설명하면 그 일을 할 사람을 고용 할 것입니다.

다시 말하지만, 필요하다고 생각한다면이 모든 것을 부드럽게 할 수 있습니다.하지만 많은 사람들은 Life In The Real World를 열심히 때리는 것만이 필요합니다 . 그리고 당신은 그들에게 그것을 주어 호의를 베푸는 것입니다.

행운을 빕니다.

그의 직업 설명을 잠시 동안 변경하여 테스트를 작성하고 테스트를 유지하십시오. 많은 회사가 처음 시작할 때 한동안 새로운 경험이없는 새로운 사람들을 위해 이것을한다고 들었습니다.

또한 그가 그 역할을 맡고있는 동안 문제를 제기하십시오. a) 현재 코드에서 실패 할 테스트를 작성하십시오. a) 소프트웨어의 요구 사항을 충족하십시오. 바라건대 그것은 그가 견고하고 철저한 테스트 (프로젝트 개선)를 만들고 그가 핵심 개발에 다시 통합 될 때 테스트를 더 잘 작성하도록 만들 것입니다.

편집> 소프트웨어의 요구 사항을 충족한다는 것은 코드가 해당 테스트 케이스를 고려할 필요가 없거나 의도하지 않았을 때 의도적으로 코드를 깨기 위해 테스트를 작성하는 것이 아니라는 것을 의미합니다.

동료가 테스트 작성 경험이 없다면 단순한 상황을 넘어서 테스트하는 데 어려움을 겪고있을 수 있으며 이는 부적절한 테스트로 나타납니다. 내가 시도 할 것은 다음과 같습니다.

• 시간을 할애하여 종속성 주입, 엣지 사례 찾기 등과 같은 테스트 기술을 동료와 공유하십시오.
• 테스트에 대한 질문에 답하도록 제안하십시오.
• 잠시 동안 테스트의 코드 검토를 수행하십시오. 동료에게 좋은 테스트의 모범이되는 변경 사항을 검토하도록 요청하십시오. 그들이 실제로 당신의 테스트 코드를 읽고 이해하고 있는지 확인하기 위해 그들의 주석을보십시오.
• 팀의 테스트 철학에 특히 잘 맞는 책이 있다면 그에게 사본을 제공하십시오. 코드 검토 피드백이나 토론에서 책을 참조하여 그가 선택하고 따라갈 스레드를 확보하는 것이 도움이 될 수 있습니다.

나는 특히 수치심 / 죄책감을 강조하지 않을 것입니다. 테스트는 널리 채택되고 모범 사례이며, 좋은 테스트를 작성하고 유지하는 것은 전문적인 예의이므로 팀 동료가 주말을 직장에서 보낼 필요가 없다는 점을 지적 할 가치가 있습니다.

정말로 "강해 져야"한다면 공정한 시스템을 도입하십시오. 아무도 자신이 뽑힌 것처럼 느끼는 것을 좋아하지 않습니다. 예를 들어 팀은 특정 수준의 테스트 범위를 유지하기 위해 코드를 요구할 수 있습니다 (게임 가능하지만 적어도 자동화 가능). 테스트를 위해 새 코드가 필요합니다. 검토자는 코드 검토를 수행 할 때 테스트의 품질을 고려하도록 요구합니다. 등등. 그 시스템은 팀의 합의에서 비롯되어야 함. 토론을 신중하게 조정하면 동료의 테스트가 예상과 다른 다른 근본적인 이유를 발견 할 수 있습니다.

그 / 그녀를 가르치는 것은 그의 멘토의 책임입니다. 그 / 그녀의 테스트 방법을 얼마나 잘 가르치고 있습니까? 그와 짝을 이루고 있습니까? 주니어는 xyz에 대한 좋은 테스트를 설정하는 방법을 잘 모릅니다.

주니어 신입생으로서 그는 많은 개념을 알고 있습니다. 몇 가지 기술. 약간의 경험. 그러나 결국 모든 주니어는 잠재력이 있습니다. 그들이 작업하는 거의 모든 기능에는 이전에 해본 적이없는 새로운 것이있을 것입니다. 물론 주니어는 "문"을 열고 닫는 수업 중 프로젝트에 대한 간단한 State 패턴을 수행했지만 패턴을 실제 세계에 적용하지는 않았습니다.

그 / 그녀는 당신이 얼마나 잘 가르치는가만큼 잘할 것입니다. 만약 그들이 "Just get it"을 할 수 있었다면 그들이 처음에 주니어 포지션을 취했을 것이라고 생각하십니까?

내 경험상 주니어는 고용되어 선배들과 거의 같은 책임을지게되지만 보수를 적게 받고 흔들 리기 시작하면 무시됩니다. 내가 쓴 것 같으면 용서 해줘

@ jsmorris

나는 한때 선임 개발자와 "건축가"에게 늦지 않고 "쉬운"일을 전날 밤에 끝내지 않은 이메일로 나를 비난하고 테스터 (대학을 졸업 한 첫 직장이었다)를 받았다. 우리는 하루 종일 그것에 있었고 오후 7시에 종료라고 불렀고, 그날 점심 식사 전에 오전 11 시부 터 몸부림 치고 있었고, 적어도 두 번은 우리 팀원 모두에게 도움을 요청했습니다.

나는 응답하고 팀에 다음과 같이 참조했습니다. "한 달 동안 실망했습니다. 팀의 도움을받지 못했습니다. 필요하면 길 건너 커피 숍에있을 것입니다. 죄송합니다. 거의 모든 것이 의존하는 12 개 매개 변수, 800 라인 메서드를 디버깅 할 수 없습니다. "

커피 숍에서 한 시간 정도 식은 후 사무실로 돌아와 쓰레기를 움켜 쥐고 떠났습니다. 며칠 후 그들은 내가 들어올 것인지 물어 보자 전화를했고, 그렇게하겠다고 말했지만, 아마도 내일 인터뷰를했습니다.

"그럼 그만둬?"

소스 저장소에서 : 각 커밋 전에 후크를 사용합니다 (예 : SVN에 대한 사전 커밋 후크).

해당 후크에서 각 메서드에 대해 하나 이상의 사용 사례가 있는지 확인합니다. 사전 커밋 후크를 통해 쉽게 적용 할 수있는 단위 테스트 조직 규칙을 사용합니다.

통합 서버에서 모든 것을 컴파일하고 테스트 커버리지 도구를 사용하여 테스트 커버리지를 정기적으로 확인합니다. 코드에 대한 테스트 범위가 100 %가 아닌 경우 개발자의 커밋을 차단합니다. 코드의 100 %를 다루는 테스트 케이스를 보내야합니다.

자동 검사 만 프로젝트에서 잘 확장 될 수 있습니다. 모든 것을 손으로 확인할 수는 없습니다.

개발자는 자신의 테스트 케이스가 코드의 100 %를 포함하는지 확인할 수단이 있어야합니다. 그렇게하면 100 % 테스트 된 코드를 작성하지 않으면 "죄송합니다. 잊어 버려서 죄송합니다"오류가 아니라 자신의 잘못입니다.

기억하십시오 : 사람들은 당신이 기대하는 것을 결코하지 않고 항상 당신이 검사하는 것을합니다.

우선, 여기에있는 대부분의 응답자들이 지적한 것처럼, 그 사람이 테스트에서 가치를 보지 못한다면, 당신이 할 수있는 일이 많지 않으며, 당신은 이미 그 사람을 해고 할 수 없다고 지적했습니다. 그러나 여기서 실패는 선택 사항이 아니므로 할 수 있는 몇 가지 작업은 어떻습니까?

조직이 6 명 이상의 개발자를 보유 할 수있을만큼 규모가 큰 경우 품질 보증 부서를 두는 것이 좋습니다 (시작할 사람이 단 한 명이라도). 이상적으로는 테스터 1 명과 개발자 3 ~ 5 명의 비율이 있어야합니다. 프로그래머에 대한 것은 ... 그들은 테스터가 아니라 프로그래머입니다. 정식으로 적절한 QA 기술을 배운 프로그래머를 아직 인터뷰하지 않았습니다.

대부분의 조직은 코드에 대한 노출이 가장 적은 신규 고용인에게 테스트 역할을 할당하는 치명적인 결함을 만듭니다. 이상적으로는 선임 개발자가 코드 경험이있는 QA 역할로 이동해야합니다. , 그리고 (희망적으로) 발생할 수있는 코드 냄새와 실패 지점에 대한 육감을 개발했습니다.

게다가 실수를 저지른 프로그래머는 일반적으로 구문 오류가 아니라 (컴파일에서 선택되는) 논리 오류가 아니기 때문에 결함을 찾지 못할 것입니다. 코드를 작성할 때 테스트하십시오. 코드를 개발 한 사람이 해당 코드를 테스트하게하지 마십시오. 다른 사람보다 버그가 적을 것입니다.

귀하의 경우, 재조정 된 작업 노력을 감당할 수 있다면이 새로운 직원을 QA 팀의 첫 번째 구성원으로 만드십시오. "실제 세계에서의 소프트웨어 테스트 : 프로세스 개선"을 읽어 보도록하세요. 새로운 역할에 대한 교육이 필요하기 때문입니다. 그가 마음에 들지 않으면 그만두고 당신의 문제는 여전히 해결됩니다.

약간 덜 복수심에 찬 접근 방식은이 사람이 자신이 잘하는 일을하도록하고 (저는이 사람이 작업의 프로그래밍 부분에서 실제로 유능하기 때문에 고용되었다고 가정합니다) 테스트를 수행 할 테스터 한두 명을 고용하는 것입니다 ( 대학생들은 종종 실습 또는 "협동"용어를 가지고 있으며 노출을 좋아하고 저렴합니다.)

참고 : 결국 QA 팀이 QA 디렉터에게보고하거나 적어도 소프트웨어 개발자 관리자에게보고하지 않기를 원할 것입니다. QA 팀이 제품을 완성하는 것이 주요 목표 인 관리자에게보고하는 것은 관심.

조직이 6 명 미만이거나 새 팀을 만들 수 없다면 PP (paired programming)를 권장합니다. 나는 모든 극단적 인 프로그래밍 기술을 완전히 개종 한 것은 아니지만, 확실히 짝을 이루는 프로그래밍을 믿습니다. 그러나 짝을 이룬 프로그래밍 팀의 두 구성원 모두 전담해야합니다. 그렇지 않으면 작동하지 않습니다. 그들은 두 가지 규칙을 따라야합니다. 검사관은 화면에 코딩되는 내용을 완전히 이해해야하거나 코더에게 설명을 요청해야합니다. 코더는 자신이 설명 할 수있는 것만 코딩 할 수 있습니다. "당신이 보게 될 것입니다", "저를 믿으세요"또는 손을 흔드는 행위는 용납되지 않습니다.

나는 당신의 팀이 그것을 할 수있는 경우에만 PP를 추천합니다. 테스트와 같이 아무리 많은 응원이나 협박도 자존심 가득한 내성적 인 두 사람이 그렇게하는 것이 편하지 않다고 느끼면 함께 일하도록 설득하지 않기 때문입니다. 그러나 세부적인 기능 사양을 작성하고 코드 리뷰를 수행하는 것과 짝을 이룬 프로그래밍 사이에서 PP가 일반적으로 승리한다는 것을 알게되었습니다.

PP가 당신에게 적합하지 않다면 TDD가 최선의 선택이지만 문자 그대로 취한 경우에만 가능합니다. 테스트 주도 개발이란 테스트를 먼저 작성하고 테스트를 실행하여 실제로 실패했음을 증명 한 다음 작동하도록 가장 간단한 코드를 작성하는 것을 의미합니다. 트레이드 오프는 이제 코드이기도 한 수천 개의 테스트 모음을 가지고 있어야하며 버그를 포함 할 수있는 프로덕션 코드와 똑같습니다. 솔직히 말해서 저는 TDD의 열렬한 팬이 아닙니다. 주로 이러한 이유로 인해 테스트 케이스 문서보다 테스트 스크립트를 작성하려는 많은 개발자에게 효과적입니다. 일부 테스트는없는 것보다 낫습니다. 테스트 적용 가능성을 높이고 스크립트의 버그를 줄이기 위해 TDD와 PP를 결합합니다.

다른 모든 방법이 실패하면 프로그래머가 욕설 항아리와 동등하게 만드십시오. 프로그래머가 빌드를 깨뜨릴 때마다 $ 20, $ 50, $ 100 (직원들에게 적당히 고통스러운 것)을 좋아하는 항아리에 넣어야합니다 ( 등록!) 자선. 그들이 지불 할 때까지, 그들을 피하십시오 :)

농담을 제쳐두고, 프로그래머가 테스트를 작성하도록하는 가장 좋은 방법은 프로그래밍을하지 않는 것입니다. 프로그래머를 원하면 프로그래머를 고용하십시오-테스트를 ​​원하면 테스터를 고용하십시오. 저는 12 년 전에 테스트를하면서 주니어 프로그래머로 시작했고, 그것이 제 경력 경로로 바뀌었고, 아무것도 바꾸지 않았습니다. 적절하게 육성되고 소프트웨어를 개선 할 수있는 권한과 권한이 부여 된 견고한 QA 부서는 처음부터 소프트웨어를 작성하는 개발자만큼이나 가치가 있습니다.

이것은 약간 무정 할 수 있지만 상황을 설명하는 방식은이 사람을 해고해야하는 것처럼 들립니다. (쓰기 시험 포함) 주택 개발 사례에 따라 거부 : 또는 적어도 그것을 명확하게 하고 다른 사람들이 결국 해고 얻을 것이다 정리해야한다는 버그 코드를 확인합니다.

주니어 엔지니어 / 프로그래머가 테스트 스크립트를 디자인하고 수행하는 데 많은 시간을 들이지 않는 주된 이유는 대부분의 CS 인증이이를 많이 요구하지 않기 때문에 디자인 패턴과 같은 다른 엔지니어링 영역은 대학 프로그램에서 더 많이 다루기 때문입니다.

내 경험상 주니어 전문가를 습관화하는 가장 좋은 방법은 프로세스의 일부로 명시 적으로 만드는 것입니다. 즉, 반복에 걸리는 시간을 추정 할 때 케이스를 설계, 작성 및 / 또는 실행하는 시간이이 시간 추정에 통합되어야합니다.

마지막으로 테스트 스크립트 디자인 검토는 디자인 검토의 일부 여야하며 실제 코드는 코드 검토에서 검토되어야합니다. 이로 인해 프로그래머는 자신이 작성한 각 코드 줄에 대해 적절한 테스트를 수행 할 책임이 있으며, 수석 엔지니어와 동료는 작성된 코드 및 테스트에 대한 피드백과 지침을 제공 할 책임이 있습니다.

"디자인이 더 단순 해짐을 보여주기"귀하의 의견에 따라 저는 여러분들이 TDD를 연습한다고 가정하고 있습니다. 사실 후에 코드 리뷰를하는 것은 효과가 없을 것입니다. TDD에 대한 모든 것은 그것이 테스트 철학이 아니라 디자인이라는 것입니다. 그가 디자인의 일부로 테스트를 작성하지 않았다면, 특히 주니어 개발자로부터 테스트를 작성하는 것으로부터 많은 이익을 얻지 못할 것입니다. 그는 결국 많은 코너 케이스를 놓치고 그의 코드는 여전히 엉망이 될 것입니다.

가장 좋은 방법은 것입니다 매우 그와 함께 앉아서 몇 쌍의 프로그래밍을 할 수있는 환자의 수석 개발자. 그리고 그가 배울 때까지 계속하십시오. 또는 배우지 않으면 실제 개발자를 실망시키기 때문에 그가 더 적합한 작업에 그를 다시 할당해야합니다.

모든 사람이 같은 수준의 재능 및 / 또는 동기를 가지고있는 것은 아닙니다. 민첩한 팀이라도 개발 팀은 "A-Team"의 사람들과 "B-Team"의 사람들로 구성됩니다. A-Team 멤버는 솔루션을 설계하고, 사소하지 않은 모든 프로덕션 코드를 작성하고, 비즈니스 소유자와 의사 소통하는 사람입니다. B-Team은 구성 관리, 스크립트 작성, 절름발이 버그 수정, 유지 보수 작업과 같은 작업을 처리합니다.이 모든 작업에는 실패에 대한 작은 결과를 가져 오는 엄격한 절차가 있습니다.