하급 개발자의 '거의 좋은'코드를 처리하는 방법은 무엇입니까? [닫은]

팀 관리에 대한 질문이 있습니다. 지금은 코딩 공장에서 원격으로 일하는 하급 개발자를 상대하고 있습니다. 그 사람은 비판을 받고 기꺼이 배울 의향이 있지만, 물건을 얼마나 밀어야할지 의심이 듭니다.

SRP 위반, 신의 대상, 방법이나 변수에 대한 의미없는 이름; 나는 그가 고쳐야 할 것을 지적하고 그것이 왜 잘못되었는지 설명하려고 노력한다.

내 질문은 : 언제 중지합니까? 지금은 잘못된 언어의 변수 이름과 같은 코딩 스타일에 약간의 위반이 있거나 (이전 팀은 스페인어와 영어를 혼합하여 수정하려고합니다), 사소한 구조적 문제로 인해 문제가 해결되는 경우 여가 시간이 있거나 문제가있는 클래스를 수정해야합니다. 나는 이것이 팀 사기에 좋다고 생각하므로 초보자에게 무엇을 사소한 세부 사항처럼 보일지에 대해 코드를 지속적으로 되돌려 보내지 않을 것입니다. 어떤 일을하는 법을 배우는 것에서

그 사람을 가르치는 것과 끊임없는 비평으로 그를 태우지 않는 것 사이의 경계를 어떻게 균형을 맞추는가? 주니어에게는 그의 눈에 효과가있는 것을 다시 해달라고하면 실망 할 수 있습니다.

병합하기 전에 코드를 수정해야한다고 생각되면 주석을 작성하십시오. 바람직하게는 "왜"를 사용하여 개발자가 배울 수 있습니다.

코드는 작성된 것보다 훨씬 자주 읽습니다. 따라서 "사소한"것으로 보이는 것이 실제로 중요 할 수 있습니다 (예 : 변수 이름).

그러나 지루한 의견이 있으면 다음을 고려하십시오.

• CI 프로세스가이를 포착해야합니까?
• 참조 할 명확한 "개발자 안내서"가 있습니까 (또는 모든 것이 머리에 문서화되어 있습니까)?
• 이 주석이 실제로 코드 품질에 기여합니까?

많은 사람들이 공정이나 완벽의 제단에서 생산성을 희생합니다. 이 작업을 수행하지 않도록주의하십시오.

가능하면 동료를 직접 방문하십시오. 또는 화상 통화를 사용하십시오. 관계를 구축하면 비평 (코드 검토조차도)을보다 쉽게 ​​관리 할 수 ​​있습니다.

코드 조각에 문제가 너무 많거나 적다는 것을 발견하면 작은 코드 조각에 대한 검토를 요청하십시오. 증분 변경은 정의상 크기가 더 작기 때문에 더 중요한 설계 문제를 피할 가능성이 높습니다.

그러나 절대적으로 않습니다 하지 물건을 병합 한 후 돌아가서 그것을 해결. 이것은 수동적 인 공격이며 개발자가이 작업을하면 사기를 죽일 수 있습니다.

작가보다는 코드에 대한 비판을 유지하십시오.

제작 된 모든 작품에는 고유 한 감정 애착이 있습니다. 가능한 한 작성기에서 코드를 분리하여이를 완화하는 것이 좋습니다. 코드의 품질은 사용자 사이의 마찰 지점이 아니라 함께 직면하는 상호 목표로 일관되게 설정되어야합니다.

이것을 달성하는 한 가지 방법은 현명하게 단어를 선택하는 것입니다. STEM 개인은 자신을 매우 논리적으로 생각하기를 원하지만 감정은 인간 본성의 일부입니다. 사용 된 언어는 상한 감정이나 아파 한 감정의 차이 일 수 있습니다. "이 기능 이름이 영어 인 경우 규칙에 더 일관성이 있습니다"라고 말하는 것이 "이 기능 이름을 잘못 작성했으며 영어 여야합니다."보다 바람직합니다. 후자는 여전히 길들이고 혼자서도 괜찮은 것처럼 보이지만, 전자에 비해 결함을 분명히 알 수 있습니다. 개인 또는 이메일로 말할 내용을 준비 할 때 상황, 단어 및 초점이 문제가 아닌 문제 에 있는지 여부를 조사하십시오 사람 .

신체 언어

말은 중요하지만 대부분의 의사 소통은 비언어적입니다. 신체 언어에주의를 기울이십시오. 오리엔테이션과 같은 미묘한 미묘한 것조차도 중요합니다.

정직한 긍정적 인 피드백 제공

다수의 연구에 따르면 나쁜 행동을 처벌하는 대신 좋은 행동을 보상 할 때 정보가 더 빨리 학습되고 더 잘 유지된다는 것이 밝혀졌습니다. 때로는 단순한 "좋은 직업"또는보다 구체적인 "성능이 우리의 표준을 티, 훌륭한 작업에 일치시키는 것으로 나타났습니다." 이러한 개선에 대한 인식을 보완하여 수정 한 문제에 대해 다른 사람에게 주니어 개발자와 그의 작업에 큰 영향을 줄 수 있다고 조언합니다.

그 사람은 비판을 받고 기꺼이 배울 의향이 있지만, 물건을 얼마나 밀어야할지 의심이 듭니다.

당신이 할 수있는 모든 것을 미십시오. 그 사람이 배우고 있고 코드를 검토하는 것이 당신의 일이라면, 당신은 그가 좋은 일을하면 많은 것을 얻을 수 있습니다.

즉, 앞으로 검토 할 코드가 줄어들고 팀에 채용 대상이 될 수 있습니다.

또한, 당신이 물러 서면, 당신은 도움이 아니라 후원입니다.

너무 많은 일을하고 있는지 묻는 질문을 여기에 게시했다는 사실 만으로이 특정 조언이 필요하지 않다는 것을 이미 서명했지만 다른 사람들에게는 여기에 있습니다. 얼간이.

멘토가되는 것은 쉬운 일이 아닙니다. 또한 실수를 저지르고 스스로 고칠 수있는 공간을 확보해야합니다. 실제 피해를 입히지 않는 곳에서 그렇게해야합니다.

귀하의 설명을 바탕으로, 나는 "이것이 좋습니다. 내가 다르게했을 몇 가지가 있지만 그다지 중요하지는 않습니다."

당신이 이해하는 것처럼 비판에는 비용이 들며 세부 사항을 파악하는 데 많은 시간을 소비하면 사기 문제가됩니다. 이상적으로는 모든 코딩 표준이 자동으로 확인되므로 표준을 따르지 않으면 빌드 할 수 없습니다. 시간을 크게 절약 할 수 있으며 비즈니스에 전념 할 수 있습니다. '중요한 것'에 대한 비판을 예약하면 조언이 훨씬 더 많은 영향을 미치며 소중한 멘토로 간주됩니다. 좋지 않은 것과 그렇지 않은 것을 구별하는 것이 정말 중요합니다.

나는 가르치는 순간 의 개념을 믿는다 . 개발자의 정신 능력이 충분한 경우, 다른 방식으로 세부 사항을 요구할 수 있습니다. (S) 그는 아닐 수도 있고 괜찮습니다. 사람들은 직장에서 타 버리고 일찍 시작하여 나중에 간단 해 보이는 것을 성취하기 위해 많은 정신 에너지가 필요할 수 있습니다.

나는 그의 작품이 받아 들일 수있는 것이 아니라 완벽 할 때 받아들이는 것을 고려할 것입니다. 그리고 다음 과제는 토론을 마친 후 작지만 중요한 모든 변경 사항을 적용하여 즉시 리팩토링하는 것입니다.

따라서 일이 처음 받아 들여질 때 당신의 메시지는 그것이 나쁘지 않다는 것입니다. 그리고 어떤 곳은 그것을 충분히 잘 받아 들였을 것입니다. 그러나 자신의 무역을 제대로 배우기를 원하는 주니어 개발자가되고 싶은 곳은 아닙니다.

그래서 당신은 "충분하지 않기 때문에 당신의 일을 거부합니다"라고 말하지 않습니다. 당신은 (a) "충분히 잘해서 당신의 일을 받아들입니다"라고 말한 다음, (b) "하지만 더 잘하고 싶습니다"라고 말합니다.

꽤 광범위한 질문이지만 여기 몇 가지 아이디어가 있습니다.

1. 동료 리뷰 (주니어 개발자에 의한)

   누군가가 "올바른"방법을 배우는 가장 좋은 방법은 다른 사람들이 그것을하는 것을 보는 것입니다. 모든 개발자가 코드 검토를 수행합니까? 하급 개발자가 수행하도록하는 것도 좋지 않은 생각이 아닐 수도 있습니다 (선임 개발자의 검토도 하나 이상 받아야 함). 그렇게하면 좋은 코더가 작동하는 것을 볼 수있을뿐만 아니라 자신 이외의 엔지니어를 대상으로 한 리뷰 의견이 있다는 것을 알 수 있습니다.

2. 조기 피드백 / 작업 검토

   개발자가 자신의 작업 분류에 참여할 수 있도록합니다. 작업 노트에 의도 한 디자인을 기록하고 변경 세트가없고 작업만으로 "코드 검토"를 제출하게하십시오. 그렇게하면 한 줄의 코드를 작성하기 전에 계획을 검토 할 수 있습니다. 그의 작업이 검토되면 코딩을 시작할 수 있습니다 (그 후 다른 코드 검토를 제출 함). 이것은 개발자가 많은 것을 썼고 그것을 다시 써달라고 해야하는 강렬한 상황을 피합니다.

코드가 객관적인 서면 표준을 객관적으로 위반하는 경우 모든 문제가 해결 될 때까지 계속 밀어 내야한다고 생각합니다. 물론, 처음 몇 번의 커밋은 개발자에게는 약간 성가신 일이지만 나중에 가이드 라인을 더 빨리 배울 수도 있습니다.

또한, 여기저기서 몇 가지 표준 위반을 허용하면 잘못된 선례를 볼 것입니다. 깨진 창 이론을보십시오 . 또한 표준이 이미 코드베이스에 일관되게 적용된 경우 표준을 따르는 것이 훨씬 쉽습니다. 문제의 주니어 개발자를 포함하여 모두가 승리합니다.

코딩 표준이 기록되어 있다면 사기가 큰 문제라고 생각하지 않습니다. 그것이 더 주관적인 "잘, 나는 다르게 다르게 했었을 것이다"영역에 들어간 경우에만 개발자의 접근 방식이 똑같이 유효 할 수 있기 때문에 걱정해야한다.

개발자가 제안 된 커밋을 Github Pull Requests 또는 Phabricator Diffusion과 같은 도구에 게시하고 변경 사항을 공유 마스터 브랜치에 적용하기 전에 피어 사인 오프를 얻는 코드 검토 워크 플로 채택을 고려하십시오.

이런 식으로, 이미 수행 한 작업을 소급하여 비판하거나 다른 사람에게 다시 요청하도록하는 대신, 동료 검토를 통과 할 때까지 작업은 아직 완료되지 않았습니다 . 피어와의 앞뒤는 컴파일러의 앞뒤와 마찬가지로 소프트웨어 엔지니어링 프로세스의 일부입니다.

특정 라인에 대한 의견으로 우려 사항을 게시하고 이에 대한 토론을 할 수 있습니다. 그는 당신의 코드와 똑같이 할 수 있습니다. 토론은 제안 된 특정 코드 변경에 중점을 두며 일반적으로 누군가의 성과 나 역량이 아닙니다.

우리 회사의 뛰어난 수석 엔지니어조차도 코드 검토가 오타를 포착하거나 더 명확하게 만들도록 강요 할 때 감사합니다. 신입 사원이 더 많은 라운드를 요구하는 것은 완전히 정상입니다. 시간이 지남에 따라 diff 를 게시 하기 전에 의견을 유치 할 수있는 문제의 종류를 재귀 적으로 수정하기 시작 합니다. 첫 번째 시도에서 더 높은 비율의 디프를받는 것은 당신이 개선하고 있다는 것을 아는 방법입니다.

나는 초심자에게 사소한 세부 사항처럼 보일 수있는 코드를 지속적으로 되돌려 보내지 않습니다. 이는 매우 실망 스러울 수 있지만 너무 '부드럽다'는 것은 남자가 어떤 일을하는 법을 배우지 못할 수도 있다고 걱정하고 있습니다.

이것들은 실제 가능성과 타당한 관심사입니다. 개발자에게 어떻게 느끼는지 물어보세요.

풀 요청 또는 코드 검토 워크 플로우가 있다고 가정하고 "그렇지 않은"또는 "선호"항목을 언급하는 것이 좋습니다.

약간의 문체 문제가 있거나 중요하지 않은 리팩토링이 필요한 설명과 유사한 상태로 PR이 표시되는 경우 의견을 남기고 자유롭게 승인하십시오. "미래에, descriptiveMethodName과 같은 것을 선호하여 이와 같은 메소드 이름을 피하려고 노력할 것"과 같은 말은, 그것을 변경하거나 개발을 방해하지 않으면 서 의견을 문서화합니다.

이제 그들은 당신의 선호도를 알고 있으며, 개선하려고한다면 앞으로 그러한 상황을 알기를 바랍니다. 또한 그들이 당신과 동의하고 충분히 중요하다고 생각할 때 실제로 문을 열어 놓을 수 있도록 문을 열어 둡니다.

코딩 공장에서 원격으로 일하는 하급 개발자를 상대하고 있습니다.

불행히도 이상적인 상황은 아니다 : 지리적으로 분리 된 한 명의 초보자 프로그래머를 담당하는 한 명의 고급 프로그래머. 약간의 긴장이 있다는 것은 놀라운 일이 아니지만, 시차가 완화 될 수 있습니다.

궁금합니다. "코딩 팩토리"란 무엇을 의미합니까? 이 용어는 나에게 언급 한 일부 관리 문제를 악화시킬 수있는 문제를 나타냅니다.

… SRP, 신의 대상, 방법이나 변수에 대한 의미없는 이름의 위반; 나는 그가 고쳐야 할 것을 지적하고 그것이 왜 잘못되었는지 설명하려고 노력한다.

문제는 주니어 개발자가 적절한 디자인 프로세스를 거치지 않고 코드를 뿜어내는 것입니다. 이것은 관리자 및 선임 개발자로서 지침을 제공하고 훌륭한 소프트웨어 개발 습관을 가르치는 데 실패한 것입니다. 처음에 함께 스케치 작업을하면 잘못된 코드가 작성되는 것을 방지 할 수 있습니다. 효율성과 사기 측면에서 코드가 생성 된 후에 비판하고 재 작성하는 것이 바람직합니다.

워크 플로우를 다시 조정해야 할 수도 있습니다. 당신이 현재 그가 당신에게 제품을 제공하기를 기대하고있는 것 같습니다. 필요한 것은 긴밀한 협업이므로 모든 개발 단계에서 지침을 제공 할 수 있습니다. 코딩이 시작되기 전에 디자인과 인터페이스에 대해 이야기하십시오. 코딩이 진행되는 동안 더 자주 체크 포인트를 수행하여 문제를 조기에 파악하십시오. 가능하면 오디오 채널과 화면 공유를 통해 페어 프로그래밍을 시도하십시오.

이 모든 것에는 더 많은 노력이 필요하지만 현재 가지고있는 문제가있는 관계를 고려하면 가치가있을 것입니다.

코딩 표준을 위반하는 경우 알고있는 위치를 보여줍니다. 같은 실수를 계속해서 보여야한다면 규칙을 따르지 않거나 거부하는 사람에게 문제가있을 수 있습니다. 실수를 고치기 위해 여가 시간을 사용하지 마십시오. 이 사람은 자신의 오류를 수정하여 다시 만들지 않도록해야합니다.

항상 그들이 옳은 일과 다음에 어떻게 개선 할 수 있는지 이야기하십시오. 우리는 항상 어떤 지역에서 나아질 수 있습니다. 피드백은 무엇이든 개선하는 데 중요합니다.

"너무 많은 비판"을 다루기위한 또 다른 아이디어는 때때로 혼자서 작업을 수행하고 하급 개발자가 코드 검토를하도록하는 것입니다. 이것은 적어도 두 가지 장점이 있습니다.

• 그들은 어떻게해야하는지 배울 수 있습니다.
• 여러 가지 좋은 솔루션이나 변수 이름이있는 경우 다른 (거의?) 똑같은 좋은 접근 방식의 제안을 받아들입니다. 누군가의 의견 때문에 내 코드를 고치면 사람들이 존중한다는 것을 보여주고 있으며 저자가 누구인지에 관계없이 비판은 항상 코드에만 관련됩니다.