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

먼저, 얼마 전에 저는 프로그래머 인 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를 내려 놓을 때입니다.

답변