기본 규칙을 따르도록 프로그래머를 설득하는 방법

프로그래머가 자주 따라야한다고 요구하는 몇 가지 규칙이 있습니다. 그들은 코드를 작성하고 작동하면 작업이 완료됩니다. 가장 기본적인 규칙은 다음과 같습니다.

• 커밋 변경
• View 또는 Controllers에서 모델 문제를 작성하지 않음
• 하드 코딩 피하기

당신의 경험에 대해 말해 줄 수 있습니까? 이것을 어떻게 관리합니까?

모든 지식 근로자는 양질의 작업을 수행해야합니다. 임의의 시간 제약이 있다고 느끼면 품질이 저하됩니다. 모든 사람이 사양을 충족하고 마감 시간을 맞추는 데 관심이있을 때 "충분히 좋은"것을 만드는 것이 어떻습니까?

불만 사항 목록은 단기 목표 달성에 대해서만 보상하며 높은 품질을 강조하지 않는 회사의 증상입니다. 5 성급 호텔 또는 트럭 정류장을 운영하고 있습니까?

기본 규칙을 따르려면 규칙이 무엇인지 알고 규칙에 동의해야합니다.

이를 처리하는 방법은 모두가 동의 할 수 있는 코딩 지침 문서 를 공동으로 작성하는 것 입니다. 그들에게 이것을 강제로 시도하지 마십시오.

따라서 팀을 구성하고 기본 규칙에 대한 공통 정의를 작성하십시오!

모든 목소리가 들리는 작업장으로하십시오. 끝없는 토론을 피하기 위해 타임 박스. 당신은 여러 가지 생각을 모 으려고 노력하고 있으므로, 모든 사람이 존중하고 열린 마음을 유지해야한다는 긍정적 인 메모로 무대를 설정하고 싶을 수도 있습니다 (코드 작성은 개인적입니다 ...).

이 지침은 팀이 추가하거나 설명해야 할 것이 있다고 느낄 때마다 변경되어야합니다.

당신의 역할은 무엇입니까? 코드 품질에 특히 관심이있는 또 다른 개발자 인 경우, 사용자가들을 수있는 권한이 없을 수도 있으며, 이러한 아이디어를 경영진에게 버블 링하여 코드 표준을 설정해야합니다. 따라 갔다. 관리자 / 팀장 / 건축가이고 권한이있는 사람은 이러한 관행을 직접 설정할 수 있습니다. 이러한 것들을 제거하기 위해 표준 문서와 코드 검토 프로세스를 연구하십시오.

그것은 당신이 켤 수있는 마법의 스위치가 아닙니다. 속도가 느리고 100 %가되지 않습니다. 어쨌든 그것은 내 경험이었습니다.

지금까지 모든 대답을 합리적으로 조합해야합니다. 결국, 똑똑한 사람들 (개발자) 그룹에 대해 이야기 할 때, 행동이 중요한 이유를 제시하고, 행동이 올바르게 수행되도록 투자되는 행동이 어떻게 수행되는지 충분히 제어해야합니다 . 위의 명령은 일반적으로 똑똑한 사람들에게는 느슨합니다. 문제가 문제라는 데 동의하지 않으면 규칙을 따르는 것보다 명령을 해결하는 데 더 많은 시간을 할애 할 수 있기 때문입니다.

내 전술 중 일부는 다음과 같습니다.

변경 사항 커밋 :

먼저, 팀은 언제 커밋 할 것인지, 무엇을 커밋 할 것인지에 동의해야합니다. 사람들이 무언가를 어디에 두어야할지 모릅니다. 언제, 얼마나 자주 체크인해야하는지에 대한 합의는 "빌드를 깨뜨리지 말라"는 것은 명백한 좋은 규칙이지만 어떻게 확인되고 누가 그것에 대해 알게됩니까? 또 다른 기준은 "체크인되지 않은 경우 수행되지 않습니다"입니다.

내가 아는 대부분의 개발자는 코드 IF를 확인하는 것이 행복합니다.

• 체크인 과정은 쉽습니다
• 동기화 프로세스가 쉽습니다 (다른 개발자의 변경을 고려하여)
• 변경 사항 확인 및 버전 간 이동이 쉽습니다.

내가 최근에 알아 차린 한 가지는 새로운 CM 도구를 사용할 때 체크인이 더 빈번하고 고통스럽지 않다는 것입니다. 우리 팀은 이전에 Clearcase를 사용한 Rational Team Concert를 개척하고 있습니다. 툴을 광고한다는 의미는 아니지만 작고 빠른 병합이 많은 새로운 스트리밍 체크인의 물결이 조기 체크인과 자주 체크인에 더 매력적입니다.

개발자가 CM 통증 제거를 담당하게하면 일반적으로 체크인 횟수가 증가합니다.

아키텍처 준수-뷰 및 컨트롤러에서 모델 문제를 작성하지 않음

나는 그것을 "아키텍처를 올바르게 수행하라"는 일반적인 덩어리에 넣었다. 나는 동료 평가에 대해 말한 사람에 동의합니다. 동료의 압력은 이것에 좋습니다. 내가 일반적으로 사람들이이 분야에서 모범 사례를 접어 접하게되는 방법 중 하나는 동료들이 다른 방법으로 왜 그렇게했는지 물어 보는 것입니다 (그렇지 않은 방법). 일반적으로 "왜"질문은 사람들이 왜 다르게해야하는지 깨닫는 길을 안내합니다. 사람들이 모범 사례를 잘 이해 한 이유를 잘 알고 있으면이를 따르는 것이 훨씬 쉽습니다.

또한 사람을 결정에 연결하는 형식이 있다면 해당 영역에 버그를 할당하는 것이 더 쉬울 수 있습니다. 따라서 디자인이 잘못된 영역에서 버그를 수정하는 책임이있는 사람은 바로 전에 무언가를 얻을 필요가 있습니다. 그들은 새롭고 흥미 진진한 무언가로 넘어갈 수 있습니다.

하드 코딩 방지

명확한 코딩 표준으로 시작하고 코딩 검토를 동료 검토에 통합합니다. 하드 코딩은 동료 검토 안건의 확인란이 될 수있는 것 중 하나입니다.

나는 이런 종류의 것이 그것이 규칙을 집행하는 팀 리더의 역할이 된 것을 본 것 중 하나입니다. 내가 운영 한 팀에서는 일반적으로 코드의 동료 검토에서 주석을 수정하기 전까지는 누군가가 계속 움직이지 못하게합니다. "하드 코딩 없음"은 빈번한 동료 검토 의견입니다.

일반적으로

거의 모든 모범 사례를 통해 전투를 선택해야한다고 생각합니다. 완벽한 팀은 없습니다. 그러나 주요 통증 포인트를 주시하고 클러스터에서 문제를 해결할 수 있습니다. 팀의 어려움과 특정 개인의 성가신 점을 실제로 아는 것이 리더의 역할이된다고 생각합니다.

팀이 특정 모범 사례를 수행하지 못한 경우 첫 번째 질문은 "이로 인해 얼마나 많은 피해가 발생합니까?" 대답이 "최소한"일 경우 아마도 시간 가치가 없을 것입니다. 일부 모범 사례는 특정 유형의 시스템과 가장 관련이 있습니다. 전반적으로 우수하지만, 사례가 자주 발생하지 않거나 시스템의 주요 부분이 아닌 시스템의 경우에는 가치가 없습니다.

"얼마나 많은지?" "ALOT !!!"입니다. 모범 사례에서이 한 가지 문제를 해결하여이 모든 고통과 고통을 제거 할 수 있음을 팀에게 보여줄 수있는 사례를 구축 할 수 있습니다. 대부분의 사람들은 고통과 고통을 피하는 것이 기쁘고 대화가 "내가 말한 것이기 때문에"에서 "우리가 더 낫기 때문에 이것을하기로 결정했습니다"로 대화를 바꿉니다.

코드 검토. 오류가없는 잘 작성된 코드 만 수락하십시오.

적어도 :

• 코드 라인을 쉽게 따라갈 수 있도록하십시오 (resharper, StyleCop와 같은 도구) 쉽게 적용 할 수 있습니다.

그 외에도 조직, 개발자 및 팀 내 역할에 따라 작동하는 것을 선택하십시오.

• 버그 수정 및 요청 변경을 정기적으로 수행하도록합니다.
• 숙련 된 개발자와 쌍으로 프로그램
• 건설적인 방식으로 코드 검토
• 코드 연습
• 교육을 시작하고 Code Complete 및 The pragmatic programmer와 같은 책을 사용하십시오.

저의 역할은 관리자이지만 소규모 팀으로서 저는 개발하고 차라리 코치를 선호합니다.

코드 파서에 연결된 의자의 전극은 이미 지적되었지만 프로그래머는 두려워하지 않는 것 같습니다. 해고는 가치있는 자산을 잃어버린 것을 의미하므로 좋은 접근 방식으로 들리지 않습니다.

모든 도구를 살펴보고 다른 사람에게 열려 있습니다.

이 문제를 해결하는 방법에는 3 가지가 있습니다.

1. 코딩 규칙 관련 문제를 확인하기위한 소스 코드의 정적 분석 같은 도구를 사용하여 cppcheck 과에서 그 grammatech을 . Wikipedia에는 http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis 목록이 있습니다. 일반적으로 대부분의 소스 제어 시스템에는 체크인하는 동안 이러한 문제를 직접 확인할 수있는 후크가 있습니다. CVS 후크의 경우 http://goo.gl/F1gd2 링크를 참조하십시오 . 준수하지 않으면 체크인 실패, 3 회 이상 실패하면 개발자가 팀에 자신을 설명해야 함을 의미합니다.

2. 코딩 과정 자체에서 개발자에게 문제를 표시합니다. 선택한 IDE와 통합 된 사용자 지정 스크립트를 사용하는 것이 멋진 방법입니다. 이 링크를 확인하십시오 : http://goo.gl/MM6c4

3. 민첩한 프로세스를 따르고 코드 검토가 스프린트의 일부인지 확인하십시오

3 단계 계획은 다음과 같습니다.

1. 프로그래머 해고
2. 일부 소프트웨어 엔지니어를 고용하십시오
3. ...
4. 이익!

:디

진지하게, 그들이 코드를 작성하는 것 외에는 아무것도 믿지 않는다면보다 균형 잡힌 팀이 필요합니다. 내가 일한 프로그래머는 컴퓨터의 다른 디렉토리를 CM으로 사용했습니다. 우리는 그들의 프로그래머와 거의 1 년 동안 싸웠습니다. 우리는 결국 그들을 해고했습니다.

1. 그들이 기본 규칙을 위반할 때 지적하십시오.
2. 추적 할 수없는 버그를 만들거나 코드가 유연하지 않아 구현할 수없는 기능 요청에 직면 할 때까지 기다립니다.
3. 당신이 이전에 말한 것을 상기 시키십시오.
4. 그들이 잠시 동안 자신의 똥에 빠져 보자.
5. 시간을내어 문제의 코드를 리팩터링하고 버그를 격리하고 인프라를 제공하여 새로운 기능을 구현하십시오. 시간을내어 자신이 한 일을 설명하십시오.

또는 가장 잔인하지만 매우 설득력있는 작업은 일정이 빡빡 할 때 극도로 저조한 코드베이스를 유지하도록하는 것입니다. : D
그런 다음, 일정이 바뀔 때마다 변경을 위해 잘 작성된 코드베이스를 유지하도록합니다.

일반적으로 특정 표준을 채택하지 않으려는 것은 팀워크에 대한 경험이 부족함을 의미합니다.

결국 사람들은 실수로부터 만 배웁니다. 다른 사람의 완고함을 바탕으로하는 문제를 절대로 고치지 마십시오. 프로젝트에 정말로 중요한 경우 (즉, N 일 이내에 배달하지 않으면 회사에서 소송을 제기 할 수 있음) 먼저 프로젝트에서 제외시킵니다.

나는 당신이 프로그래머가 당신이 언급 한 문제들에 대한 태도를 바꾸지 않을 것이라고 생각합니다. 그들이 왜 이런 일을하기를 원하는지 설명해보십시오. 더 좋은 점은 그들이 이점을 경험하게하십시오.

한 명의 전문 소프트웨어 엔지니어를 고용하십시오. 그리고 가장 약한 불. 그런 다음 입양 할 수없는 사람들을 천천히 대체하십시오. 그러한 사람들이 때때로 장기적으로 이익보다 더 많은 해를 끼칩니다.

여기에서 주요 아이디어는 전문가가 대부분의 일을 시작하고 다른 사람들을 해고하더라도 귀중한 인적 자원을 감소 시키지는 않는다는 것입니다.

약간 거칠지 만, 몇 개월 동안 화장실에 Code Complete를 두었습니다. 효과가 있었는지 확실하지 않았지만 당시에는 좋은 생각처럼 보였습니다.

그렇다면 규칙을 따르지 않으면 어떤 결과가 발생합니까? 답이 같으면 (아무것도 아닌) 행운을 빕니다. 계층화 된 접근 방식을 제안합니다. 먼저 그들을 모아서 규칙에 사는지 토론하십시오. 다음 단계는 코드 검토에 포함시키는 것입니다. 당근과 스틱을 사용해 볼 수도 있습니다. 밤새 파일을 체크 아웃 한 사람은 다음 주 회의에 도넛을 가져와야합니다. 당근은 한 달 동안 규칙을 따르는 사람이라면 누구나 라스베가스에서 주말을 보낼 수 있습니다. 둘을 위해.

또는 최악의 범죄자를 해고하고 나머지는 땀을 흘리게하십시오.

이러한 규칙을 사용하여 피하고 싶은 결과를 겪게하십시오. 예를 들어 그들이 수정해야 할 작은 통제 된 혼란을 만드는 것은 그들이 당신이 요구하는 이유를 실제로 이해하는 유일한 방법 입니다.

이 승무원이 실제로 변경 사항을 확인하는 데 어려움을 겪고 있으며 마법 상수를 하드 코딩하지 않고 우려를 분리하면 승무원 전체를 해고하고 가능한 한 빨리 공예에 관심이 있는 실제 프로그래머 ^1로 교체합니다 . 한 번에 하나씩 또는 한꺼번에 말할 수는 없지만이 조커들은 가야했습니다.

설명하는 코딩 종류는 일회용 일회용 스크립트에 적합합니다. 실제 응용 프로그램을 만드는 방법이 아닙니다. 그들이 전문 프로그래머로서 돈을 받고 있다면 이런 종류의 일을 아는 것이 그들의 임무입니다.

¹ 이것은 종종 이진법이나 똑같은 말로 코드를 직접 작성하는 가상의 사람들에게 농담 용어로 사용됩니다. 농담이 아니에요 나는 상당히 신인 프로그래머이며 내 공예에 관심이 있기 때문에 이런 말을 할 필요가 없습니다. 이들은 당신이 다루는 실제 프로그래머가 아닙니다.

관리자의 일은 직원의 친구가되어서는 안되며 때로는 나쁜 사람이되어야합니다. 코딩 표준 및 커밋 시행, 예측 아키텍처 준수 거부, 규정 된 도구 사용 실패 등은 인기가 없어야 할 때입니다.

정책을 명확하게 표현하십시오. 공식적인 코드 검토를 수행하고 정책을 준수하는지 확인하십시오. 코드 검토의 모든 문제가 판결 될 때까지 다른 작업으로 이동하지 마십시오.

정책이 코드를 커밋하지 않는 것에 관한 것이라면, 요청 될 때이를 수행 할 수없는 경우 서면 경고를 요구합니다. 그들이 코드를 커밋하지 않으면 걱정하지 않는 한 아무 코드도 작성하지 않았습니다.

합리적으로 개선 할 수있는 기회를 얻은 후에도 개선되지 않으면 해고하십시오. 전문가가 아닌 개발자는 어떤 종류의 코드를 작성하든 팀을 끌어들입니다. 그들은 전문성이 결여되어 다른 사람들에게 영향을 미치며 용납해서는 안됩니다. 그들은 어떤 경우에도 좋은 사람들이 아닙니다. 좋은 개발자는 코드를 커밋하고 좋은 개발자는 동의하지 않고 좋은 개발자가 하드 코딩하지 않아도 아키텍처 결정을 따릅니다. 카우보이 코더를 제거하여 두통 이외의 것을 놓치지 마십시오.