새롭고 향상된 인터페이스 구현을 위해 이전 버전과의 호환성을 포기할 때는 언제입니까? [닫은]

나는 같은 소프트웨어 회사에서 10 년 이상 일해 왔습니다. 결과적으로 다양한 객체 지향 프로그래밍 언어를 사용하여 큰 코드 기반을 구현했습니다. 나는 처음 커리어를 시작할 때 초보자 프로그래머였으며 훌륭한 인터페이스 및 클래스 디자인 원칙에 대해 많이 알지 못했습니다. 디자인 기술이 시간이 지남에 따라 향상되었다고 생각하고 싶지만, 이전 버전과의 호환성 문제로 인해 이전 코드를 개선하는 데 점점 더 많은 어려움에 직면하고 있습니다. 내 코드는 회사에서 판매하는 제품의 일부로 많은 고객이 사용합니다.

내 질문은 : 오래된 인터페이스의 이전 버전과의 호환성을 유지하고 새로운 디자인을 구현하기 위해 총알을 물려고 할 때 언제해야합니까?

이전 버전과의 호환성을 유지하는 것이 큰 부담이되어 인터페이스에 대한 유용한 변경이 불가능한 시점이 있다고 생각합니다. 피드백을 제공 할 수있는 유사한 우려가있는 사람이 있습니까?

'언제'가 좋은 질문이지만 '어떻게'가 더 관련성이 있다고 생각합니다. 사용자를 실망 시키거나 불행하게 만들지 않는 방식으로 전환하기가 어려울 수 있습니다. 고려해야 할 사항 :

• 전환에 앞서 고객 / 고객과 의사 소통하십시오. 왜 그리고 어떻게 구현 될 것인지 설명하십시오. 보안, 성능, 안정성 및 향후 유연성을 이유로 인용하는 것이 모두 유효합니다.
• 어쨌든 깨끗하게 휴식을 취하고 있다면 피드백을 요청하십시오.
• 타사 개발자가있는 경우 입력 내용을 이해하기 쉬운 정도로 포함시켜야합니다.
• 가능하면 호환성 계층을 제공하십시오.
• 종합적인 업그레이드 안내서를 제공하십시오.
• 업그레이드를 가능한 한 쉽고 간단하게하십시오. 약간의 작업이 필요하더라도 사용자의 고통을 최소화하십시오.
• 충전하면 새 버전으로 업그레이드 할 때 할인 혜택을 제공하십시오.
• 새 버전 에 최소한 몇 가지 새롭고 유용한 기능을 추가 하여 업그레이드를 장려하십시오. 이것은 업그레이드가 관리자에게 더 매력적으로 보이도록하는 데 특히 중요합니다.
• 휴식을 취하면 마지막에 필요할 때 휴식을 취하십시오. 이는 사전에 포괄적 인 계획을 세우고 모든 것이 올바르게 설정되었는지 확인하는 것을 의미합니다.
• UI가 있다면 쉽게 변경할 수 있습니다. 재 설계보다는 새로 고침을 생각하십시오. 기술이 아닌 사용자의 경우 한 버전에서 다른 버전으로 UI를 크게 변경하면 좌절의 큰 원인이 될 수 있습니다.
• 새 버전은 이전 버전보다 훨씬 안정적이고 성능이 뛰어납니다. 사용자에게 업그레이드를 다시 보내야 할 이유를주지 마십시오. 사전에 광범위한 테스트 (단위, 통합 및 베타 테스트)없이 새 버전을 출시하지 마십시오.
• 이전 버전을 동시에 오랫동안 유지하십시오. 단계적으로 철폐하고 지원을 중단하기로 결정한 경우 가능하면 6-12 개월 전에 통지하십시오.
• 재정과 인력 측면에서 두 가지 버전을 동시에 유지할 수 있습니까? 또한 비즈니스 관점에서는 이전 버전에 집착하고 업그레이드하지 않으려는 나머지 클라이언트를 잃을 여유가 생길 때까지 이전 버전에 대한 지원을 중단해서는 안됩니다. 그것을 유지하는 것이 이익보다 중요합니다.)
• 필요한 경우 이전 버전이 중단 된 후 일정 기간 동안 보안 업데이트를 수행합니다.
• 다시 말하지만, 모든 과정에서 의사 소통은 거대합니다. 사용자 / 클라이언트 / 고객은 언제라도 버림받지 마십시오. 그들의 충성과 열정은 비즈니스의 기초입니다. 블로그 나 포럼에서 질문에 답변해야합니다. 사회적 요인을 과소 평가해서는 안된다.

'언제'에 관해서는 아마도 다른 사람보다 응용 프로그램에 대한 더 나은 아이디어를 가질 것입니다. 그러나 일반적으로 기술 부채 및 아키텍처가 안정성을 완전히 억제하고 합리적인 성능을 방지하며 새로운 기능의 개발을 압도적으로 또는 불필요하게 어렵게 만들면 깨끗하게 휴식을 취해야 할 때입니다.

이 단계를 가볍게 수행하지 마십시오. 올바르게 수행하더라도 이전 버전과의 호환성을 깨는 것은 큰 문제입니다. 휴식 시간을 고려하기 전에 먼저 테스트 적용 범위를 늘리고 리팩토링을 고려해야합니다.

일반적으로 나는 제임스 앤더슨에 동의합니다. 그러나 내 경험에는 고려해야 할 추가 측면이 있으며 실제로는 진화하는 인터페이스를 허용하는 옵션을 가리킬 수 있습니다.

이 예제는 내가 작업하고있는 팀 중 하나의 것입니다. 그들은 적어도 한 달에 한 번, 때로는 심지어 매주 정기적으로 제품을 배송합니다. 새로운 기능과 새로운 플랫폼은 최신 버전에서만 지원되므로 고객은 업그레이드를 권장합니다. 업그레이드가 쉽고 고객은 중간에 버전을 건너 뛸 수 있습니다. 다운 그레이드는 지원되지 않습니다. 또한 버전은 3 년 동안 만 지원됩니다. 그 후 유지 보수 비용이 두 배로 증가하는 1 년의 유예 기간이 있습니다.

그 결과, 고객의 약 95 %가 대부분 1 년에 한 번 정기적으로 업그레이드하고 있습니다. 또한 점진적으로 새로운 인터페이스를 도입 할 수 있습니다.

오래된 인터페이스는 어떻습니까? 이 팀에서 사용하는 기술은 기존 인터페이스를 '종료'로 선언하는 것입니다. 그런 다음 새 인터페이스를 사용할 수 있고 이전 인터페이스는 아직 폐기되지 않은 12 개월의 기간이 있습니다. 새로운 인터페이스는 기존 인터페이스보다 더 나은 기능을 제공하므로 두 가지 인센티브가 있습니다. 기존 인터페이스 수명 종료와 새로운 인터페이스가 훨씬 더 우수합니다.

이 경우의 구식 인터페이스는 표준 주류 기술에 기반한 서비스 인터페이스로 점차 대체되는 플랫폼 별 기술이었습니다.

물론이 변화는 밤새 일어나지 않으며 완료 될 때까지 몇 년이 걸립니다. 그러나 기존 기술에 대한 투자를 중단하고 새로운 기술에 대한 투자를 허용했습니다. 고객에게 도움이 제공되고 발전 할 수 있습니다. 대부분은 최신 기술로의 전환을 환영합니다.

그러나이 특정 접근 방식은 시나리오에서 작동하지 않을 수 있습니다. 그것은 내가 함께 일하는 팀을 위해 확실히 작동합니다.

이미 좋은 답변을 얻었 으므로이 주제에 관한 Joel Spolsky의 훌륭한 기사에 대한 포인터를 추가하고 싶습니다. 그는 IE 8에서 이전 버전과의 호환성을 포기하는 계획을 논의하고 있으며 이는 본질적으로 귀하의 문제와 동일합니다.

http://www.joelonsoftware.com/items/2008/03/17.html

짧은 대답은 절대입니다!

경험에 따르면 최소한 호환성이 떨어지면 고객과 사용자는 성가 시게되며 최악의 상태에서는 완전히 손실됩니다.

사용자에게 코드를 다시 쓰도록 요청하는 경우, 사용자와 모든 자손에 대한 관례적인 저주를 마친 후에는 "어쨌든 다시 써야한다면 내가 읽고있는 ACME 라이브러리로 전환해야 할 것입니다. 너무 많이? "

트릭은 이전 버전과의 호환성을 유지하지 않는 방식으로 현재 인터페이스를 향상 시키거나 이전 인터페이스를 유지하면서 완전히 새롭고 분명히 우수한 인터페이스를 제공하는 것입니다. 언젠가는 새로운 인터페이스에는 구식 인터페이스에서는 불가능했던 기능들이 있지만, 이는 사람들에게 문제를 일으키지 않고 움직일 동기를 부여합니다.

이를 더 명확히하기 위해 편집하십시오.

프로그래머로서 당신이 생각하는 것은-

"이 API를 개선하고 가능한 한 시스템을 좋게 만들고 모든 사람들이 나를 존경 할 것입니다."

API 사용자가 생각하는 것은-

"A * * * e 그는 나의 시간과 일정이 중요하지 않다고 생각한다. 나는 내가하고있는 일을 중단하고 그의 자아를 만족시키기위한 것 외에 다른 이유없이 모든 코드를 리팩터링해야한다. 리팩터링해야한다면 나는 전환 할 것이다. 또 다른 API를 사용하기 만하면됩니다. "

이것은 실제로 기술적 결정보다 비즈니스 결정에 더 가깝습니다. 일반적으로 이는 주요 릴리스 (예 : 버전 3.5에서 버전 4.0으로 진행)의 일부로 수행되며 종종 두 버전이 동시에 병렬로 지원됩니다. 즉, 이전 버전에서 유지 관리를 수행하지만 모든 새로운 기능은 새 버전에만 나타납니다. 구 버전은 회사가 돈을 벌거나 최소한 유지 보수 비용을 상쇄하기에 충분한 한 지원됩니다. 이를 경영진에게 제시 할 준비를하십시오.

나는이 쪽의 고객쪽에 있었으므로 전환에 대해 무엇을 할 것인지에 달려 있다고 말하고 싶습니다.

현재 계정 시스템을 업그레이드하고 있습니다. 업그레이드를 수행하는 회사는 이전 버전과 호환되지 않는 버전도 지원합니다. 그들은 데이터를 가져 와서 새로운 시스템으로 옮겨서 (이론적으로) 모든 이전 데이터가 거기에 있도록 계획합니다. 데이터 변환에 수백 파운드를 지불 할 것입니다. 문제 없어요.

내가 일한 anothe rcompany의 이전 상황과 비교하십시오. 공급 업체는 기존 시스템에서 새로운 시스템으로 전환 할 방법이 없었습니다. 이를 통해 다른 모든 공급 업체와 동일한 상황에 처하게되었습니다. 사실 우리는 그들이 업그레이드를 도와 주겠다는 약속을하지 않았기 때문에 상황이 더 나빴습니다. 그들은 새로운 계약을 얻지 못했습니다.

고객을 확보하고 유지하는 데 많은 노력을 기울였습니다. 전환을 어떻게 완화 할 수 있습니까?