동료에게 코드를 소개하는 방법

복잡하고 복잡 할 수있는 코드베이스를 팀의 새로운 구성원에게 소개하는 방법은 무엇입니까?

가장 쉬운 방법은 다이어그램으로 전체 아키텍처를 배치하고 코드에 익숙해지면서 새로운 사람에게 잘 정의 된 (그리고 범위가 넓은) 작업을 제공하는 데 몇 주 (또는 몇 개월)가 걸릴 것이라고 생각합니다.

그러나 컨설턴트 (및 그에 대한 직원)로서 나는 시간 제약이나 팀 역할 지정으로 인해 항상 그것을 가질 수는 없습니다. (저는 다른 사람보다 두 배나이 특정 프로젝트에 참여해 왔으므로 "junior"는 "코드 / 프로젝트에 대해 덜 알지"않습니다.

나는 프로젝트와 코드에 새로운 멤버를 소개하기 위해 지금 몇 번이나 임무를 수행해 왔으며, 슬프게도 매번 나는 이전보다 훨씬 나아지지 않았다. 나는 다이어그램과 그림을 좋아하지만 종종 시스템의 복잡성을 적절하게 설명하지 못한다고 생각합니다. (모든 작은 "gotchas"는 어떻습니까?)

이 프로젝트는 우리가 고객에게 프로젝트를 전달할 시점에 이르렀고 더 어려운 일을하기 위해 지식을 전수 할 사람은 본질적으로 대학을 벗어났습니다. (선임 개발자와의 지식 이전을 할 때 나는 훨씬 낫습니다.)

나는 한 달에 한 번 사용자 그룹에 참석하고 다른 기회가 생길 때마다 새로운 주제를 접할 수는 없지만 효과적인 지식 공유를 복제하는 능력이 부적절하다고 느낍니다.

모든 조언을 주시면 감사하겠습니다. 나는 주로 따라야 할 지침을 찾고 있습니다. 예를 들어 : 어디서 시작합니까? 어떻게 진행합니까? 하루 종일 듣지 않고 청취자 자신의 익숙하지 않은 기술이나 패턴을 어떻게 다루십니까? 비즈니스 로직과 코드 구조를 어디에 연결합니까?

감사합니다!

(항상 그렇듯이 언제든지 질문을 자유롭게 편집하십시오.)

1 단계는 물론 코드에서 "gotchas"를 제거하는 것입니다. 명확하고 간결하며 일관된 코드를 사용하고 작업하고 디버깅하기가 더 쉽습니다.

어디서 시작하니?

나는 새로운 이민자에게 그들이 코드베이스에 어떻게 들어가기를 원하는지 묻습니다. 모두 다르게 배웁니다. 어떤 사람들은 작업을 거의하지 않는 것을 좋아합니다. 기존 코드를 디버깅하는 것과 같습니다. 어떤 사람들은 코드가 무엇을하는지 이해하기 위해 코드를 실행하고 싶어합니다. 일부는 진입 점에서 시작하여 둘러보기를 원합니다. 일부는 visio 다이어그램을 원합니다 ... 설정된 패턴이 모든 사람에게 가장 적합한 것은 아닙니다.

하루 종일 듣지 않고 청취자 자신의 익숙하지 않은 기술이나 패턴을 어떻게 다루십니까?

나는 그들을 피합니다. 새로 온 사람이 물어볼 때까지 블랙 박스로 둡니다. 그런 다음 자신의 시간을 더 많이 배울 수 있다는 힌트와 함께 정보를 제공하거나 나중에 일반적인 것들이 더 잘 알려지면 나중에 물어보십시오.

비즈니스 로직과 코드 구조를 어디에 연결합니까?

하지 않으려 고 노력합니다. 신입생이 스스로 사고하는 방식에보다 자연스러운 구조로 자신의 마음에 앉을 수 있도록 스스로 배우는 것이 거의 항상 좋습니다.

기억해야 할 것은 명령을 짧게 유지하는 것입니다. 사람들은 꽤 빨리 체크 아웃하는 경향이 있으므로 그 시점에서 더 이상 지시하지 않아도 '고착'되지 않습니다. 그들에게 15-60 분 동안 물건을 보여주고 (다른 사람들은 서로 다른 관심 범위를 가짐) 그것을 처리하기 위해 5-30 분 휴식을 취하십시오.

내 경험에 따르면 아키텍처 다이어그램이 제공하는 광범위한 개요와 실제로 코드를 사용하여 작업하는 데 대한 세부적인 내용 사이의 격차를 해소하는 좋은 방법은 시스템의 드릴 다운, 즉 요청이 도착할 때 발생하는 일입니다 (서버 코드의 경우). ) 또는 사용자가 (클라이언트 코드의 경우) 입력 한 다음 관련된 모든 코드 계층을 단계별로 설명합니다.

또 다른 방법은 소스 코드의 "가이드 투어"입니다. 즉, 패키지 / 네임 스페이스 / 모듈 / 디렉토리를 통해 각 코드의 일반적인 기능을 설명합니다. 물론 이것은 코드가 다소 논리적으로 배치되어야합니다.

당신은 당신이 그 (것)들에게 가르치고, 그들에게 코드베이스를 가르치는하지 않을 당신의 일을. 그들이 필요한 것을 생각하려고하지 말고, 일을 할 때 실제로 알아야 할 것을보십시오.

지난 몇 달 동안의 버그 추적 기록, 스크럼 사용자 사례, 상태 보고서 및 소스 제어 커밋을 가져옵니다. 어떤 파일을 가장 많이 터치 했습니까? 가장 문제가되는 코드는 무엇입니까? 어떤 일이 가장 오래 걸렸습니까? 지난 몇 달 동안 만지지 않았다면 생각만큼 중요하지 않을 수 있습니다.

책상 위의 인쇄물 더미를보십시오. 최근 브라우저 기록을 확인하십시오. 자주 참조하는 저장된 이메일, 사용하는 연락처, 다운로드 한 문서를 찾으십시오. 내가 다른 사람들에게 전달한 가장 유용한 참고 문헌 중 하나는 시스템을 처음 배우거나 디자인 할 때 내가 유지 한 메모입니다. 어떤 표준 물질은 대부분의 유용 당신 ?

다음으로 알려진 백 로그를 가져옵니다. 그러한 일을 끝내기 위해 어떤 것들을 연구해야합니까? 어떤 코드 영역에 문제가있을 가능성이 가장 높습니까? 메모를하는 것처럼 정보를 전달하십시오.

일상 업무에서 차트 나 도표를 참조 할 경우이를 포함 시키십시오. 한 번도 귀찮게 한 적이 없다면 아마도 후임 / 동료에게 그렇게 유용하지 않을 것입니다.

가르 칠 때 가장 어려운 과제 중 하나는 자신을 신발에 넣는 것입니다. 이 경우, 당신 은 그들의 신발에 있습니다. 최대한 활용하다.

지원 작업은 최고이며, 쉽게 버그를 발견하고 발견 할 수있는 영역을 안내합니다. 그들은 코드가 어떻게 어울리는지를 빠르게 배울 것입니다. 당연히이 버그와 코드베이스에 대한 질문을하기 위해 올 것입니다. 그러나 그들은 거기에 도착할 것입니다 (그리고 버그가 수정 될 것입니다). 종종 예제를 통해 이해하기가 훨씬 쉽고, 마찬가지로 디버거에서 코드베이스를 실행하여 코드베이스를 쉽게 해결할 수 있습니다.

코드 변경이 확실하지 않은 경우 (또는 일반적으로 코드베이스에 익숙해 질 때까지 코드 수정이 확실하지 않은 경우) 체크인 전에 검토 할 수 있습니다.

물론, 광범위한 개요 및 블록 다이어그램에 대한 기존 아이디어는 필수 첫 단계입니다.