팀 관리에 대한 질문이 있습니다. 지금은 코딩 공장에서 원격으로 일하는 하급 개발자를 상대하고 있습니다. 그 사람은 비판을 받고 기꺼이 배울 의향이 있지만, 물건을 얼마나 밀어야할지 의심이 듭니다.
SRP 위반, 신의 대상, 방법이나 변수에 대한 의미없는 이름; 나는 그가 고쳐야 할 것을 지적하고 그것이 왜 잘못되었는지 설명하려고 노력한다.
내 질문은 : 언제 중지합니까? 지금은 잘못된 언어의 변수 이름과 같은 코딩 스타일에 약간의 위반이 있거나 (이전 팀은 스페인어와 영어를 혼합하여 수정하려고합니다), 사소한 구조적 문제로 인해 문제가 해결되는 경우 여가 시간이 있거나 문제가있는 클래스를 수정해야합니다. 나는 이것이 팀 사기에 좋다고 생각하므로 초보자에게 무엇을 사소한 세부 사항처럼 보일지에 대해 코드를 지속적으로 되돌려 보내지 않을 것입니다. 어떤 일을하는 법을 배우는 것에서
그 사람을 가르치는 것과 끊임없는 비평으로 그를 태우지 않는 것 사이의 경계를 어떻게 균형을 맞추는가? 주니어에게는 그의 눈에 효과가있는 것을 다시 해달라고하면 실망 할 수 있습니다.
답변
병합하기 전에 코드를 수정해야한다고 생각되면 주석을 작성하십시오. 바람직하게는 “왜”를 사용하여 개발자가 배울 수 있습니다.
코드는 작성된 것보다 훨씬 자주 읽습니다. 따라서 “사소한”것으로 보이는 것이 실제로 중요 할 수 있습니다 (예 : 변수 이름).
그러나 지루한 의견이 있으면 다음을 고려하십시오.
- CI 프로세스가이를 포착해야합니까?
- 참조 할 명확한 “개발자 안내서”가 있습니까 (또는 모든 것이 머리에 문서화되어 있습니까)?
- 이 주석이 실제로 코드 품질에 기여합니까?
많은 사람들이 공정이나 완벽의 제단에서 생산성을 희생합니다. 이 작업을 수행하지 않도록주의하십시오.
가능하면 동료를 직접 방문하십시오. 또는 화상 통화를 사용하십시오. 관계를 구축하면 비평 (코드 검토조차도)을보다 쉽게 관리 할 수 있습니다.
코드 조각에 문제가 너무 많거나 적다는 것을 발견하면 작은 코드 조각에 대한 검토를 요청하십시오. 증분 변경은 정의상 크기가 더 작기 때문에 더 중요한 설계 문제를 피할 가능성이 높습니다.
그러나 절대적으로 않습니다 하지 물건을 병합 한 후 돌아가서 그것을 해결. 이것은 수동적 인 공격이며 개발자가이 작업을하면 사기를 죽일 수 있습니다.
답변
작가보다는 코드에 대한 비판을 유지하십시오.
제작 된 모든 작품에는 고유 한 감정 애착이 있습니다. 가능한 한 작성기에서 코드를 분리하여이를 완화하는 것이 좋습니다. 코드의 품질은 사용자 사이의 마찰 지점이 아니라 함께 직면하는 상호 목표로 일관되게 설정되어야합니다.
이것을 달성하는 한 가지 방법은 현명하게 단어를 선택하는 것입니다. STEM 개인은 자신을 매우 논리적으로 생각하기를 원하지만 감정은 인간 본성의 일부입니다. 사용 된 언어는 상한 감정이나 아파 한 감정의 차이 일 수 있습니다. “이 기능 이름이 영어 인 경우 규칙에 더 일관성이 있습니다”라고 말하는 것이 “이 기능 이름을 잘못 작성했으며 영어 여야합니다.”보다 바람직합니다. 후자는 여전히 길들이고 혼자서도 괜찮은 것처럼 보이지만, 전자에 비해 결함을 분명히 알 수 있습니다. 개인 또는 이메일로 말할 내용을 준비 할 때 상황, 단어 및 초점이 문제가 아닌 문제 에 있는지 여부를 조사하십시오 사람 .
신체 언어
말은 중요하지만 대부분의 의사 소통은 비언어적입니다. 신체 언어에주의를 기울이십시오. 오리엔테이션과 같은 미묘한 미묘한 것조차도 중요합니다.
정직한 긍정적 인 피드백 제공
다수의 연구에 따르면 나쁜 행동을 처벌하는 대신 좋은 행동을 보상 할 때 정보가 더 빨리 학습되고 더 잘 유지된다는 것이 밝혀졌습니다. 때로는 단순한 “좋은 직업”또는보다 구체적인 “성능이 우리의 표준을 티, 훌륭한 작업에 일치시키는 것으로 나타났습니다.” 이러한 개선에 대한 인식을 보완하여 수정 한 문제에 대해 다른 사람에게 주니어 개발자와 그의 작업에 큰 영향을 줄 수 있다고 조언합니다.
답변
그 사람은 비판을 받고 기꺼이 배울 의향이 있지만, 물건을 얼마나 밀어야할지 의심이 듭니다.
당신이 할 수있는 모든 것을 미십시오. 그 사람이 배우고 있고 코드를 검토하는 것이 당신의 일이라면, 당신은 그가 좋은 일을하면 많은 것을 얻을 수 있습니다.
즉, 앞으로 검토 할 코드가 줄어들고 팀에 채용 대상이 될 수 있습니다.
또한, 당신이 물러 서면, 당신은 도움이 아니라 후원입니다.
너무 많은 일을하고 있는지 묻는 질문을 여기에 게시했다는 사실 만으로이 특정 조언이 필요하지 않다는 것을 이미 서명했지만 다른 사람들에게는 여기에 있습니다. 얼간이.
멘토가되는 것은 쉬운 일이 아닙니다. 또한 실수를 저지르고 스스로 고칠 수있는 공간을 확보해야합니다. 실제 피해를 입히지 않는 곳에서 그렇게해야합니다.
답변
귀하의 설명을 바탕으로, 나는 “이것이 좋습니다. 내가 다르게했을 몇 가지가 있지만 그다지 중요하지는 않습니다.”
당신이 이해하는 것처럼 비판에는 비용이 들며 세부 사항을 파악하는 데 많은 시간을 소비하면 사기 문제가됩니다. 이상적으로는 모든 코딩 표준이 자동으로 확인되므로 표준을 따르지 않으면 빌드 할 수 없습니다. 시간을 크게 절약 할 수 있으며 비즈니스에 전념 할 수 있습니다. ‘중요한 것’에 대한 비판을 예약하면 조언이 훨씬 더 많은 영향을 미치며 소중한 멘토로 간주됩니다. 좋지 않은 것과 그렇지 않은 것을 구별하는 것이 정말 중요합니다.
나는 가르치는 순간 의 개념을 믿는다 . 개발자의 정신 능력이 충분한 경우, 다른 방식으로 세부 사항을 요구할 수 있습니다. (S) 그는 아닐 수도 있고 괜찮습니다. 사람들은 직장에서 타 버리고 일찍 시작하여 나중에 간단 해 보이는 것을 성취하기 위해 많은 정신 에너지가 필요할 수 있습니다.
답변
나는 그의 작품이 받아 들일 수있는 것이 아니라 완벽 할 때 받아들이는 것을 고려할 것입니다. 그리고 다음 과제는 토론을 마친 후 작지만 중요한 모든 변경 사항을 적용하여 즉시 리팩토링하는 것입니다.
따라서 일이 처음 받아 들여질 때 당신의 메시지는 그것이 나쁘지 않다는 것입니다. 그리고 어떤 곳은 그것을 충분히 잘 받아 들였을 것입니다. 그러나 자신의 무역을 제대로 배우기를 원하는 주니어 개발자가되고 싶은 곳은 아닙니다.
그래서 당신은 “충분하지 않기 때문에 당신의 일을 거부합니다”라고 말하지 않습니다. 당신은 (a) “충분히 잘해서 당신의 일을 받아들입니다”라고 말한 다음, (b) “하지만 더 잘하고 싶습니다”라고 말합니다.
답변
꽤 광범위한 질문이지만 여기 몇 가지 아이디어가 있습니다.
-
동료 리뷰 (주니어 개발자에 의한)
누군가가 “올바른”방법을 배우는 가장 좋은 방법은 다른 사람들이 그것을하는 것을 보는 것입니다. 모든 개발자가 코드 검토를 수행합니까? 하급 개발자가 수행하도록하는 것도 좋지 않은 생각이 아닐 수도 있습니다 (선임 개발자의 검토도 하나 이상 받아야 함). 그렇게하면 좋은 코더가 작동하는 것을 볼 수있을뿐만 아니라 자신 이외의 엔지니어를 대상으로 한 리뷰 의견이 있다는 것을 알 수 있습니다.
-
조기 피드백 / 작업 검토
개발자가 자신의 작업 분류에 참여할 수 있도록합니다. 작업 노트에 의도 한 디자인을 기록하고 변경 세트가없고 작업만으로 “코드 검토”를 제출하게하십시오. 그렇게하면 한 줄의 코드를 작성하기 전에 계획을 검토 할 수 있습니다. 그의 작업이 검토되면 코딩을 시작할 수 있습니다 (그 후 다른 코드 검토를 제출 함). 이것은 개발자가 많은 것을 썼고 그것을 다시 써달라고 해야하는 강렬한 상황을 피합니다.
답변
코드가 객관적인 서면 표준을 객관적으로 위반하는 경우 모든 문제가 해결 될 때까지 계속 밀어 내야한다고 생각합니다. 물론, 처음 몇 번의 커밋은 개발자에게는 약간 성가신 일이지만 나중에 가이드 라인을 더 빨리 배울 수도 있습니다.
또한, 여기저기서 몇 가지 표준 위반을 허용하면 잘못된 선례를 볼 것입니다. 깨진 창 이론을보십시오 . 또한 표준이 이미 코드베이스에 일관되게 적용된 경우 표준을 따르는 것이 훨씬 쉽습니다. 문제의 주니어 개발자를 포함하여 모두가 승리합니다.
코딩 표준이 기록되어 있다면 사기가 큰 문제라고 생각하지 않습니다. 그것이 더 주관적인 “잘, 나는 다르게 다르게 했었을 것이다”영역에 들어간 경우에만 개발자의 접근 방식이 똑같이 유효 할 수 있기 때문에 걱정해야한다.