Làm thế nào để bạn đối phó với sự thay đổi trong các khung nguồn mở mà bạn sử dụng cho các dự án của mình?

Nó có thể là một vấn đề cá nhân của tôi, nhưng tôi thích giữ mã trong các dự án sống được cập nhật - bao gồm các thư viện / khung mà họ sử dụng. Một phần của nó là tôi tin rằng một ứng dụng web sẽ an toàn hơn nếu nó được vá đầy đủ và cập nhật. Một phần của nó chỉ là một liên lạc của sự cưỡng chế ám ảnh về phía tôi.

Trong bảy tháng qua, chúng tôi đã thực hiện viết lại phần mềm chính của chúng tôi. Chúng tôi đã bỏ khung Xaraya, một sản phẩm chậm và về cơ bản đã chết như một sản phẩm và chuyển đổi sang Cake PHP. .

Chúng tôi đã triển khai thử nghiệm đơn vị với SimpleTest và tuân theo tất cả các quy ước đặt tên tệp và cơ sở dữ liệu, v.v.

Bánh hiện đang được cập nhật lên 2.0. Và, dường như không có đường dẫn di chuyển khả thi để nâng cấp. Các quy ước đặt tên cho các tệp đã thay đổi hoàn toàn và chúng đã bỏ SimpleTest để ủng hộ PHPUnit.

Điều này khá nhiều sẽ buộc chúng tôi ở lại nhánh 1.3 bởi vì, trừ khi có một loại công cụ chuyển đổi nào đó, sẽ không thể cập nhật Cake và sau đó cải thiện dần mã di sản của chúng tôi để gặt hái những lợi ích của khung Cake mới . Vì vậy, như thường lệ, chúng tôi sẽ kết thúc với một khung cũ trong kho Subversion của chúng tôi và chỉ cần tự vá nó khi cần thiết.

Và đây là những gì tôi nhận được mỗi lần. Vì vậy, nhiều sản phẩm nguồn mở không làm cho nó đủ dễ dàng để giữ cho các dự án dựa trên chúng được cập nhật. Khi các nhà phát triển bắt đầu chơi với một đồ chơi sáng bóng mới, một vài bản vá quan trọng sẽ được thực hiện cho các nhánh cũ hơn, nhưng phần lớn trọng tâm của họ sẽ tập trung vào cơ sở mã mới.

Làm thế nào để bạn đối phó với những thay đổi căn bản trong các dự án nguồn mở mà bạn sử dụng? Và, nếu bạn đang phát triển một sản phẩm nguồn mở, bạn có giữ các đường dẫn nâng cấp trong tâm trí khi bạn phát triển các phiên bản mới không?

Vấn đề không phải là duy nhất đối với nguồn mở. Các vấn đề tương tự xảy ra với các dự án thương mại. Thậm chí có thể nhiều hơn bởi vì bạn không có nguồn, bạn có thể tự duy trì nếu công ty giảm hỗ trợ.

Các dự án nguồn mở loại người dùng cuối có chu kỳ nâng cấp nhanh chóng và các phiên bản cũ mất hỗ trợ rất nhanh. Mặt khác, các dự án được thiết kế cho người dùng để đặt mã hóa nỗ lực đáng kể lên hàng đầu có xu hướng có chu kỳ hỗ trợ dài của chi nhánh cũ sau khi nâng cấp lớn. Đủ lâu để bạn dành thời gian đầu tiên chờ nó ổn định và trưởng thành, sau đó di chuyển và kiểm tra kỹ mã của chính bạn.

Có thể khó chống lại sự cám dỗ để có bản mới nhất và lớn nhất, nhưng nhận ra rằng có một sự đánh đổi cơ bản trong phần mềm giữa tính ổn định và tính năng mới. Bạn không thể có cái này mà không phải hy sinh cái kia. Đó là lý do tại sao các nhánh bugfix tồn tại, vì vậy bạn có thể chọn phía nào của phổ phù hợp nhất với nhu cầu của bạn.

Chúng tôi đã xử lý vấn đề này bằng cách mô đun hóa mã của chúng tôi.

Trang web chính của chúng tôi đã được xây dựng khoảng tám năm trước và chúng tôi đã may mắn được xây dựng bởi một trong những người đóng góp ban đầu cho Spring Framework nên nó là một nền tảng được xây dựng khá tốt. Nhưng thật không may, chúng tôi cũng không may mắn khi nhà phát triển này quyết định rẽ nhánh Spring sau một cuộc tranh cãi về hướng đi của nó, vì vậy, cơ sở mã này hiện đang bị kẹt trên một ngã ba không rõ ràng của Spring 1.1.4 (hoặc một cái gì đó cổ điển).

Chúng tôi đã cố gắng viết lại mã để chuyển sang các phiên bản mới của Spring, nhưng điều đó tỏ ra vô cùng khó khăn. Vì vậy, giải pháp của chúng tôi là bắt đầu xây dựng các tính năng mới của trang web dưới dạng các mô-đun trong một ứng dụng hoàn toàn riêng biệt, sử dụng các khung mới nhất như Spring 3.x, Hibernate 3.6, v.v.

Bây giờ chúng tôi có hai ứng dụng web chạy trên cùng một URL cơ sở và chúng tôi sử dụng mô-đun mod_proxy của Apache để phân bổ từng đường dẫn đến ứng dụng phù hợp. Ví dụ: "/ thành viên" chuyển đến ứng dụng cũ và "/ thư mục" chuyển đến ứng dụng mới. Tuy nhiên, khách truy cập vào trang web sẽ không biết rằng họ đang sử dụng các ứng dụng khác nhau; Chúng trông giống hệt người dùng.

Hai ứng dụng cần liên lạc, ví dụ khi một thành viên đăng nhập vào trang web (sử dụng ứng dụng mới của chúng tôi), chúng tôi cần thông báo cho ứng dụng cũ mà họ hiện đang đăng nhập. Chúng tôi thực hiện điều này bằng một dịch vụ web đơn giản, chỉ tiếp xúc với lưu trữ cục bộ. Số lượng tích hợp cần thiết giữa hai ứng dụng hóa ra là tối thiểu.

Một phần quan trọng của việc thực hiện công việc này là xác định và đóng gói các tài sản chung. Vì vậy, tất cả văn bản tĩnh, đồ họa, biểu định kiểu, Javascript và mẫu đã được chuyển khỏi ứng dụng gốc thành một dự án riêng - thứ ba mà cả ứng dụng mới và cũ đều sử dụng. Điều này đảm bảo rằng cả hai ứng dụng web đều nhìn và hoạt động giống nhau mặc dù chúng hoàn toàn tách biệt.

Tôi tưởng tượng rằng theo thời gian chúng ta sẽ thay thế ngày càng nhiều ứng dụng gốc cho đến khi cuối cùng nó hoàn toàn không cần thiết. Điều hay ho của kỹ thuật này là chúng ta có thể thực hiện từ từ thông qua một loạt các thay đổi nhỏ, ít rủi ro - không cần phải chuyển đổi đột ngột và mạo hiểm sang một hệ thống mới.

Tôi không luôn luôn làm điều đó. Rất nhiều dự án nguồn mở có các nhánh bảo trì tích cực được duy trì cho các bản phát hành chính trước đó. Đôi khi những người được duy trì bởi những người cần phiên bản đó được duy trì. Rất nhiều dự án ở lại trên một bản phát hành lớn cho đến khi chính họ đã sẵn sàng cho một bản phát hành lớn.

Và đây là những gì tôi nhận được mỗi lần.

Mỗi thời gian? Bạn phải đưa ra lựa chọn tồi tệ đáng chú ý. Phải có một ví dụ về việc nó đã không xảy ra.

Khi các nhà phát triển bắt đầu chơi với một món đồ chơi sáng bóng mới

Đó là một gợi ý. Tránh đồ chơi mới sáng bóng khi sử dụng các dự án nguồn mở. Tránh phát hành 1.0.

Làm thế nào để bạn đối phó với những thay đổi căn bản trong các dự án nguồn mở mà bạn sử dụng?

Bước 1. Chọn các dự án nguồn mở rất, rất cẩn thận. Luôn so sánh hai hoặc nhiều dự án cạnh tranh.

Bước 2. Khi so sánh hai dự án cạnh tranh, hãy cố gắng hiểu tính năng "thiết yếu" được cung cấp và cách cả hai tiếp cận nó. Tránh "kết hôn" với một API cụ thể quá sớm.

Bước 3. Nắm bắt các nguyên tắc thiết kế của "Ràng buộc muộn" và "Khớp nối lỏng lẻo". Cố gắng cách nhiệt từ các thay đổi dự án nguồn mở.

Bước 4. Hoàn toàn so sánh chi phí / lợi ích giữa các dự án nguồn mở và "tự mình thực hiện". Thỉnh thoảng, tạo giải pháp của riêng bạn có thể tốt hơn là đối phó với giải pháp nguồn mở.

Thay đổi tên tập tin không nên quá khó. Vâng, đó là một kịch bản lớn, xấu xí. Có, nó phải được chạy trong vài tuần trong khi thực hiện chuyển đổi. Nhưng đó là một chi phí hữu hạn.

Nếu nếu xảy ra mọi lúc, thì hãy phát triển các chiến lược đối phó tốt hơn. Vì quan sát của bạn về thế giới thực là nó sẽ luôn xảy ra, nên hy vọng thế giới thực thay đổi sẽ không thực sự giúp ích nhiều. Bạn có một số kinh nghiệm khó thắng trong thay đổi. Tận dụng điều đó. Coi nó giống như một bệnh nhiễm trùng và phát triển phản ứng miễn dịch của riêng bạn.