풀은 주니어 훈련 장소를 요청합니까

마스터로의 Pull Request의 모든 코드는 프로덕션 준비가되어야한다는 개념이 있습니다. 이것은 의미가 있으며 내 의견으로는 공정한 진술입니다.

여기서 PR을 만들면이를 마스터에 넣었을 것이라는 의견이 있지만 일부 검토자가 단순히 '동의'하고 누락 된 부분을 발견하기를 원합니다.

우리는 인간이기 때문에 실수를 저지르고 다른 검토자가 단위 테스트에서 찾을 수없는 항목 (맞춤법 오류, 잘못된 javadoc 등)을 찾을 수 있기를 바랍니다.

그러나 풀 요청은 개발자에게 어느 정도의 수준의 지원 / 훈련을 제공해야합니까?

새로운 변경 사항을 적용 할 때마다 검토자는 변경 사항을 다시 검토해야합니다. 변경 사항은 개발 시간이 걸리고 변경 사항을 다시 검토하게합니다.

따라서 Pull Requests에서 얼마나 많은 훈련이 예상되어야합니까? 저의 일부는 후배 나 노인에 따라 다릅니다. 그러나 나는 또한 주니어들에게도 방대한 양의 문제를 발견 할 수있는 장소가되어서는 안된다고 생각합니다.

"내 풀 요청은 프로덕션 준비가되어야한다"는 목표를 달성하기 위해 개발자가 노력하도록 노력하는 데 어려움을 겪고있는 사람이 있습니까?

풀 요청은 교육을위한 장소가 아닙니다. 당신의 팀은 올바른 아이디어를 가지고 있습니다. PR은 "가는 것이 좋다고 생각합니다. 무언가를 놓친 경우를 대비하여 두 번째 눈을 가질 수 있습니까? 결국 인간입니다." 그리고 나는 그것이 당신의 견습생이하는 일이라고 생각합니다. 그들은 솔직하게 생각하는 것이 좋다고 생각합니다.

여기 극단적 인 생각이 있습니다 (말장난 의도). 가슴 앓이를주는 견습생과 프로그램을 연결하십시오. 더 선임 팀원으로서, 그들을 들어 올리고 생산성을 높이는 것이 당신의 임무입니다.

팀의 핵심 설계 원칙이나 표준을 위반하는 코드가 풀 요청 단계에 이르면 분명히 해결해야합니다. 또한 코드 검토는 팀의 표준 및 디자인 사례를 전달하는 좋은 수단이 될 수 있습니다.

그러나 가장 좋은 장소입니까? 내가 말하지 않은 이유는 다음과 같습니다.

1. 기본적인 설계 결함이나 대규모 문제를 해결하기 위해 여러 번의 코드 검토 반복이 필요한 경우, 검토 기한 또는 일반적인 소진으로 인해 위에서 언급 한 더 작은 문제를 간과하려는 강한 유혹이있을 것입니다. 이상적으로는 팀이이 유혹에 저항 할만큼 탄력적 일 수 있지만, 이로 인해 상황이 발생하지 않는 것이 가장 좋습니다.
2. 많은 수의 주석이 포함 된 코드 검토를받는 것이 후배 / 신입 사원에게는 좋은 경험이 아닙니다. 예, 피드백에 응답하는 것은 개발에 필요한 기술이지만 개발자가 항상 마음에 들지 않는 코드에 능숙하게 응답하는 것은 아닙니다.

더 큰 규모의 피드백을 위해서는 쌍 프로그래밍 및 설계 검토가 선호되는 장소입니다.

즉, 코드 검토 중에 코드를 처리하는 것이 "잘못"되어 코드를 처리하는 것이 더 나빠질 수 있으며, 이것이 최선의 환경 (예 : 원격 팀)이있을 수 있습니다. 이 경우 코드 검토에서 문제를 해결하고 지금까지 개발 한 개발 프로세스의 문제를 해결하십시오.

풀 요청 중에 문제를 찾는 것이 이상적이지는 않지만 테스트 나 생산 문제보다 확실히 좋습니다.

풀 요청이 사람들을 훈련 시키는 유일한 장소 가되어서는 안되기 때문에 더 많이 말하고 싶습니다 . 또한, 주니어 개발자 만이 풀 요청에 대한 교육이 필요할 수 있습니다. 계약자, 오픈 소스 기고자, 현지 규정 또는 표준에 익숙하지 않은 다른 부서의 개발자, 심지어 베테랑 프로그래머조차도 만족할 때 가끔 알림이 필요합니다.

당분간 풀 요청을 여는 데 비용이 거의 들지 않습니다. 원하는만큼 많은 사람이 원하는만큼 피드백을 제공 한 다음 작성자가 병합 할 준비가되었다고 다시 알릴 때까지 그대로 두십시오. 풀 요청은 제안 된 코드 변경이 완전히 준비되었거나 많은 작업이 필요한지 여부를 알려주는 훌륭한 중앙 도구입니다.

일부 풀 요청 검토는 고무 스탬프 이상으로 드러나며 팀에 대한 외부 제출은 한 달이 걸릴 수 있습니다. 첫 번째 종류는 얻을 수 있으면 좋지만 두 번째 종류가 가치가 없다는 것을 의미하지는 않습니다. 사람들이 항상 완벽한 끌어 오기 요청을 제출하도록하는 것은 모든 사람에게 실망 스러울 것입니다.

저는 항상 좋은 리드의 특징 중 하나가 각 개발주기 동안 필요에 따라 추가 교육을 제공하는 사람이라고 생각했습니다. 저에게 이것은 저 자신을 코딩하거나 코드를 검토 할뿐만 아니라 더 많은 저급 개발자들과 함께 앉아 프로그래밍을함으로써 내가 지뢰 한 지뢰를 피할 수 있도록 도와줍니다.

주로 우리의 주요 목표가 교육적이라는 환상은 없습니다. 그렇지 않습니다. 상급자, 리드 또는 하급 개발자이든 목표는 당신의 교양이 아닙니다. 목표는 항상 고객에게 품질 코드를 제공하는 것입니다. 바람직하게는 시간과 예산에 따라 원하는 것을 수행하십시오. 그러나 모든 업무를 직접 수행하는 것은 불가능하므로 모든 사람이 팀의 성공을 돕는 데 도움을주는 리드로서 저의 책임입니다. 그리고 그것은 훈련 기회가 실제로 나타날 때 인식하는 것을 의미합니다.

따라서 풀 요청이 주니어 훈련을위한 장소인지에 대한 귀하의 질문에, 나는이 기간 동안 가르치는 순간이 드물지 않다고 말해야 할 것입니다. 첫 번째 병합 충돌을 처리해야합니다. 검토 후이 문제를 해결하겠습니다. 오, 봐요, 당신은 당신의 DAO에 대한 단위 테스트를 포함하지 않았습니다, 우리는 우리가 그 새로운 방법을 다룰 수있을 때까지 당신의 검토를 연기 할 것입니다. 이 재무 계산에서 BigDecimals보다 이중 기본 요소를 사용하는 것이 더 나은 이유는 무엇이라고 생각 했습니까? 네, 그렇게 드문 일이 아닙니다.

따라서 확실히 일어날 수 있지만 풀 요청의 주요 목표는 아닙니다. 풀 요청의 코드가 프로덕션 준비가 될 것이라는 기대도 없다고 생각합니다. 종종 그렇지 않습니다.

gitflow 스타일 분기 전략에서 기능 및 릴리스 분기를 사용하는 경우 풀 요청은 릴리스 후보와 비슷합니다. 생산 준비가되어 있지 않지만 더 근사한 것입니다. 코드가 컴파일 된 것을 알고 있으며 (오른쪽) 사용자 스토리의 목표를 충족한다고 주장하기에 충분한 테스트 코브 페가 있습니다. 또한 개발 환경에서 여러 통합 테스트를 이미 실행 했으므로 PR을 검토하는 동안 변경 사항을 시연하라는 요청을 받으면 바로 데모를 진행할 수 있습니다.

궁극적으로 PR 검토 중에 도움을 제공해야한다고 생각하지만 일반적인 코딩에는 도움이되지 않습니다. 대신, 작업 품질의 프로덕션 품질 코드에 포함시키기 위해 제안 된 코드를 준비하는 것과 관련이 있습니다. PR은 개발자가 PR에 포함 된 각 변경 사항에 대한 타당성과 확실한 이해를 보여줄 수있는 기회입니다. 심지어 단위 테스트, 데모 및 많은 질문으로 무게를 측정 한 후에도 제안 된 변경 사항을 프로덕션에 적용 할 것으로 기대하지 않습니다.

코드는 결국 끝났습니다. 그러나 우리는 QA가 고문하도록했습니다.

본인의 기여에 대해 모든 사람에게 감사하고이 주제에 대한 사람들의 의견을 이해하는 데 도움을주고 싶습니다.

이것은 피드백을받은 후의 답변이며, 이제받은 답변과 의견을 바탕으로 이해했습니다. 모두 감사합니다.

요약

• 박쥐의 완벽한 끌어 오기 요청을 기대하거나 강요하지 마십시오.
• 그러나 완벽한 풀 요청에 대한 목표 를 계속 유지하십시오 .
• 기대 일부 풀 요청에 협력 / 지원의 양을. 결국, 그것은 풀 요청을 생성하여 본질적으로 요구하는 것입니다.
• 디자인 결함이나 구현 결함으로 인해 약간 커지면 개발자와 함께 시간을 보내고 일부를 프로그래밍하여 코드를 작성하고 목표에 더 가깝게 만듭니다. 이것이 모든 선임 개발자의 역할입니다.
• 주니어는 중급 개발자보다 더 많은 페어 프로그래밍 세션이 필요합니다. 따라서 풀 요청이 해당 요구 사항을 반영해야합니다.
• 풀 요청에서 식별 된 재 작업을 줄이기 위해 코드를 만지기 전에 개발자가 설계 / 구현 회의를 갖도록 권장하십시오.

기술 팀 측면에서 회사 문화에 대해 더 자세히 말할 수 있습니까? 개발자가 메인 라인에 병합하려고 할 때 코드를 프로덕션에 사용할 수 있다는 아이디어로 어려움을 겪고 있다면 실제로 개발자에게 무엇을 말하고 있습니까? 당신은 그들의 작업이 "완료"되었을 때 작동하지 않는다면 괜찮다고 말하고 있습니까? 시스템이 고장 나도 괜찮습니까? 그들이 기술 부채를 추가하고 있다면, 그것을 정당화하고 그들이하고있는 일을 알고 있다면, 그들이 다시 돌아와서 리팩토링을 할 수 있다는 것을 보여 주면 괜찮습니다. 그러나 그들이 왜 위험한 일을하고 있는지 잘 모를 경우, 몇 번이나 통과시킬 수 있습니까?

주니어 개발자라면 처음 몇 개의 끌어 오기 요청에 분명히 문제가 있습니다. 결국 그들은 그것을 끊어야한다. 계속해서 문제가 발생하면 아직 준비가되지 않은 작업을 할당하고 있습니까?

아니면 대체 주니어를 고용하고 그것을 파악할 수 없었던 주니어를 해고해야합니까?

내가 뭘 봤는지 알아? 유능한 개발자가 아닌 사람들은 단지 네 포즘 때문에 회사에서 수년간 계속 일합니다. 물론 풀 풀 요청은 여러 번의 검토가 필요합니다. 린의 말로 표현하자면, 그들은 "폐기물"입니다. 팀을 끌고, 결론을 내리는 것입니다.

따라서 스스로 결정해야합니다. 후배들에게 역량을 보여주기 위해서는 몇 번의 풀 요청이 필요할까요?