팀이 소규모 수업 / 방법을 사용하도록 설득하려면 어떻게해야하나요?

면책 조항 : 저는 신규 이민자 (제 3 일)이며 대부분의 팀원은 저보다 경험이 풍부합니다.

코드를 살펴보면 다음과 같은 코드 냄새와 나쁜 엔지니어링 관행이 있습니다.

• 다소 일치하지 않는 이름 지정 지침
• 가능한 경우 읽기 전용으로 표시되지 않은 속성
• 큰 클래스-수백 가지의 확장 메소드 (다양한 유형)로 구성된 유틸리티 클래스를 발견했습니다. 2500 줄 이상이었습니다!
• 큰 방법-150 줄 길이의 방법을 리팩토링하려고합니다.

후자의 두 가지는 실제 문제인 것 같습니다. 팀원들이 더 작은 클래스와 메소드를 사용하도록 설득하고 싶습니다. 하지만 그렇게해야합니까? 그렇다면 어떻게?

우리 팀은 메인 팀으로부터 멘토를 받았습니다 (위성 팀입니다). 내가 먼저 가야합니까?

업데이트 : 프로젝트에 대한 일부 답변이 요청되었으므로 작동중인 프로젝트라는 것을 알고하십시오. 그리고 IMHO, 그 규모의 거대한 클래스 / 방법은 항상 나쁩니다.

어쨌든, 나는 내 팀을 화나게하고 싶지 않습니다. 그렇기 때문에 내가 물어야한다면 어떻게해야합니까?

업데이트 : 나는 받아 들여진 대답을 기반으로 무언가를하기로 결정했습니다. 왜냐하면 나는 새로 온 사람이기 때문에 "신선한 눈"으로 모든 것을 보게됩니다. 내가 찾은 모든 코드 냄새에 주목할 것입니다 (위치, 나쁜 이유, 어떻게 할 수 있습니까? 더 나은, ...),하지만 지금은 팀에서 존경을 모으기 위해 열심히 노력합니다. "더 나은 코드"를 작성하고 사람들을 알고 왜 그런 짓을했는지 알고 있습니다 ... 시간이 맞으면 시도합니다 팀에 새로운 코드 정책 (이름 지정 지침, 소규모 클래스, 소규모 메소드 등)에 대해 문의하고 가능하면 오래된 코드를 리팩터링하십시오. 작동해야합니다 (IMHO).

고맙습니다.

신선한 눈으로 코드를 볼 수있는 이점이 있습니다. 나쁜 관행에 대해 발견 한 내용을 기록하기 위해 메모하십시오. 그런 다음 팀에 합류 할 때 리팩토링 시간과 같은 적절한 순간에 메모를 꺼냅니다.

Steve McConnell의 Code Complete는 여러분이 이야기하고있는 주제에 대한 수많은 통계를 보유하고 있습니다. 나는 모든 숫자를 기억하지는 않지만 더 긴 메소드 / 클래스로 버그 수를 늘리는 방법, 디버깅하는 데 시간이 얼마나 걸리는 지 등에 대해 이야기합니다.

당신은 책의 사본을 사서 동료들에게 몇 가지 연구를 보여줄 수 있습니다.

면책 조항 : 나는 새로운 이민자이며 (제 3 일), 대부분의 팀이 나보다 더 경험이 있습니다.

너무 많은 변경을 제안하기 전에 팀의 속도를 늦추고 듣고 듣고 배우십시오. 코드가 그대로 구성되어있는 데는 이유가있을 수도 있고 아닐 수도 있지만, 먼저 듣고 배우는 데 시간이 걸리면 도움이 될 수 있습니다.

그 후에 당신이 할 수있는 어떤 제안이라도 가장 긍정적으로보고 저항이 줄어 듭니다.

동료의 존중을 얻거나 최소한 존중을 잃지 않으면 변화를 성공적으로 도입 할 가능성이 크게 향상됩니다.

어떻게됩니까? "한 번 두 번 측정하십시오."그런 것.

팀이 코드를 작성하는 방식을 정밀하게 검사하려는 의도가 없다면, 철저한 정밀 검사에 대한 열정을 완화 할 수 있습니다. 대부분의 작업 코드는 이유에 따라 작동합니다.

작은 코드를 작성하는 가장 쉬운 방법은 개발자에게 단위 테스트 에 집중하도록 요구하는 것 입니다. 간결한 코드를 테스트 하라는 요청을받는 것만 큼 강력한 것은 없습니다 . 개발자가 갑자기 전역 데이터 구조에 대한 혐오감을 느끼면서 너무 많은 객체를 너무 많은 레이어에 너무 많이 전달하여 테스트를해야한다는 것을 알면 놀랍습니다.

나는 TDD의 거대한 팬이 아니에요하지만 난 않는 그들이 테스트를 작성하는 것입니다 방법을 고려해야 개발자를 강제 사실을 사랑 해요. 그리고 실제로 테스트 를 하는 것에 대한 마술이 아니라 코드가 더 나은 이유 가 종종 있습니다. (나중에 변경할 때 편리하다는 것은 확실합니다.)

행운을 빌어 요.

팀을 설득해서는 안됩니다. 새로운 이민자로서, 당신은 진지하게 받아들이지 않을 것이므로 시간을 낭비합니다.

대신, 작고 깨끗한 코드를 직접 작성하십시오. 그런 다음 잠시 후 코드 검토 후 일부 팀원이 스타일을 모방하기 시작할 수 있기를 바랍니다.

그렇지 않다면 여전히 생산성이 높아지고 열심히 노력하면 결국 이러한 규칙 중 일부를 시행 할 수있는 더 높은 위치에있게됩니다.

그리고 그렇습니다. 코드 완성에서 모든 사람에게 보여주십시오.

몇 가지 요령이 있습니다.

• 팀의 현재 상태와 역사를 배우십시오-멘토가있는 것처럼 들리며 멘토가 얼마나 많은 영향을 미칩니 까? 또한 멘토는 얼마나 새롭고 멘토없이 오랜 시간이 걸렸습니까? 문제 코드는 언제 시작됩니까? 현재 팀의 아기를 비판하는 것은 실제로 글을 기억하지 않는 오래된 코드를 비판하는 것과 크게 다를 수 있습니다.

• 한 번에 한 가지-팀 회의에서 모든 생각에 폭탄을 떨어 뜨리지 마십시오. 특정 관점에서 오는 잠정적 인 질문으로 시작하십시오. 예를 들어 "이봐 요, 새 사람으로서 유틸리티 클래스 중 일부가 실제로 크다는 것을 알았습니다. 그 이유가 있습니까?"

• 아기 발자국 제안-즉각적인 총체적인 정밀 검사는 거의 불가능하므로 모든 사람들이 이것이 좋은 계획이라는 데 동의 할 경우 제안 할 수있는 몇 가지 시작 단계를 알아 내십시오.

• 미래 예방 메커니즘 제안-예를 들어, 팀은 상위 소수 클래스에는 절대 추가하지 않지만 더 성장해야 할 때 리팩토링한다는 목표에 동의 할 수 있습니다.

• 위험에 대한 우려를 경청하십시오. 이것이 실제로 레거시 코드 인 경우 리팩토링이 매우 위험한 미지 및 종속성이 충분할 수 있습니다. 리팩토링을 피해야하는 이유는 아니지만 실제 재 작업을 수행하기 전에 더 나은 테스트 전략이나 위험을 줄이기위한 다른 방법이 필요할 수 있습니다.

• 신체 언어를 알고 느리게하십시오. 경험이 많지 않은 코드베이스에 문제가 있습니다. 지금 새로운 사람 창을 통해 순진한 질문을하고 유용한 답변을 얻을 수 있으며, 이러한 질문을 사용하여 팀이 자신의 디자인 선택을 고려하도록 조사 할 수 있습니다. 그러나 그것은 두 가지 방식으로 진행됩니다. 새로운 사람으로서, 당신은 아직 많은 "신념"을 가지고 있지 않으므로 느리게 가면서 닫힌 얼굴이나 자세를 인식하십시오. 사람들이 셧다운을 시작하면 의사 결정을 지연시키고 이길 방법을 찾으십시오.

관리자 및 팀원으로서 New Guy Insights에 기뻐했습니다. 나는 새로운 팀원이 내게 준 건설적인 해설을 모두 받아들이지는 않았지만, 비판이 정직한 관심과 호기심으로 말되고 강의로 전달되지 않았다면 일반적으로 기꺼이 듣고 자했다. 새로운 사람에 대한 존중의 표시는 통찰력을 전달한 다음 물러나서 뒤로 물러서서 처리 할 수있을 때 지속됩니다. 의사 결정을 듣고 채택 할 때 기분이 좋으며 팀이 "아니오"라고 말할 때 더 어려워집니다. 당신은 여전히 ​​옳을 수도 있지만, 트릭은 다음에 무엇을 해야할지 파악하는 것입니다 ... 보통 약간 기다렸다가 더 많은 정보를 찾는 것이 좋은 경우 다음 단계입니다.

팀이 소규모 수업 / 방법을 사용하도록 설득하려면 어떻게해야하나요?

하지마

자신에게 Resharper 라이센스를 구입하고 예를 따르십시오. [ ' 추출 방법 '리팩토링 에 크게 의존하십시오 .]

시간이 지남에 따라, 다른 사람들 은 더 읽기 쉬운 코드에 감사하고 이와 같이하도록 설득해야합니다.

• 예- 설득 되지 않을 가능성이 있습니다. 하지만 여전히 최선의 방법입니다.

IMO- 음절이 팀원들에게 더 나은 프로그래머가되도록 설득하려고 노력할 필요는 없습니다. ' Code Complete '를 읽고 @Uncle Bob을 따르십시오. 의 SOLID 원칙을 따르고 아직 설득되지 않은 경우 더 나은 프로그래머가됩니다.

기억하십시오 : 논리를 사용하여 처음에는 논리를 사용하지 않은 위치에서 누군가를 주장 할 수 없습니다.

이것은 기술적 인 질문보다 관리적인 질문 인 것 같습니다. 당신이 말한 모든 것이 유효합니다. 팀이 정말로 필요로하는 것은 모든 사람이 단일 디자인 패턴에 적응하고 적용하도록 할 수있는 훌륭한 건축가입니다. 팀은 지속적이고 규칙적으로 코드를 리팩터링해야합니다.

그러나 또 다른 "당신은 그것을 필요로하지 않을 것"이라는 원칙이 있습니다. 만약 존재했던 것이 상당히 추악하더라도, 그것을 바꾸는 것이 항상 좋은 생각은 아닙니다. 대신 팀이 전체를 재 구축하거나 일부를 재 구축해야하는 경우 코딩을 수행하기 전에 나쁜 사례와 문제에 대한 문서를 축적하십시오.

일부 팀은 코드에 적합한 도구를 모르기 때문에 코드 품질 관리를하지 않습니다. 팀 코드를 개선하는 데 도움이되는 많은 도구가 있습니다.

Visual Studio에는 명명 규칙에 도움이 될 수있는 "코드 분석"이 있습니다.

또한 순환 복잡성과 같은 코드 메트릭을 사용할 수 있습니다. 이렇게하면 너무 복잡한 클래스와 메서드를 가리킬 수 있습니다.

기록을 유지하는 것도 좋은 생각입니다. 팀원이해야 할 일을 구두로 표현하면 사람들은 잊어야 할 의무가 있습니다. 인간은 매우 연약한 기억을 가지고 있습니다! =)

나는 이것에 대해 많은 소음을 내지 않을 것입니다 ... 프로그래머의 개발 팀은 자신의 가족과 같습니다 ... 실수를 지적하면 사람들이 당신에게 화를 낼 수 있습니다. 이런 종류의 문화 변화는 많은 코딩을 필요로 할뿐만 아니라 인간과의 섬세한 접촉이 필요합니다.

방금 추가하려는 관리자로서 팀이 처음으로 좋은 코드를 작성하기를 원합니다. 코드 검토, TDD 및 그 모든 것. 그러나 일단 제작이 완료되고 작동하면 다시 돌아가려면 강력한 사례를 만들어야합니다.

나는 당신이 찾은 것보다 항상 코드를 더 잘 남기기 위해 밥 삼촌의 조언을 따르고 있습니다. 따라서 수정해야 할 버그가 있거나 약간의 개선이 있다면 정리 작업을 수행했으면합니다.

그러나 비즈니스는 실제로 돈을 감시 합니다 . 리팩토링을 통해 팀에 시간과 리소스를 충분히 제공 할 수있는 이점을 얻을 수있는 사례를 만들어야했습니다. 코드 모양을 좋아하지 않는 것만으로는 충분하지 않습니다.

따라서 그것이 효과가 있다면, 당신이 그것을 싫어하는만큼만 내버려 두어야 할 수도 있습니다.

이제 새로운 코드는 다릅니다. 좋은 코드 여야합니다.

150 줄의 메소드 ... 10.000 줄의 코드를 가진 메소드를 보았습니다.

외부 도구 를 사용하여 두 가지 문제를 해결할 수 있습니다 .

• 다소 일치하지 않는 이름 지정 지침
• 가능한 경우 속성이 읽기 전용으로 표시되지 않습니다

C #에서 Resharper 는 두 문제를 모두 확인할 수 있습니다. 지침을 따르지 않는 이름은 오류로 표시됩니다. 읽기 전용으로 표시되지 않은 속성도 오류로 표시됩니다. FxCop도 도움이 될 수 있습니다.

이러한 툴은 리팩토링 덕분에 방대한 방법을 여러 개의 작은 방법으로 나눌 수 있습니다.

이름이 큰 메소드로 잘 구성되면 큰 클래스가 항상 그렇게 나쁘다는 것을 모르겠습니다. Eclipse를 IDE로 사용하므로 "outline"보기라는 이름이 있습니다. 모든 IDE에는 이름이 다르고 클래스 내의 각 메소드에 대한 이름과 링크를 제공하는 알파벳순으로 정렬 할 수 있습니다. 등을 사용하면 큰 클래스를 쉽게 탐색 할 수 있으며 실제로 긴 메소드를 사용하는 것이 좋지 않을수록 더 익숙 할 것입니다. 나는 긴 수업을 옹호하지는 않지만 어떤 경우에는 관리가 가능하며 반드시 여러 수업으로 나눌 필요는 없다고 생각합니다.

주제를 팀원들과 함께 가져오고 방법의 크기에 대한 의견을 얻으십시오. 그들이 당신과 동의한다는 것을 알게되면 놀랄 것입니다. 당신이보고있는 것은 이전의 나쁜 관행, 전 개발자가 더 이상 회사에 가지 않았거나 그 부분이 급한 일이었고 지금은 그것을 리팩토링 할 시간을 가진 사람을 고용했습니다.)

당신은 여전히 ​​새로운 사람입니다. 어려운 과제를 수행하고 버그없이 신속하게 완료하여 평판을 쌓으십시오. 동료의 존경을 받기 전에 물건을 바꾸려고하면 물건을 사는데 훨씬 더 힘들 수 있습니다 (그리고 동료를 소외시킬 수도 있습니다).

개발 시간을 단축하고보다 강력한 솔루션을 제공하는 방법을 효과적으로 보여주는 작업에 더 나은 코딩 습관을 도입 할 수있는 방법을 찾을 수 있다면이를 달성 한 방법을 알게 될 수도 있습니다.

다른 모든 위대한 대답에 더하여, 하나의 돌로 두 마리의 새를 죽이고 코드베이스에 대한 이해를 얻는 것을 목표로 프로젝트를 코드 정리할 수 있습니다. 이를 학습 기회로 팀 / 관리자에게 판매 할 수 있으며, 변경 사항을 검토 할 때 동료로부터 피드백을받을 수 있으며, 이는 설계 불량 문제를 해결하기위한 최선의 방법을 안내합니다.