내 밧줄의 끝에 [닫힌]

저는 대기업의 계약자입니다. 현재이 프로젝트에는 3 명의 개발자가 있습니다.

문제는 다른 두 개발자가 실제로 얻지 못한다는 것입니다. "it"은 다음을 의미합니다.

• 그들은 우리가 사용하는 기술에 대한 모범 사례를 이해하지 못합니다. 6 개월 동안 저와 다른 사람들이 모범을 보인 후에는 끔찍한 반 패턴이 사용되고 있습니다.
• 이들은 주로 스파게티 코드를 생성하는 "복사 및 붙여 넣기"프로그래머입니다.
• 그들은 끊임없이 일을 끊고 변화를 구현하지만 모든 것이 좋은지 확인하기 위해 기본 연기 테스트를 수행하지는 않습니다.
• 그들은 코드 검토를 요구하거나 거부합니다.
• 그들은 형식 ​​코드와 같은 기본 작업을 거부하거나 거의하지 않습니다.
• 모든 클래스에 대한 문서가 없습니다 (jsdocs)
• 아무것도하지 않는 코드를 삭제하는 것을 두려워합니다.
• 버전 관리 기능이 있어도 주석이 달린 코드 블록은 어디에나 두십시오.

다른 코드를 포맷하고, 버그를 수정하고, 깨진 기능을 발견하고, 스파게티를 제거하는 추상화를 만들면서 점점 더 좌절감을 느낍니다.

나는 무엇을 해야할지 정말로 모른다. 나는 좌절하지 않으려 고 노력하지만 엉망입니다. 나는 사람들을 사람들처럼 좋아하지만 코딩 상황이 너무 나빠서 하루 종일 웹을 탐색하면 더 빨리 움직일 수 있다고 생각합니다.

관리자에게 다른 svn commit 액세스를 검토하도록 요청하는 것이 잘못된 것일까 요? 커밋은 우리가하는 일에 대해 잘 알고있는 사람이 검토 한 후에 만 ​​수행 할 수 있습니까? 계약자로서 이것이 최선의 방법인지 잘 모르겠습니다.

내가 몇 가지를 고치고 있는지 명확하게하는 미묘한 방법이 있습니까?

팀에서 이와 같은 것을 가지고 있습니다. 사람들이 옳은 일을하도록 노력했지만 예상대로 작동하지 않아 다른 솔루션으로 옮겼습니다.

먼저 관리자에게 가서 단위 테스트로 다루지 않는 한 소스 컨트롤에 코드를 넣지 않는 거래를했습니다. 코드가 단위 테스트없이 들어 오면 커밋을 즉시 취소하고 코드를 담당 한 사람을 핑 (ping)하는 거부권이 있습니다.

대신에이 규칙으로, 나는 정기적으로 (이 경우, 코드 검사 도구를 실행 jacoco 우리의 SBT의 빌드) 확인 조각이 제대로 적용되고, 나 또한 그들에 의해 밀려 코드에 지속적으로 리팩토링과 코드 리뷰를하고 있어요 만들 수 있습니다. 이 프로젝트 는 Java 및 Scala 프로젝트이므로 존재하지 않아야하거나 생각했던 방식으로 작동하지 않는 것을 포착하는 데 도움이되는 많은 도구가 있습니다 .JavaScript로 동일한 작업을 수행 할 수는 있지만 확실하지 않을 수도 있습니다. 해결책.

내가 믿게하는 가장 중요한 것은 프로젝트에 대해 내가 기대하는 것과 프로젝트의 주요 구조를 명확하게 볼 수 있다는 것입니다. 따라서이 견해를 반영하지 않는 것을 볼 때마다 거기에 갈 수 있습니다. 고치세요. 동일한 방식으로 작업하고, 뷰를 정의하고, 사용해야하는 패턴, 코드를 작성하고, 코드를 작성하는 방법, 항상 자신과 관리자에게 진행 상황과 진행중인 작업을 알려 주어야합니다. 빨리.

그들이 포기하고 옳은 일을하거나 경영진이 메시지를 받아 프로젝트에서 제거하는 순간이있을 것입니다.

나는 지금까지 내 의견과 다른 게시물을 보았으므로 실제로 답을 알고 있다고 가장하지 않을 것입니다. 내가 제공 할 수있는 최선은 내가들은 것 / 다른 사람들로부터 읽은 것을 요약하고 내 경험의 일부를 믹스에 추가하는 것입니다.

먼저, 얼마 전에 저는 프로그래머 인 SE 회원 중 한 명인 Martin Blore 와 IMO에 속한 블로그를 보았습니다. TDD 자기 실현 에 대한이 특정 게시물 은 매우 정확합니다. TDD는 모든 것을 하나로 묶는 최후의 최고 수준이지만 이전 수준, 특히 가장 크고 명확한 코드를 생성하는 원칙과 관행이 없으면 TDD를 작동시키는 것이 불가능하지는 않지만 매우 어려울 것입니다.

우리 회사에서는 애자일과 TDD가 경영진에 의해 우리에게 부과되었으며, 처음에 우리는 (민첩과 반대되는) 말을했기 때문에 단순히 그렇게했습니다. 우리는 TDD를 두 번 시도했으며 자동화 된 테스트를 사용하는 것을 강력하게 제안하는 한편, 팀이 마지막 릴리스에서 함께했던 모든 것을 개인적으로 버렸습니다. 그들은 깨지기 쉽고, 거대했고, wazoo를 복사 / 붙여 넣기했고 수면 진술로 수수께끼를 달아서 천천히 느리고 예측할 수 없게 만들었습니다. 당신의 팀을위한 나의 충고 : 아직 TDD하지 마십시오.

당신이 6 개월 동안 회사에 갔다고 계약자라고 언급했기 때문에 당신의 상황이 무엇인지 모르겠습니다. 장기적인 목표가이 회사에 머 무르거나 계약이 만료됩니까? 나는 당신이 무언가를하더라도 실제로 결과를 보는 데 꽤 시간이 걸릴 수 있기 때문에 묻습니다.

또한 팀에 합류 할 때 일반적으로 팀 (개발자 및 관리)이 제안한 사항을 고려할 수있는 충분한 신뢰와 팀의 존경을 받기까지 시간이 걸립니다. 내 경험상 화재를 거의 일으키지 않고 다른 사람들이 의존 할 수있는 기술과 지식이 있음을 보여 주면 도움이됩니다. 6 개월이면 충분하지 않습니다. 새롭고 야심 찬 사람이 팀에 합류하여 세상을 바꿀 수있는 방법을 묻는 글을 게시하는 경우가 종종 있습니다. 슬픈 현실은 단순히 할 수 없다는 것입니다.

팀의 존중과 관심이 있다고 가정합니다. 이제 뭐?

첫째, 경영진과 개발자 모두 문제가 있음을 알고 있어야합니다. 관리 조치는 수행 된 작업 측면에서 결과를 나타냅니다. 기능의 현재 수량과 품질에 만족한다면, 안타깝게도 그들이 듣지 않을 것입니다. 다른 사람들이 지적했듯이 경영진의 지원 없이는 어떤 종류의 변화도 도입하기가 매우 어려울 것입니다.

관리 지원을 받으면 다음 단계는 팀이 운영 방식을 운영하는 근본 원인을 심층적으로 파악하고 파악하는 것입니다. 이 다음 주제는 지금 당장 개인적으로 추구 한 주제입니다. 지금까지 이것은 나의 여행이었다 :

1. 경영진의 지원을 받으면 MainMa 이 내 질문 에 대한 답변으로 제안한 많은 중앙에서 규정 된 사례 / 프로세스를 소개 할 수 있습니다 . 우리는 많은 것들을 수행했으며 (페어링 프로그래밍 제외) 분명히 이점을 볼 수 있습니다. 코드 검토는 특히 스타일링, 문서화를 표준화하는 데 도움이되었으며 팀간에 지식 / 기술을 공유 할 수있었습니다. 코드 검토가 지시되었지만 팀은 실제로 코드를 좋아하고 체크인 된 모든 기능을 검토합니다. 그러나 ...
2. 일반적으로 작성된 코드가 여전히 너무 결합되어 있으며 디자인이 잘못되었거나 완전히 부족합니다. 코드 리뷰는 그 중 일부를 포착하지만 다시 작성할 수있는 것은 너무 많습니다. 디자인이 처음에 왜 나쁜가요? -많은 개발자들이 모범 사례를 소개 한 적이 없으며 처음부터 공식적으로 OOD를 배운 적이 없습니다. 많은 사람들이 자신이 맡은 작업을 "간단히 코딩"했습니다.
3. 관리 지원을 통해 코딩을 수행하기 전에 설계를 논의하는 등 더 많은 프로세스를 도입 할 수 있습니다. 그러나 당신은 한 사람 일뿐입니다.주의를 기울이지 않으면 팀은 항상 항상 한 일로 되돌아갑니다. 왜?
4. 더 나은 관행이나 습관을 소개하고 가르 칠 수 있으므로 지속적으로 모니터링 할 필요가 없습니까? -이 부분이 그렇게 쉽지 않다는 것이 밝혀졌습니다.
5. 다른 팀원들이 왜 새로운 관행을 배우고 선택하는 것을 꺼려하고 왜 현대 소프트웨어 방법론 문헌에 그렇게 많이 쓰여졌을 때 SOLID 나 DRY에 대한 저항력이 높은가? 우리 팀에서 2 주 전에 긍정적 인 변화를 일으킨 결과 동일한 15 줄의 코드를 가진 2 개의 함수를 리팩토링했으며 리뷰어는 복사 / 붙여 넣기 에만 아무런 문제가 없기 때문에 리뷰어가 그것을 영웅적이고 불필요한 노력이라고 불렀습니다. 15 줄 나는 그러한 견해에 강력히 동의하지 않지만 현재로서는 동의하지 않기로 합의했습니다. -지금 무엇? 이제 우리는 내 다른 게시물 의 주제에 도달했습니다 .
6. maple_shaft 와 nikie 가 답변에서 지적한 것처럼 (죄송합니다, MainMa , 가장 많은 표를 얻었지만 5 단계 뒤에 있습니다 :)), "process"가 더 이상 당신을 도울 수 없으며이 포럼에서 아무도 도울 수없는 무대에 도달했습니다 "수정"이 무엇인지 말해 줄 수 있습니다. 다음 단계는 개인, 일대일, 팀일 수도 있고 한 번에 또는 다른 사람에게 다가 가서 대화하는 것입니다. 그들에게 무엇이 효과적이고 무엇이 효과가 없는지 물어보십시오. 그들이 무엇을 운전하게했는지의 근본 원인을 식별하는 유일한 방법은 이제 그들과 개별적으로 대화하고 그것을 알아내는 것입니다. 이 단계의 일부로, 나는 최근에 완전히 다른 팀 문제를 겪었지만 여기에 Joel의 대답이 있다고 생각 합니다.매우 상세하고 통찰력있는이 사례에도 적용됩니다. 요약하면, 관리를 "짧은 가죽 끈"으로 사용하는 것은 거의 모든 것에 대한 가능한 접근 방법이지만, 우리는 순수한 관리 또는 기술 리더십보다 정신 분석에 더 많은 동기를 부여하기 위해 인간을 다루고 있음을 기억해야합니다.
7. 이제 팀원들과 이야기하고 있습니까? 무엇을 물어 보나요? 내가 여기에 가본 적이 없기 때문에이 다음 부분에 대해 잘 모르겠습니다. 가능한 시나리오는 다음과 같습니다. Q : SOLID는 어떻게 오지 않습니까? A : 필요하지 않습니다. Q : 도움이 될 수 있습니다. A : 나는 괜찮습니다. -어떻게 든 당신은 입을 떠나 일련의 소리를 만들어 내야하며, 청취자가 기회를주는 모든 것을 주면 일이 더 나을 수 있다는 것을 인식하게합니다. 여기서 실패하면 "프로세스"가 무엇을하든 실제로 가치가 있다고 확신하지 않습니다. 반면에이 시점을 지나면 더 이상 "프로세스"가 필요하지 않을 것입니다.
8. 근본적으로 IMO는 팀원들이 현재 습관 / 실습에 문제가 없는지 배우지 않습니다. 아마도이 모든 것의 다음 단계는 설명하고 문제를 강조하고 분명하게하는 방법을 찾는 것입니다. 결국, 우리는 따뜻하고 모호한 느낌을주기 때문에 SOLID / DRY 원칙을 사용하거나 문서를 유지하면서 읽을 수있는 코드를 작성하지 않습니다. 더 좋은 품질의 코드를 생성하고 솔직히 코드를 더 빨리 작성하기 때문에 그렇게합니다. 측정 할 수 있습니까? 아마도 이것이 소프트웨어 메트릭스가 나오는 곳일까요?
9. 여기에 미친 아이디어가 있고 그것이 실제로 작동하는지 (표준 산업 관행 일 수도 있고 완전히 무효 일 수도 있습니다. 지난 24 시간 동안 방금 만들었습니다), 나는 그것을 가지고 싶어합니다. 내년에 시작하자마자 테이블에 :
   • 다른 많은 사람들의 의견에 반하여 모든 소스 파일에 대한 작성자 / 소유자 아이디어를 소개하십시오. Pragmatic Programmer가 제안 했듯이, 이는 소스 코드를 담당 할 한 사람에게 소유권과 책임감을 부여 할 것입니다. 그것은 다른 사람들이 코드를 수정할 수 없다는 것을 의미하지는 않습니다. 우리 모두가 팀으로 일하고 있지만, 결국 코드를 ​​소유 한 사람은 변경 사항을 검토해야합니다.
   • 모든 체크인을 모니터링하고 특히 버그 수정 사항을 찾는 소스 리포지토리 트리거를 만듭니다. 모든 버그 수정이 체크인 설명에서 바로 참조 식별자를 갖도록 프로세스로 만드십시오. 이제 변경된 파일 목록을 구문 분석하고 파일 헤더 주석 블록에서 "작성자"를 제거하는 스크립트를 작성하십시오. 파일 당 / 프로젝트 당 / 작성자 당 체크인 된 결함 수를 추적하는 SQL 데이터베이스를 작성하십시오.
   • 통계가 충분하면 코드가 다른 코드보다 결함 / 변경이 적다는 것을 알 수 있습니다. 사용할 수있는 하드 데이터입니다. 단일 프로젝트의 평균 결함률이 상당히 높은 경우, 기술적 부채를 상환하기 위해 다음 정리 / 리팩토링 작업의 후보로 프로젝트를 가져 오십시오.
   • 프로젝트 또는 파일의 평균 결함률이 상당히 높고 소유자가 한 명인 경우 해당 사람과 일대일로 대화하십시오. 이 문제를 해결하기 위해 무엇을 할 수 있는지 정중하고 비대칭 적으로 질문하십시오. 이들이 소유자이므로 변경을 추진해야하지만 귀하의 도움을 제공해야합니다. 바라건대, 소유자는 자신의 스파게티 코드에서 많은 원인을 추적하고 도움을 요청하자마자 행동을 시작하고 SOLID를 내려 놓을 때입니다.

문제에 대해 관리자에게 문의하는 것이 좋지만 거의 모든 체크인을 검토하고 싶지는 않습니다.

대신 SVN에 연결하여 모든 체크인에 대해 실행되는 단위 / 회귀 테스트 모음을 제안하는 것이 좋습니다. 그것은 적어도 깨진 빌드를 피하는 데 도움이 될 것입니다. 다른 모범 사례를 점차 제안 할 수 있습니다.

그가 완전히 수용하지 않는 것으로 판명되면, 아마도 그의 머리 위로 가야 할 것입니다. 그렇게하기로 결정했다면 최고의 게임을 가져와야합니다. 그렇게하면 기본적으로 경영진에 고용되어 더 높은 수준으로 고용 될 것입니다.