자신의 작업을 문서화하지 않는 스타 개발자는 어떻게 해야 할까요?[닫은]

https://stackoverflow.com/questions/532338

collaboration

22-08-2019
|

문제

자신의 일을 진지하게 아는 동료가 있습니다. 그는 제가 함께 일한 사람 중 가장 뛰어난 사람 중 하나입니다. 하지만 그는 다음과 같습니다.

공용 디렉토리가 아닌 홈 디렉토리의 작은 영역에서 작업합니다. CVS 저장소
그렇지 않다 문서 그의 코드
그렇지 않다 논평 그의 코드, 예를 들어3,500 슬록 주석이 없고 내용을 나누기 위한 빈 줄이 없는 C
종종 상황을 지나치게 복잡하게 만듭니다.하나의 간단한 쉘 스크립트가 수행할 수 있는 작업을 수행하기 위해 서로 호출하는 세 가지 쉘 스크립트를 사용합니다.

혹시 이 사람도 '이걸 나만 알면 날 버릴 수 없어'라고 생각하는 사람이 아닐까?

무엇을 해야할지에 대한 제안이 있으십니까?

BTW 경영진은 상황을 알고 있으며 상황을 바꾸려고 노력하고 있습니다.

해결책

제 생각에는 누군가 위에서 설명한 바보 같은 일을하는 사람은 스타 개발자가 될 수 없습니다! 나에게 그것은 그가 의도적으로 자신이있는 것만 큼 복잡하게 만들어서 다른 사람이 자신이 코드를 유지할 수 없도록하는 것처럼 보인다. 이것은 자신보다 더 중요합니다! 그와 이야기하십시오. 그는 그것을 바꿔야합니다! 그가 그렇지 않다면, 그를 진짜 스타 개발자로 교체하십시오!

반년 안에 그는 자신의 코드가 어떻게 작동하는지 알지 못할 것이라고 약속합니다! 그를 해고하면 많은 시간과 돈을 절약 할 수 있습니다.

다른 팁

CVS 부분은 쉽습니다 - "우발적 인"하드 드라이브 실패는 그에게 인생을위한 교훈을 가르쳐 줄 것입니다 (실제로 코드를 잃지 않도록 백업을해야합니다).

그것은 힘든 상황처럼 들립니다.

개인적으로, 나는 그를 놓아 줄 것입니다. 그는 스타 개발자 일지 모르지만 팀 선수는 아닙니다. 좋은 제품을 만들려면 함께 일할 수있는 응집력있는 팀이 필요합니다.

문서화 실패는 직업 안보를 보장하는 (매우 나쁜) 방법입니다.

이에 대응하기 위해 몇 가지 작업을 수행 할 수 있습니다.

개인 성과 검토를위한 요구 사항으로 문서를 추가하십시오.
문서화되지 않은 소프트웨어를 수락하지 마십시오.
개발자와 한마디 도와 그가 문서화하지 않는 이유를 알아보십시오.
멋진 문서 도구를 구입하십시오.

을하다 나쁜 경찰/좋은 경찰 영화에서 본 스케치. 경영진이 나쁜 경찰이되고 당신은 좋은 경찰이되게하십시오. 관리자가 그의 작품에 대한 과잉 사망 문서와 분당 지퍼 백업을 요청하게하십시오. 그러나 당신은 그에게 적당한 문서 (예 : Doxygen)와 일반적인 소스 제어 체크인을 제공합니다 ...

그와 이야기 하시겠습니까?

그가 실제로 "스타 개발자"라면 그는 당신이 말하는 것을 기록 할 것입니다.

그것은 밤새 그를 바꾸지 않을 수도 있지만 다른 사람들이 자신처럼 그것을 얻지 못한다는 것을 완전히 알지 못할 수도 있습니다.

편집하다:

아마도 지금 변경하는 것은 조금 늦었을 것입니다. 그러나 솔루션을 해결하려면 더 많은 정보가 필요합니다. 여기 누군가가 실제로 그 지점만으로 그 사람을 놓아 두게하는 것은 불가능합니다. 작년에 매일 그 사람에게 그가 변화가 필요하거나 여기에서 나가야한다고 말하면, 당신은 그를 놓아 줄 수 있습니다. 그러나 나는 그 증거가 없습니다.

화려한 개발자는 소스 제어, 댓글 및 문서를 사용하도록 배울 수 있습니다. 당신이 여기서 노력을 소비한다면, 당신은 진정으로 스타 개발자를 가질 것입니다.

여기에서 잘못된 영역에 집중하고있을 수 있습니다. 프로세스에서 약점을 볼 수있는 기회가 제공됩니다.

일반적인 CVS 저장소보다는 자신의 홈 디렉토리의 작은 영역에서 작동합니다.

간단한 채팅은 아마도 여기에서 충분할 것입니다. 버전 제어의 이점은 스스로를 말하고 "밝은"사람은 그러한 이점에 대해 열정적 일 것입니다. 그러나 더 큰 사용 편의성과 유연성을 허용하는 대체 버전 제어 시스템을 살펴볼 수있는 좋은 기회 일 수 있습니다 (BZR 및 GIT를 살펴보십시오). 더 나은 방법으로, 그가 선택 과정에 참여하게하십시오. 그가 실제로 "별"이라면 아마도 좋은 입력을 가지고 있고 그 사용에 더 많은 투자를받을 것입니다.

그의 코드를 문서화하지 않습니다

문서가 귀하의 프로세스의 일부인 것처럼 들리지 않습니다. 사람들은 추가 작업을해야한다는 것을 저항 할 것이며 정의 된 과정이 없다면 많은 추가 작업에 대해 이야기하고 있습니다. 문서가 정말로 필요합니까? 그렇다면 생성을위한 프로세스가 정의되어 있습니까? 완전히 헌신 한 사람이 있어야합니까? 최소한 그것을 용이하게하는 도구가 있어야합니까 (미디어 위키만큼 간단한 것)?

그의 코드에 주석을주지 않습니다.

세 단어 : 피어 코드 검토. 명백한 오류가 발생하는 이점을 제외하고, 이것은 또한 약간의 동료 압력을 제공 할 수 있으며, 이는 강력한 힘이며 좋은 일이 될 수 있습니다. 동료들에 의해 잘 인식되기를 원하면 소유권과 품질이 자체적으로 생성됩니다.

예를 들어, 예를 들어, 하나의 간단한 쉘 스크립트가 할 수있는 작업을 수행하기 위해 서로 전화하는 세 개의 쉘 스크립트를 사용합니다.

다시 한 번 피어 코드 검토. 경영진은이 프로그래머의 결함에 대해 알고 있다고 언급합니다. 그는? 사람들이 자신이하는 방식의 문제를 인식하지 못하면 변화하고 개선하기가 다소 어렵습니다.

그리고 아마도 무엇보다도, 개발 프로세스를 개선하려는 계획을 세우면 ( "스타"뿐만 아니라 팀의 다른 모든 사람들을 향상시킬 수 있음) 경영진으로부터 자신을 위해 골드 스타를 얻을 수 있습니다.

나에게 별 프로그래머처럼 들리지 않습니다. 모든 훌륭한 프로그래머는 소스 제어의 코드 형식 및 사용이 중요하다는 것을 알고 있습니다. 그는 혼자서 좋은 진전을 이루고 있지만 다른 팀원의 진보를 방해하고 있으며, 이는 작업이 끝나는 일에 순 부정적인 영향을 미칠 수 있습니다. 그에게 말하고, 그가 그의 관행을 바꾸기를 거부한다면, 그를 놓아주십시오.

그가 정말 똑똑하고 당신이 그의 방식을 바꿀 수 없고 그를 잃고 싶지 않지만 여전히 당신의 코드가 문서화되고 주석 처리되기를 원한다면 경험이 적은 개발자에게 문서화와 주석 작성을 하도록 하는 것이 내 제안이 될 것입니다.개인적으로 내가 스타 개발자라면 다른 사람이 내 코드에 주석을 달고 결국에는 내가 직접 그 일을 시작하게 되면 꽤 어리석은 기분이 들 것입니다.그런 일이 발생하지 않는 동안 경험이 부족한 개발자는 한두 가지를 배울 수 있습니다.

훌륭한 프로그래머가되는 것보다 스타 개발자가되는 것이 더 많습니다. 팀 기술이없고 의도적으로 팀 표준을 무시하고 있다면 그에게 제기해야합니다. 그가 경영진과 대화 한 후 그들을 준수하지 않는다면, 아마도 그는 당신의 회사에 적합하지 않을 것입니다.

이 질문은 나를 긴장하게 만듭니다. 당신이 묘사하는 사람이 엄청나게 들리기 때문에 나는 그에게 약간의 것을 볼 수 있기 때문입니다.

나는 꽤 좋은 팀 선수라고 생각하고 아주 좋은 팀에있어 운이 좋다. 그러나 나는 동료들이 이해하지 못하는 방법을 사용하지만 설명하기 위해 꽤 열심히 노력했습니다. 꽤 큰 경험 차이가 있는데, 우리 중 누구도 반영하지 않습니다.

문서는 광범위하고 까다로운 주제입니다. 나는 마른 (스스로 반복하지 말) Maxim을 따르려고 노력합니다. 코드와 분리 된 문서는 자신을 반복하는 데 금액이 될 수 있으므로 최신 상태를 유지하기 위해 속도를 늦추지 않으면 현재 구제 할 수 있습니다. 나의 일반적인 접근법은 나중에 그것을 터치하는 것입니다.

종종 내가 작업하고있는 문제는 너무 까다로워서 계획을 세우고 원하는 모든 것을 문서화 할 수 있지만 코드와 관련하여 종종 내가 틀렸다는 것을 발견하고 다시 생각해야한다는 것을 알게됩니다. 따라서 사전에 물건을 문서화 할 수 있다는 생각은 그냥 따라야합니다. 단지 간단한 문제에만 적용됩니다.

어쨌든, 나는 이것이 훌륭한 질문이라고 생각하며, 대답은 전혀 간단하지 않습니다.

그 남자는 정말로 록 스타입니까? 진지하게? 잠시 생각해보십시오. 그는 똑똑하지만 일을 끝내지 않거나 똑똑하고 일을 할 수 있습니까?

정말 힘들어 생각합니다.

그가 정말로 록 스타라면, 당신은 그를 엉망으로 만들지 않아야 할 것입니다. 그는 자신의 과정을 사용하여 엄청나게 멋진 것들을 생산하고 있습니다. 당신에게 가장 적합한 일을하는 다른 방법이 있다고해서 그것이 그의 최선의 일을 할 수 있다는 것을 의미하지는 않습니다. 그를 당신의 과정에 구부리려고 노력하는 대신, 그의 모든 굉장함을 죽일 수있는 당신은 그가 일하는 방식을 수용 할 수있는 방법을 찾아야합니다.

그가 당신이 말하는 것처럼 정말 좋다면, 당신은 그렇게하는 것을 신경 쓰지 않아야합니다. 그렇게하려는 노력의 가치가 없다면, 그는 그렇게 좋지 않습니다. 이 경우, 당신은 록 스타가없고, 당신은 규칙이되는 것을 좋아하지 않는 평범한 프로그래머 만 있습니다. 그 사람들, 당신은 그냥 제거해야합니다. 그러나 기질 록 스타는 일반적으로 자신이 생산할 수있는 품질 때문에 고통의 가치가 있습니다. 그 사람들, 당신은 유지하기 위해 많은 시간을 가야합니다.

자신의 직업에 지루하고 더 많은 도전을하기 위해 물건을 복잡하게하는 스타 프로그래머처럼 들립니다. 그는 곧 더 나은 것을 찾을 것입니다.

일을 바꾸려고? 문서화되지 않은 작업 소프트웨어 또는 잘 문서화 된 쓰레기를 선호합니까? 어떤 사람들은 댓글이 거의 없거나 전혀 필요하지 않은 소프트웨어를 쓸 수 있습니다. 이는 품질의 신뢰할 수있는 지표가 아닙니다.

좋은 개발자를 잃을 까봐 두렵습니다.

"안녕하세요 스타 개발자,

다음 주부터 코드에 대한 문서화가 필요하고 코드에 도움이되는 댓글을 달성 할 것입니다. 회사 정책이 될 것이며 예외는 없습니다. "

그 이후로, 당신은 그 실패를 제 시간에 켜지지 않을 것과 동일하게, 직장에서 oofing을 막지 못하는 것과 동일하게 다루는 것입니다. 일을 제대로하지 않습니다.

그가 이런 식으로 일하고 있다면, 그는 스타 개발자가 아닙니다. 훌륭한 소프트웨어 개발자는 유지 관리가 매우 중요하다는 것을 이해합니다. 당신은 아마도 장기적으로 이것에 대해 대가를 치를 것입니다. 나는 이것이 얼마나 심각한 지에 대해 그와 매우 직접적이며 조정을 시작할 수 없다면 그를 보내 게 할 것입니다. 나는 이것을 전에 많은 시간을 보았고 그것은 시한 폭탄입니다.

솔직히 말해서, 나는 이와 같은 많은 개발자들을 보았으며, 학교를 떠나지 않으면 변하지 않을 것입니다. 나는 지금 당신의 무손실을 자르고 있다고 말합니다.

그가 정말로 밝다면 경영진이 그를 제거 할 가능성은 거의 없습니다.

물론 전체 프로젝트가 닫힐 수 있지만 어쨌든 CVS와 문서에는 사용되지 않을 것입니다.

어떤 경영진도 나쁜 프로그래머를 고용하기 위해 좋은 프로그래머를 해고하지 않습니다.

도움이 될 것이라고 말하십시오 그를 그가 원할 때마다 관리를 제거합니다.

그는 무엇을 바꾸고 싶어 하는가? 그는 경영진에게 다음과 같이 말할 수 있습니다. "좋아요, 사람들, 모든 것이 당신이 나에게 물었던 것처럼 : 체크인, 문서화 및 당신의 통제를 통제합니다. 나는 내 부분으로 끝났고, 나는 포장하고 떠납니다."

팀이 그와 함께 성공할 수 있습니까? 그렇다면 문제를 밀고 제대로 문서화되지 않았거나 다른 표준을 충족하지 않는 코드를 수락하지 않습니다. 바라건대 이것은 요점을 가로 질러 갈 것이지만 그것은 단지 그를 화나게 만들고 그를 그만 둘 수 있습니다. 팀이 그와 함께 성공할 수 없다면 시간과 노력의 가치가없는 그의 기술 수준까지 교체품을 훈련시킬 수있을 때까지 운이 좋지 않습니다.

+1 Ocdecio- 스타 개발자라면 그의 코드는 자체를 문서화하는 고품질 디자인을 기반으로해야합니다.

그러나 좌절감은 그가 자신에게 흥미로운 기술적으로 따르는 영역에서 우수하지만 기능을 제공하는 데 어려움을 겪지 않을 수 있습니다.

"구루"를 사용할 수있게되면 절대적인 생명을 구할 수 있습니다. 또는 적어도 예전 이었습니까?

코드 검토가 통과 될 때까지 코드를 릴리스하지 말고 현재 기능/프로젝트에 대해 작성한 코드에 대한 의견 및/또는 문서가 충분한 경우에만 통과 할 수 있습니다.

편집하다 그의 평가에 그것을 가져 오십시오. 그의 "개선 영역"에 대해서는 문서 / 댓글 코드를 제공 할 수 있습니다.

:-)

또한 충분히 문서화 될 때까지 코드를 체크인하는 것을 방해하는 자동 품질 검사를 추가 할 수도 있습니다.

그것은 당신이 그를 처음에 체크인하도록 설득 할 수 있다면! (필수적, IMO)

여기에는 "댓글 없음"에 많은 사람들이 있습니다. 여기서 악 대차. 댓글이없는 문맹 코드는 완벽하게 가능하지만 누군가가 똑똑하고 의견을 말하지 않기 때문에 반드시 문맹 코드를 작성한다는 의미는 아닙니다.

그러니 명확히합시다. 당신은 이미 그가 의견이나 별도의 문서로 자신의 코드를 전혀 문서화하지 않았으며 소스 컨트롤을 사용하지 않는다고 말했습니다. 어때요 :

의견이 부족 했음에도 불구하고 그의 코드는 이해할 수 있습니까?
팀이 참여하는 모든 종류의 문제 추적 (예 : Fogbugz, Bugzilla 등)을 사용합니까?
그의 코드는 테스트 중입니까?
팀에 실제로 코드가 어떻게 작동하는지에 대해 다소 익숙한 다른 사람이 있습니까?
그는 적어도 팀의 나머지 팀과 함께 일하는 방식을 변화시킬 수 있다는 것을 인정하고 있습니까?

이 모든 질문에 대한 답이 "아니오"라면 큰 문제가 있습니다. 똑똑하다고해서 반드시 누군가를 자산으로 만드는 것은 아닙니다. 그가 내일 회사를 떠나지 않거나 버스에 맞지 않을 것이라는 보장이 있습니까? 그런 일이 발생하면 얼마나 망가 졌을까요? 위험이 가치가 있습니까?

나는 이것이 어떤 환경에서나 전형적인 것으로 생각합니다. 누군가가 원하는 것을 어떻게 할 수 있습니까? 이것이 바로 "친구를 이기고 사람들에게 영향을 미치는 방법"이 모든 것입니다. 데일 카네기는 조작에 관한 것이 아니라 사람들을 관리하는 것이 었습니다.

그가 단지 경험이없고 경험과지도가 필요한 것처럼 들립니다.

앉아서이 문제에 대해 그와 이야기 할 수 있다고 생각하십니까? 누군가가 잘못하고있는 사람에게 말하는 경우가 종종 (특히 우리가 다른 사람들의 감정을 상하게하고 싶지 않은 오늘날의 서구 사회에서), 나는 당신이 문제를 침착하고 정직하게 설명함으로써 멀리 갈 수 있다고 생각합니다. 그들을 통해 이야기합니다. 그 사람이 당신과 당신의 의견을 존중하는 경우 도움이됩니다. 이것은 완전히 다른 문제이며 위에서 언급 한 책에서 이야기됩니다. 그가 이것들이 심각한 문제라는 것을 이해하도록하십시오. 또한 미래의 개발 일자리에서 그는 이런 일도 할 것으로 예상되므로 지금 연습하는 것이 좋습니다.

다음 공연 검토까지 기다리는 것이 좋은 생각이라고 생각하지 않습니다. 많은 부정적인 피드백을 쌓고 한 번에 그것을 전달하는 것은 나쁜 생각 일뿐입니다.

코드 문서는 과도하게 평가되었습니다. CVS 교육은 쉽습니다.

좋은 수업은 방법과 속성을 통해 그 목적을 밝혀야합니다.

응용 프로그램 외부에서 모델을 문서화하는 것도 흐르고 이해하기가 더 쉽습니다.

나는 당신이 그것을 얻을 수 없다면, 당신이 스타 개발자를 잃을 것 같다.

편집 : oops- 많은 수입품에 CVS 대신 CSV를 사용했으며 SVN HEH를 사용합니다.

자동 실행 검증 도구를 사용하도록하십시오. (내 대답을 참조하십시오.불완전 주의자에게 질문하는 방법?")
그가 과도하게 복잡하고 SCC를 사용하지 않으면 그는 ~ 아니다 훌륭한 개발자 - 이러한 것들은 소프트웨어 엔지니어링의 중요한 부분입니다.
그가 알고리즘과 같은 영역에서 대체 할 수없는 광채를 가지고있을 가능성이 거의없는 사건에서, 그 영역에서 일하도록 할당하고, 예를 들어 알고리즘을 정의하고, 실제 프로그래머가 코딩을하도록하십시오.
정적 분석 코드를 사용하여 코드를 이해하고 정리하십시오.

페어 프로그래밍. 방금 나열된 요구 사항에 대해 "완료"할 히마 쌍을 찾으십시오. 당신은 문제를 해결할 것입니다. 제어, 문서화, 그의 행동마다 질문 등을 소스 할 수 있습니다. 또한 첫 번째 사람의 힘을 사용하여 다른 사람을 훈련시킵니다.

당신이 묘사 한 바에 따르면,이 동료는 분명히 있습니다 ~ 아니다 스타 개발자. 프로그래밍은 팀 스포츠이며 다른 사람들과 잘 어울리지 않는 사람들은 프로젝트에 많은 가치를 더할 수 없습니다.

개인적으로, 나는 6 개월 이상 전에 쓴 코드를 기억하지 못할 수도 있고, 일종의 소스 제어의 변화의 역사를 매우 중요하게 생각합니다.

당신 이이 사람과 정기적 인 코드 리뷰를 가지고 있다면, 당신은 그가 당신이 생각하는 것만 큼 개발자의 훌륭한 것이 아니라는 것을 알 것입니다.

나는이 실에있는 대부분의 사람들과 동의합니다. 그를 핫스팟에 올리는 한 가지 방법은 팀 코드 리뷰를하는 것입니다.

첫 번째 코드 검토 회의의 경우 열려 있고 권장 사항을 수락하는 팀원 중에서 코드를 선택하십시오. "Star"개발자는 코드 검토가 어떻게 작동하는지 확인한 다음 다음에 검토 할 코드를 예약 할 수 있습니다. 그에게 다음 회의를 준비 할 시간을주고 그때까지 그는 적어도 그의 코드를 댓글을 달아야합니다.

코드 검토의 의도는 사람들에게 수치심이 아니라 개선을위한 문제와 장소를 공동으로 식별하는 것이지만, 스타 개발자를 핫 시트에 올리는 좋은 방법이 될 것입니다.

제 생각에는이 사람을 떨어 뜨려야합니다. 그의 코드는 읽을 수없는 것처럼 들리며 확실히 팀도 아니고 안전한 플레이어가 아닙니다.

또한 누군가가 자신을 필수 불가결 한 것으로 볼 수있게하는 것은 매우 나쁜 관행입니다. 당신이 그를 계속 유지하게한다면, 그의 관행은 더 나아질 것입니다. 그가 떠날 때, 모든 사람을 위해, 당신은 얽힌 코드의 엄청난 두통을 남길 것입니다. 그가 형성되지 않으면 이제 손실을 줄여야합니다.

마지막으로,이 개발자를 지배하지 않고 주니어 개발자로부터 열악한 사례를 설정합니다. 당신이 그들이 올바르게 일하도록 강요한다면, 당신은 "왜 나가 아닌"군중으로부터 분개 할 위험이 있습니다. 그렇지 않으면 "스타"처럼 일하는 많은 해킹을 얻습니다.

요컨대, 그가 매우 빠르게 형성하지 않는 한, 전체 개발 직원의 건강과 정신을 위해 그를 떨어 뜨릴 때입니다.

우리는 3 년 전에 현재 직장을 시작했을 때 비슷한 문제를 겪었습니다. 우리의 리드 개발자는 카우보이였습니다. 그는 정말 똑똑했지만 매우 불규칙했고, 그의 물건 중 일부는 매우 잘 문서화되어 있었지만 너무 복잡해졌지만, 먼저 유지하거나 코드를 코딩하고 나중에 무엇을 건축했는지 알아 내기 위해 코드를 버리기 위해 코드를 버릴 것입니다.

그는 약 2 년 반 전에 떠났고, 우리가 그의 오래된 코드 중 일부를 찾을 때 여전히 우리를 괴롭 히고 있습니다. 그리고 그의 방어에서, 이곳의 개발 상점이 그 당시에 달리는 방식입니다. 지난 3 년 동안 나는 십자군에있었습니다. 그 정신을 바꾸려면.

스타 개발자가되면 시스템, 코드, 프레임 워크, 아키텍처 등을 얼마나 잘 아는 지에 대해 많은 것을 멈추지 않습니다.

우아하고 유지 관리 가능하며 유연하며 읽기 쉬운 코드를 작성합니다
나머지 팀과의 협력 : 소스 제어 사용, 예제에 따라 선도 등
각 방법, 클래스, 대상 등이 무엇을하는지 문서화
자신과 팀을 위해 일하는 새롭고 더 나은 방법을 연구하고

당신이 어떤 수준 에서이 네 가지를 모두 따르지 않는다면, 당신의 스타 개발자가 아닌 경우, 당신이 그것들을 사용하는 것을 시도/배우기를 거부한다면, 다른 고용 기회를 찾아야 할 때가 굶주린 아티스트가 인기가 있다고 들었습니다. 이 시간의 사람과 함께 (전체 오해 천재적인 것)

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow