몇 년이 지난 후에도 직원이 계속 잘못된 코드를 작성해야합니까? [닫은]

a) C ++ 프로그래머 만이 예제의 기술적 장점을 판단 할 수 있습니다. b) 프로그래머 만이 이와 같은 코드를 작성하는 다른 프로그래머의 기질을 느낄 것입니다.

HR과 이사들은 단순히 현장에서 증거를 볼 수 있기 때문에 문제가 있음을 알고 있습니다. 우리가 문제의 프로그래머에게 더 많은 시간을 줄지 여부는 저의 전화입니다. 많은 오류는 매우 기본적인 수준에 있습니다. 프로그래머에게 내 질문은 수석 C ++ 개발자라고 공언하는 사람이 현재 코드 샘플을 기반으로 의심의 혜택을 받아야하는지 여부입니다. 프로그래머가 아닌 사람들, 심지어 C ++ 프로그래밍 외부의 사람들조차도 이것에 대해 판단 할 수 없습니다.

배경을 위해, 저는 잘 설립 된 회사의 개발자를 관리하는 임무를 맡았습니다. 그들은 모든 C ++ 코딩을 전문으로하는 단일 개발자를 가지고 있지만 (영원히) 작업의 품질은 끔찍합니다. 코드 검토 및 테스트 결과 메모리 누수 중 최악의 문제 중 하나 인 많은 문제가 밝혀졌습니다. 개발자는 자신의 코드에서 누수를 테스트 한 적이 없으며 애플리케이션을 1 분만 사용하면 많은 MB가 누수 될 수 있음을 발견했습니다. 사용자는 엄청난 속도 저하를보고했으며 "나와는 아무 상관이 없습니다. 종료했다가 다시 시작하면 다시 시작됩니다."

누수를 감지하고 추적 할 수있는 도구를 제공했으며 도구 사용 방법, 문제 발생 위치 및 해결 방법을 시연하기 위해 몇 시간 동안 그와 함께 앉았습니다. 6 개월이 지났고 새 모듈을 작성하도록 지명했습니다. 더 큰 코드베이스에 통합되기 전에 검토했으며 이전과 동일한 나쁜 코딩을 발견하지 못했습니다. 이해할 수없는 부분은 코딩의 일부가 아마추어보다 나쁘다는 것입니다. 예를 들어, 그는 다른 클래스 (Bar)의 객체를 채울 수있는 클래스 (Foo)를 원했습니다. 그는 Foo가 Bar에 대한 참조를 보유하기로 결정했습니다.

class Foo {
public:
    Foo(Bar& bar) : m_bar(bar) {}
private:
    Bar& m_bar;
};

그러나 (다른 이유로) 그는 Foo의 기본 생성자가 필요했으며 초기 디자인에 의문을 제기하지 않고이 보석을 썼습니다.

Foo::Foo() : m_bar(*(new Bar)) {}

따라서 기본 생성자가 호출 될 때마다 Bar가 누출됩니다. 설상가상으로 Foo는 2 개의 다른 객체에 대해 힙에서 메모리를 할당하지만 소멸자 또는 복사 생성자를 작성하지 않았습니다. 따라서 Foo의 모든 할당은 실제로 3 개의 서로 다른 객체를 유출하므로 Foo를 복사 할 때 무슨 일이 있었는지 상상할 수 있습니다. 그리고 그것은 더 나아졌습니다-그는 다른 세 클래스에서 같은 패턴을 반복했기 때문에 일회성 슬립이 아닙니다. 전체 개념은 여러 수준에서 잘못되었습니다.

이것이 완전한 초보자로부터 온다면 더 많은 이해를 느낄 것입니다. 그러나이 사람은 몇 년 동안이 일을 해왔으며 지난 몇 달 동안 훈련과 조언에 매우 중점을 두었습니다. 나는 그가 대부분의 시간 동안 멘토링이나 동료 리뷰없이 일하고 있다는 것을 알고 있지만, 그가 바꿀 수 없다고 느끼기 시작했습니다. 그래서 내 질문은, 당신은 분명히 나쁜 코드를 작성하는 사람과 함께 할 것입니까?

저의 충고는이 특정한 예에 관해 그에게 맞서고 그가 말하는 것을 보는 것입니다. 그가 코드에 문제가 있다고 거부하면 할 수있는 일이 거의 없을 것입니다. 그가 실수했다는 것을 받아들이면 (그가 방어 적이라고해도) 최소한 개선의 여지가있다. 당신이 그를 향상시키기위한 시간과 노력을 받아 들인다면, 당신이나 상급 프로그래머는 모든 경향이 평평해질 때까지 그를 앉히고 함께 코딩해야합니다 (적어도 1 개월 동안이 사람을 바칠 준비를하십시오).

나쁜 프로그래머, 나는 보통 함께 일할 수 있지만, 개선 할 수없는 프로그래머는 할 수 없습니다.

그래서 내 질문은, 당신은 분명히 나쁜 코드를 작성하는 사람과 함께 할 것입니까?

아니요. 메모리 관리에 대한 기본 지식이 부족한 전문 C ++ 개발자를 해고 할 것입니다.

누군가 Java 또는 C # 또는 다른 곳에서 온 사람이라면 위도를 줄 것입니다. 그러나 이것은 순수한 무능력입니다.

귀하의 질문에 대한 광범위한 답변을 드릴 수 없습니다. 즉, 그 직원을 유지하거나 해고해야합니다. 직원을 해고하는 것은 어렵지만 이는 이와 같은 커뮤니티의 범위를 벗어난 결정입니다.

C ++ 프로그래머에 대한 답변을 제한하기 위해 질문을 업데이트했습니다. 내 배경 / 자격 : C로 치아를 자르고 C ++, C # 및 Java로 코딩 할 수 있습니다. 그리고 재미 있다고 생각하기 때문에 스레드 간 경쟁 조건을 추적하고 싶습니다. 그렇습니다, 나는 조금 꼬집고 있습니다.

이 주위에 당신의 대답과 의사 결정 랩 :되는지 여부 누군가 캔 변화는 개인에 의존하고 있다면 그들은 변경하고 싶습니다.

그러나 몇 가지 질문으로 시작합시다.

1. 언급 한 코드와 예제에 대해 그에게 물었습니까? 그의 리뷰에 대한 그의 인상은 어떠 했습니까?
2. 6 개월 동안 메모리 조작을 이해하고 코드에 메모리 누수가 없는지 확인하는 방법에 대해 구체적으로 설명했습니까?
3. 6 개월 동안 그가 진척 중인지 아닌지를 나타 내기 위해 합리적으로 빈번한 피드백을 제공하고있었습니다.
4. 그의 이전 코딩 방식이 더 이상 새로운 코드에서 허용되지 않는다고 명시 적으로 지적 했습니까?

모든 질문에 예라고 말할 수 있어야합니다. 그렇지 않다면 여전히 그와 의사 소통을해야한다는 증거의 부담이 있습니다.

최근 리뷰에 대한 그의 답변이 가장 중요합니다.

그가 노력하고 있고 진행의 징후가 보이면 멘토링 프로세스를 검토해야 할 수도 있습니다. 어쩌면 더 경험이 풍부한 프로그래머와 그를 연결하여 디자인 결정을 내릴 때 즉각적인 피드백을 얻을 수 있어야합니다. 나는 페어 프로그래밍의 팬이 아니지만 이런 경우에 매우 유용 할 수 있습니다. 오래된 코드를 계속해서 수정하기 위해 계속 파견하는 것이 항상 실용적인 학습 경로는 아닙니다.

그가 시도하지 않았다면 그의 동기를 더 잘 이해해야합니다. 그는 이해하지 않았 필요 열심히하려고? 그는 신경 쓰지 않습니까? 팀에 그의 기술이 더 잘 맞고 그에 더 관심이있는 다른 영역이 있습니까? 그가 노력하지 않는다면, 왜 그런지 이해해야합니다.

거기에서, 당신은 그가 변경하고 싶은지와 그가 바꿀 수 있는지 알 수 있습니다. 변화하려는 욕구는 변화 할 수없는 것과 같습니다. 욕구와 어느 정도의 발전이 있다면, 그를 회복시키는 방법을 바꾸는 것을 강력히 고려하십시오.

그의 나쁜 코드가 당신 팀의 유일한 문제는 아닙니다.

1. 누가 자신의 코드를 검토합니까? 메모리 누수 취약점이있는 코드를 수락한다는 경고없이 왜 빠져 나갔습니까?
2. 스트레스 테스트에서이 문제를 찾지 못한 이유는 무엇입니까? 당신은 그들을 사용합니까? 그렇다면 왜 작동하지 않습니까?
3. 그는 오랫동안 무인 상태로 남아있었습니다. 왜?
4. 그는 당신이 그에게 준 도구를 사용하고 있지 않습니다. 적절한 도구를 사용하도록 어떻게 동기를 부여 했습니까?

당신은 그가 오랫동안 회사에 있었다고 말합니다. 그런 사람을 해고하는 것은 좋은 생각이 아닙니다 (월리 형 직원이 아닌 한). 고객의 요구, 소유 한 제품 등에 대한 지식은 종종 그들이 작성한 코드보다 훨씬 가치가 있습니다.

솔루션 :

• 피해야 할 사항을 알 수 있도록 QA로 이동
• 자신의 오류를 지적 할 수있는 사람과 프로그래밍
• 그의 코드에 대한 확장 된 QA 노력
• 10k의 객체를 생성하고 파괴 한 후 개발 기기가 충돌하는 것을 본다면 스트레스 테스트를 작성하게 할 것입니다.
• 위의 몇 가지 / 모두 :)

누군가를 해고하기로 결정하는 것은 누구나 어려운 결정입니다. 당신의 상황은 여러 가지 요인에 의해 복잡해집니다 :

1. 이 개발자는 몇 년 동안 회사에서 근무한 것으로 보입니다
2. 개발자는 모든 회사에 C ++ 코드를 작성합니다
3. 아무도 개발자와 나쁜 코드 수준에 대해 논의한 적이없는 것 같습니다.
4. 새로운 관리자로서 당신은 개발자가 누구 / 회사에 대해 알고있는 것과 개발자를 해고 한 정치적 결과가 무엇인지 모릅니다.

지난 6 개월 동안 개발자에게 자신의 방식에 대한 오류를 보여 주었고 그의 새로운 코드는 아직 개선되지 않았다고 말했다.

이 단계에서는 3 개월 이내에 사전 예방 적 관리를 시작해야합니다.

• 자신이하는 일을 아는 괜찮은 C ++ 프로그래머

또는

• 개발자를 종료했습니다.

개발자와 함께 앉아 있어야 할 필요가 있지만이를 작성하려면 글쓰기 / 이메일에 어떤 문제가 있는지 설명하고 개발자가 개선 할 수있는 방법을 설명하고 개선이 예상되지 않으면 실현 될 수 없다고 매우 명확하게 설명하십시오. 개월.

또한이 시점부터 개선이 3 개월 동안이 아니라 회사와의 나머지 고용 기간 동안 예상된다는 점을 분명히해야합니다!

또한 자신의 관리자와 HR 부서 (있는 경우)에게 알려야합니다.

이 과정에서 개발자를 적극적으로 관리하고 1-2 일마다 작업 / 코드를 검토하고 긁히지 않도록해야합니다. 그렇지 않은 작업을 자세히 설명하고 개선을 위해 수행 할 수있는 작업을 설명해야합니다.

당신이 그의 솜씨를 얼마나 심각하게 받아들이고 있는지에 대해 명확하지 않았거나 (즉, 그가 절대적으로 필요하지 않고 개선하기를 원한다면 그가 당신과 함께 보낸 시간을 옵션으로 보았을 수도 있습니다) 지속 불가능한 태도. 이 문제에 대한 자신의 입장을 고려하고 있다는 것이이 개발자에게 아직 명확하지 않은 경우 철자가 필요합니다 (리더십을 종료 할 권한이있는 것으로 가정). 충격은 희망적으로 변화를 가져올 것입니다.

그러나 고용 결정은이 사람보다 훨씬 넓은 의미를 지니고 있으므로 팀에 미치는 영향을 고려해야합니다. 그의 태도가 번영하도록 허용된다면, 그것은 다른 사람들로부터 분개하거나 다른 사람들도 이런 종류의 일이 괜찮다고 느끼게 할 수 있습니다. 그러나 팀의 관점에서 볼 때, 그가 갔다면 올바른 이유였으며 개선 할 충분한 기회가 있었음을 분명히해야합니다.

몇 년 전에 내가 찾은 하나의 보석은 다른 사람들이 가지고 있지 않은 기술적 지식을 가진 사람들이 경영진에게 여유를 줄 수 있다는 사실입니다. 팀에게는 나쁘다. 당신은 유일한 C ++ 개발자를 잃어 버릴까 두려워 할 수도 있지만 교체 할 수 있습니다. 그가 출시 된 제품을 잘 안다면 내재 된 위험이 있지만, 대체로 대체 할 수없는 제품 / 기술 지식을 가진 사람들이 예상보다 더 쉽게 대체되는 것을 보았습니다. 팀과 조직은 종종 처음에는 작성하기 어려운 간격을 메울 수 있습니다. 물론 C ++ 기술이나 조직 고유의 지식이 없어 교체하기가 어렵다고 생각하면 문제가 훨씬 적습니다!

물론해서는 안됩니다. 이것은 자선 단체가 아니며, 일을 위해 돈을 교환하고 있음을 기억하십시오. 그가 거래의 측면을 지키지 않으면 거래를 중단합니다.

그에게 기회를 주려면 메모리 누수에 대한 메트릭을 수집하는 표준화 된 테스트를 개발하십시오. 그가 변경 한 코드 를 보고 , 개선이 필요한지 확인하면서 매주 그의 진행 상황을 모니터링하십시오 . 그가 그 시점에서 관리 할 수 ​​없다면, 쓸모없는 독창성을 해치십시오.