프로젝트에 사용하는 오픈 소스 프레임 워크의 변화에 ​​어떻게 대처합니까?

개인적인 문제 일지 모르지만 사용하는 라이브러리 / 프레임 워크를 포함하여 살아있는 프로젝트의 코드를 최신 상태로 유지하는 것이 좋습니다. 그것의 일부는 웹 응용 프로그램이 완전히 패치되고 최신 상태라면 더 안전하다고 생각합니다. 그것의 일부는 내 부분에 강박 관념입니다.

지난 7 개월 동안 우리는 소프트웨어를 대대적으로 다시 작성했습니다. 우리는 제품으로 느리고 본질적으로 죽은 Xaraya 프레임 워크를 삭제하고 Cake PHP로 변환했습니다. (케이크는 소프트웨어를 매우 빠르게 재 작성할 수있는 기회를 제공했으며, Xaraya에 비해 성능을 충분히 향상시켜 우리의 가치를 높일 수 있었기 때문에 Cake를 선택했습니다.)

우리는 SimpleTest로 단위 테스트를 구현했으며 모든 파일 및 데이터베이스 명명 규칙 등을 따랐습니다.

케이크는 이제 2.0으로 업데이트되고 있습니다. 그리고 업그레이드를위한 실행 가능한 마이그레이션 경로가없는 것 같습니다. 파일의 이름 지정 규칙이 크게 바뀌었고 PHPUnit을 위해 SimpleTest를 삭제했습니다.

이것은 일종의 변환 도구가 없다면 Cake를 업데이트 한 다음 점차 새로운 레거시 프레임 워크의 이점을 얻기 위해 레거시 코드를 점진적으로 개선 할 수 없기 때문에 1.3 브랜치에 머물게 할 것입니다. . 따라서 평소와 같이 Subversion 저장소의 오래된 프레임 워크로 끝나고 필요에 따라 직접 패치 할 것입니다.

그리고 이것은 매번 나를 얻는 것입니다. 수많은 오픈 소스 제품으로 인해 프로젝트를 최신 상태로 유지하기가 쉽지 않습니다. 개발자가 새로운 반짝이는 장난감을 가지고 놀기 시작하면 오래된 지점에 몇 가지 중요한 패치가 적용되지만 대부분의 초점은 새로운 코드 기반에 있습니다.

사용하는 오픈 소스 프로젝트의 급진적 인 변화를 어떻게 처리합니까? 오픈 소스 제품을 개발하는 경우 새 버전을 개발할 때 업그레이드 경로를 염두에 두어야합니까?

이 문제는 오픈 소스에만 국한되지 않습니다. 상용 프로젝트에서도 동일한 문제가 발생합니다. 소스가 없기 때문에 회사가 지원을 중단하면 자신을 유지할 수 있습니다.

최종 사용자 유형의 오픈 소스 프로젝트는 빠른 업그레이드주기를 가지고 있으며 이전 버전은 매우 빨리 지원을 잃습니다. 반면에 사용자가 상당한 노력을 기울 이도록 설계된 프로젝트 는 크게 업그레이드 한 후 이전 지점에 대한 지원주기 가 길다 는 경향이 있습니다 . 시간이 오래 걸리고 안정화되고 성숙되기를 기다린 다음 자신의 코드를 마이그레이션하고 철저히 테스트하십시오.

최신의 가장 큰 유혹을 견뎌내는 것은 어려울 수 있지만 안정성과 새로운 기능 사이의 소프트웨어에는 근본적인 상충 관계가 있음을 인식하십시오. 다른 것을 희생하지 않고는 가질 수 없습니다. 그렇기 때문에 버그 수정 브랜치가 존재하므로 스펙트럼의 어느 쪽이 사용자의 요구에 가장 적합한지를 선택할 수 있습니다.

코드를 모듈화하여이 문제를 해결했습니다.

우리의 주요 웹 사이트는 약 8 년 전에 지어졌으며, 스프링 프레임 워크의 초기 공헌자 중 한 명이 웹 사이트를 구축 할 수있을만큼 운이 좋았 기 때문에 꽤 잘 세워진 기초였습니다. 그러나 불행히도 우리는이 개발자가 진행 방향에 대한 논쟁 후에 스프링을 포크하기로 결정했을 정도로 운이 좋지 않았 으므로이 코드베이스는 이제 스프링 1.1.4 (또는 그 빈티지의 것)의 유지되지 않는 포크에 붙어 있습니다.

우리는 새로운 버전의 Spring으로 이동하기 위해 코드를 다시 작성하려고 시도했지만 매우 어려웠습니다. 따라서 우리의 솔루션은 Spring 3.x, Hibernate 3.6 등과 같은 최신 프레임 워크를 사용하여 사이트의 새로운 기능을 완전히 별도의 애플리케이션에서 모듈로 구축하는 것이 었습니다.

이제 동일한 기본 URL에서 실행되는 두 개의 웹 응용 프로그램이 있으며 Apache의 mod_proxy 모듈을 사용하여 각 경로를 적절한 응용 프로그램에 할당합니다. 예를 들어 "/ members"는 이전 응용 프로그램으로 이동하고 "/ directory"는 새 응용 프로그램으로 이동합니다. 그러나 사이트 방문자는 다른 응용 프로그램을 사용하고 있는지 전혀 모릅니다. 그들은 사용자와 똑같이 보입니다.

예를 들어, 회원이 사이트에 로그인 할 때 (새로운 애플리케이션을 사용하여) 두 애플리케이션은 통신해야합니다. 기존 애플리케이션에 현재 로그인되어 있음을 알려야합니다. localhost. 두 앱간에 필요한 통합 양은 최소로 나타났습니다.

이 작업을 수행하는 데있어 중요한 부분은 공유 자산을 식별하고 함께 패키지하는 것이 었습니다. 따라서 모든 정적 텍스트, 그래픽, 스타일 시트, Javascript 및 템플릿은 원본 응용 프로그램에서 새 응용 프로그램과 기존 응용 프로그램이 모두 사용하는 별도의 세 번째 프로젝트로 옮겨졌습니다. 이를 통해 웹 응용 프로그램은 완전히 분리되어 있어도 동일한 방식으로 보이고 작동합니다.

시간이 지남에 따라 우리는 궁극적으로 완전히 필요하지 않을 때까지 점점 더 많은 원래 응용 프로그램을 교체 할 것이라고 생각합니다. 이 기술의 좋은 점은 일련의 작고 위험이 적은 변경을 통해 천천히 수행 할 수 있다는 것입니다. 새로운 시스템으로 대규모의 위험한 갑작스런 전환이 필요하지 않습니다.

항상 그런 것은 아닙니다. 많은 오픈 소스 프로젝트에는 이전 주요 릴리스에 대해 유지 보수 분기가 활발하게 유지됩니다. 때로는 해당 버전을 유지 관리해야하는 사람들이 관리합니다. 많은 프로젝트가 자체적으로 주요 릴리스 준비가 될 때까지 주요 릴리스를 유지합니다.

그리고 이것은 매번 나를 얻는 것입니다.

매번 ? 당신은 현저하게 나쁜 선택을해야합니다. 발생하지 않은 예가 하나 있어야합니다.

개발자가 새로운 반짝이는 장난감으로 게임을 시작하면

힌트입니다. 오픈 소스 프로젝트를 사용할 때 새 장난감을 피하십시오. 1.0 릴리스를 피하십시오.

사용하는 오픈 소스 프로젝트의 급진적 인 변화를 어떻게 처리합니까?

1 단계. 오픈 소스 프로젝트를 매우 신중하게 선택하십시오. 항상 두 개 이상의 경쟁 프로젝트를 비교하십시오.

2 단계. 경쟁하는 두 프로젝트를 비교할 때 제공되는 "필수"기능과 이들이 어떻게 접근하는지 이해하십시오. 하나의 특정 API를 너무 일찍 "결혼"하지 마십시오.

단계 3. "늦은 바인딩"및 "느슨한 커플 링"의 디자인 원칙을 받아들입니다. 오픈 소스 프로젝트 변경 사항을 차단하십시오.

단계 4. 오픈 소스 프로젝트와 "자신의 롤링"간에 비용 / 혜택을 명시 적으로 비교합니다. 가끔 오픈 소스 솔루션에 대처하는 것보다 나만의 솔루션을 만드는 것이 좋습니다.

파일 이름을 변경하는 것은 그리 어렵지 않습니다. 예, 크고 못생긴 스크립트입니다. 예, 변환하는 동안 몇 주 동안 실행해야합니다. 그러나 유한 한 비용입니다.

매번 일어날 경우 더 나은 대처 전략을 개발하십시오. 현실 세계에 대한 당신의 관찰은 그것이 항상 일어날 것이라는 것이므로, 현실 세계가 변화하기를 희망하는 것은 실제로 많은 도움이되지 않을 것입니다. 어려운 경험이 있습니다. 그것을 활용하십시오. 감염처럼 생각하고 자신의 면역 반응을 개발하십시오.