개발 작업에서 분리 된 유지 보수 작업이 왜 작동합니까?

Question

나는 동일한 팀이 소프트웨어에 생명을 불어 넣는 동일한 팀이 유지 보수를하는 회사에서 일합니다.

별도의 유지 보수 팀이나 유지 보수 프로그래머가있는 조직에 대해 자주 듣습니다. 내가 궁금한 점은 - 이것의 이유는 무엇입니까?

'오래된 코드'를 덜 필사자에게 버리는 것 외에도 어떤가요?

자신의 "정크"를 유지함으로써 배운 교훈은 훨씬 더 높은 가치가 있습니까? 결함을 고치는 것은 처음부터 결함을 초래 한 사람들이 수행 할 때 훨씬 더 효과적이지 않습니까?

별도의 유지 보수 팀을 갖는 것이 유익 할 수있는 실제 이유가 없습니까?

Answer 1

이것을 가장 잘 설명하기 위해 떠오르는 개념은 "대패"이것은 본질적으로입니다 전환 비용 유지 보수 작업 및 개발 작업을 모두 수행하는 것과 관련이 있습니다. 이것이 아마도 책임을 분리시키는 가장 큰 이유 일 것입니다. 다른 사람들은 주니어 또는 엔트리 레벨 프로그래머에게 발을 젖게 할 수있는 기회를 허용하고 경험이 풍부한 개발자가 더 높은 가치 품목을 생산할 수 있도록하는 것입니다.

동시에, 나는 개발자가 그것을 지원 해야하는 앱을 쓴 앱을 작성한 가치가 있다고 생각합니다. 첫째, 그들은 코드에서 배울 수있는 문제를 매우 빨리 찾을 것입니다. 둘째, 그들은 생각할 것입니다 유지 가능성과 품질 그들이 그것을 지원해야하기 때문에 코드.

실생활 스 래싱 예 :

귀하는 1500 시간 개발 프로젝트를 받았으며 마지막 3 응용 프로그램에 대한 시스템 유지 관리 및 지원을 담당합니다. 이 새로운 프로젝트에서는이 3 개의 앱을 지원하기 위해 평균 7 회 중단됩니다. 다른 3 앱에서 작업하기 시작할 때마다 20 분 동안 문제를 해결하는 데 20 분이 걸립니다. 문제를 해결 한 후, 새로운 앱에서 마지막으로 만지는 코드 주위에 마음을 감싸는 데 20 분을 소비합니다. 이는 중단 당 40 분 또는 주당 280 분입니다. 즉,이 앱을 지원하기 위해 전환 할 때 일주일에 2.67 시간의 생산성을 잃었습니다.

Answer 2

나는 1 년 넘게 민첩한 팀에서 일하고 있습니다. 라이브 제품의 경우에는 실제로 중요하지 않다고 생각합니다 (최신 버전 만 사용하는 클라이언트). 그러나 시장에 여러 버전의 제품이 있으며 각 제품을 지원해야한다고 말합니다.

예를 들어 벤틀리의 미세 조정을 가져 가십시오. 3D (건축, 식물 설계, Rails Roads Bridges 등)를위한 설계 응용 프로그램입니다. 이제 시장에 V8, V9, V10이 출시되었다고 가정 해 봅시다. 다른 기능이 있으며 파일 형식은 버전보다 크게 변경되었습니다. 그러나 프로젝트는 매우 거대 (또는 클라이언트가 매우 중요 함) V8 클라이언트와 V9 클라이언트를 지원하면서 V10을 개발해야합니다. 따라서 회사는 유지 관리 팀 (또는 시간)이 이전 버전에 할당되어 있어야합니다. 또한 제품이 사용자 정의 및 위에서 언급 한 시나리오를 지원하는 경우 일반적으로 이러한 팀을 사용자 정의 팀이라고합니다.

Answer 3

문제는 더 실용적입니다.

• 오래된 코드는 더 이상 회사 나 팀에 있지 않은 사람들에 의해 작성되었습니다.
• 오래된 코드는 외부 개발자가 작성했습니다.

많은 회사에서 원래 코더가 더 이상 유지되지 않기 때문에 더 이상 원래 코더가 유지 관리하지 않는 코드베이스를 갖는 것이 실제로 일반적입니다. 코드 기반이 충분히 커지면 누군가가 최신 상태로 유지하여 관리자라고합니다.

이 사건을 피할 수 있다면, 당신에게 좋지만 항상 일시적인지 확인하십시오.

Answer 4

나는 관행에 동의하지 않지만 많은 조직에서 컨설턴트는 소프트웨어를 짧게 작성하여 서둘러 노력한 후 프로젝트를 사내 프로그래머에게 "유지"하기 위해 전달됩니다. 이론적 근거는 훈련없이 숙련 된 사람을 데려오고 소프트웨어를 그대로 유지하기 위해 노력할 사람들에게 "지식 이전"을 포함하도록 할 수 있다는 것입니다.

요컨대, 많은 시간은 정치적/실용적 인 이유로 이루어집니다.

Answer 5

유지 보수 및 기능 개발 팀을 분할하는 동기는 일을 원활하게 실행하는 것입니다. 기능 개발 팀이 버그 수정을 처리하기 위해 수행하는 작업을 계속 중지 해야하는 경우 프로젝트가 중단됩니다. 별도의 유지 보수 팀을 보유하면 나머지 개발자들이 문제의 프로젝트/제품을 발전시킬 수 있습니다.

Answer 6

저의 첫 번째 직업은 일부 소프트웨어 모듈을 유지하는 것이 었으며, 오리지널 개발자는 새로운 프로젝트로 넘어갔습니다.

나는 추측한다 :

• 새로운 개발을보다 예측 가능하고 쉽게 예약 할 수있게합니다.

• 새로운 개발자를 훈련시킬 수있는 기회 (예 : 나)

또한 내가 유지 관리하고있는 코드는 "정크"가 아니 었습니다. 벨 등과 같은 고객에게 배포 된 초기 패킷 전환 네트워크 인 Telco Software였습니다. 테스트 케이스), 유지 관리 가능, 많은 로그 파일, 일부 설계 문서 ...

... OP의 자막은 "Man,이 코드는 악취가납니다! 원래 개발자를 얻고 문지르기를 바랍니다. 그의 코 : 저것 그를 배울 것입니다! "

따라서 코드가 이미 잘 작성된 경우 해당 주장 (원래 개발자를 가르치는)은 적용 할 수 없습니다.

내가 "유지 보수"를하고 있다고 말할 때 새로운 기능 개발과 비슷하지만 매우 사소한 기능이 있습니다. 예를 들어, 프로토콜 사양을 약간 특이한 방식으로 해석 한 새로운 고객 장치와 상호 작용합니다.

문제를 분석하고 진단하고 수정을 코딩했습니다. 그리고 QA 담당자는 자동 테스트 스위트에 새로운 해당 테스트 케이스를 추가 할 것입니다.

Answer 7

내가 볼 수있는 한 가지 장점은 조직에 코드를 수정하기에 충분히 이해할 책임이있는 다른 사람이 있다는 것입니다. 또한,이 사람은 다른 의제를 염두에두고 디자인/개발 리뷰 (자신이되어야하는)에 들어간 경우 유지 보수 관점에서 코드를 검토 할 수 있습니다.

또한 "유지 보수"는 배포, 구성, 백업 등과 같은 다양한 활동을 참조 할 수 있습니다. 이는 다른 팀이 반드시 처리해야합니다.