새로운 선임 개발자 작업

내일부터 11,000 줄의 코드 응용 프로그램에서 작업하기 시작한 8 년의 .NET 경험을 가진 선임 개발자가 있습니다. 팀에는 저와 다른 프로그래머가 있습니다. 우리는 각각 약 3 년의 경험을 가지고 있습니다.

관리자로서의 첫 번째 프로젝트이며 (프로젝트의 개발자이기도합니다.) 이미 확립 된 코드 기반을 누군가에게 소개 한 것은 이번이 처음입니다. 분명히 각 모듈, 배포 프로세스 등을 살펴보고 소스 제어 저장소의 위치, 문서 (최선이 아닌) 등을 전달할 것입니다.

새로운 기능을 작성하고 버그를 수정할 준비가되기 전에 얼마나 시간을 주어야합니까?

첫 날에는 우선 순위가 낮은 두 가지 버그를 지정하여 새 개발자가 코드베이스에 익숙해 질 시간을주지 않으면 아무도 비명을 지르지 않습니다.

가장 중요한 것은 첫 몇 주 동안 그의 모든 작업을 코드 검토하는 것입니다. 당신은 그 사람이 잘못된 방향으로 가고 있거나 회사 코딩 표준을 몇 달간 따르지 않는다는 것을 알고 싶지 않습니다. 그가 처음부터 예상되는 것을 알고 있는지 확인하는 것이 좋으며 코드 검토가이를 보장합니다. 물론 코드 검토는 모든 직원에게 도움이된다고 생각하지만 (배포 전에 코드의 100 %를 검토 함) 신입 사원에게는 매우 중요하며 질문에 대답 할 수 있고 직접 가지고 있지 않은 문서를 참조 할 수있는 사람에게 직접 수행해야합니다. 필요한 경우 아직 볼 수 있습니다.

당신이 원하지 않는 것은 새로운 사람이 들어 와서 다른 사람들과 다른 스타일을 사용하는 것입니다. 사람들은 종종 다른 장소의 개발자들에게 혼란과 성가심을 일으킬 수있는 새로운 장소에서 사용 된 코드 스타일과 충돌 할 때에도 이전 작업의 코드 스타일을 계속 사용하려고합니다.

경험이 풍부한 개발자에게도 주목할 점은 일부는 인터뷰에있는 것만 큼 좋지 않다는 것입니다. 코드 검토를 통해이를 빨리 찾을 수 있으므로 해결할 수 있습니다. 또한 실제로 무언가를 수행하도록 장려 할 것입니다. 코드를 검토하지 않은 신입 사원은 다른 사람에게하고있는 일을 보여주지 않고 프로젝트를 끌어다 놓은 것을 알았습니다. 그들은 고개를 숙이고 실제로 프로젝트의 어떤 부분도 완료하지 못했습니다. 그들이 새로운 운동을하고 있다고 확신 할 때까지 새로운 사람들과 함께 일찍 확인하는 것이 좋습니다.

또한 새로운 프로젝트가 레거시 프로젝트 상태에 겁을 먹는 것은 정상적인 일입니다. 그가 생각했던 방식으로 설계되지 않았습니다. 이것을 기대하고, 듣고, 그가 말하는 모든 것을 자동으로 닫지 마십시오. 특히,이 사람은 당신이나 다른 개발자들보다 더 많은 경험을 가지고있는 것으로 보입니다. 그러나 관리자는 제안 된 변경 사항을 현재 작업 부하 및 마감일과 균형을 이루어야합니다. 기존 코드를 리팩터링하는 방법을 배우는 데 약간의 시간을 투자하고 특히 새로운 사람이 유효한 우려가있는 경우 시간 코드를 추정하는 데 시간을 투자 할 수 있습니다. 당신은 아마도 완전한 재기록을 지원할 수 없을 것입니다 (새로운 사람들은 우리가 처음부터 다시 시작해야한다고 생각합니다),

그가 완전히 기여하지 않을 것으로 예상되는 시간이 있고 (고객이 자신의 시간을 완전히 설명 할 때), 그는 그가 원했지만 원했던 리팩토링 작업 중 일부를 시작할 수있는 시간 일 수도 있습니다. t는 할 시간이 있었다. 때때로, 새로운 개인 교육 기간을 사용하여 프로젝트 계획에없는 일부 사항을 해결하는 것이 좋습니다. 그들은 코드베이스를 배울 수 있고 그들이 원하는 것이 효과가 없다면, 기존 스케줄을 아직 고려하지 않았기 때문에 기존 스케줄에 영향을 미치지 않았습니다. 그리고 그것이 효과가 있다면, 향후 유지 보수를보다 쉽게하거나 보안을 향상 시키거나 문제가 무엇이든간에 큰 승리를 거둘 수 있습니다.

더 큰 그림이 필요없는 작은 작업에서 즉시 시작하십시오.

코드베이스에 대한 자신감과 친숙 함이 높아짐에 따라 더 크고 더 큰 작업으로 졸업합니다. 얼마나 빨리 일어나는가는 그들에 달려 있습니다.

나는 항상 코드를 파는 데 시간이 오래 걸리고 처음 며칠 / 주 동안 많은 질문을 할 것이라는 점을 이해하면서 배트에서 바로 과제를 배정받는 것을 좋아합니다.

나는 실제로 들어가서 무언가를 고치거나 바꿀 때까지 프로젝트에 머리를 완전히 감쌀 수 없다는 것을 알았습니다.

또한 ... 프로젝트가 어떻게 작동하는지 어떻게 설명했는지에 관계없이 항상 '오 그래, 나는 너에게 말하지 않았다', '우리는이 문제에 부딪쳤다. 당신은 실제로 일을 시작합니다.

얼마나 오래?

로프는 얼마나 걸립니까?

편안 할 때 : 첫 번째 버그를 고치면 준비가 됩니다.

오픈 소스 커뮤니티에서 프로젝트에 참여하고자하는 모든 사람들은 먼저 작은 문제를 처리합니다. 문제를 매우 잘 처리 할 수 ​​있으면 더 중요한 작업이 그에게 할당됩니다. 이런 식으로 그들은 프로젝트의 핵심 개발자가 될 것입니다.

이 선임 개발자는 8 년의 .NET 경험을 보유하고 있으므로 수정할 간단한 버그를 지정할 수 있습니다. 그를 다루기가 쉬운 경우 복잡한 문제를 할당하여 전체 응용 프로그램에 익숙해 지도록 할 수 있습니다. 그 후 그는 새로운 기능을 작성하고 이상한 문제를 분석 할 수있었습니다. 설정 시간이 없습니다!

8 년의 경험. 난 그냥 그를 던져 것입니다. 그는 수영을 할 수 있어야합니다. 다른 사람들이 언급했듯이 작은 쉬운 작업부터 시작하십시오. 이를 통해 코드 체크인 / 체크 아웃 프로세스 및 기타 개발 프로세스를 진행할 수 있습니다.

나는 일을 여러 번 바꿨고 첫 주 안에 모든 일에 기여했습니다. 코드를 컴파일하는 데 일주일이 걸렸습니다 (최소한 100k + 코드 줄). 전체 프로젝트는 8 시간이 걸렸습니다.

나는 첫 주에 80 시간 정도 일했다 (프로젝트는 심각하게 뒤처졌다).

작고 경험이 많은 개발자에게는 하루 정도면 기본적인 버그로 충분하다고 생각합니다. 일주일 가까이에 관련된 버그 나 작은 기능 (문제 영역과 아키텍처에서 명확 해지면)

대답은 다음과 같습니다. 무언가에 대해 하나의 오류로 인해 문제를 해결하거나 GUI 요소의 색상을 변경하려는 경우 약 5 분 (여기서는 코드를 유지하는 위치), 앱의 전체 아키텍처를 완전히 재 설계하려는 경우 조금 더 필요합니다.

그것은 실제로 당신이 그를 기대하는 작업에 달려 있습니다.