Vòng đời tính năng và những đặc tính của mô hình phát triển nguồn mở

Trong số tháng 03/2012 của tạp chí Tin học & Đời sống, chúng ta đã làm quen với mô hình phát triển phần mềm tự do qua bài “Tìm hiểu mô hình phát triển phần mềm tự do nguồn mở”. Trong số này, chúng ta sẽ làm quen với vòng đời tính năng và những đặc tính của mô hình phát triển này.

A. VÒNG ĐỜI TÍNH NĂNG CỦA NGUỒN MỞ

1. Qui trình yêu cầu tính năng

Các yêu cầu tính năng thường được theo dõi và được ưu tiên bằng việc sử dụng các qui trình nhìn thấy được đối với phần còn lại của cộng đồng phát triển. Điều này đảm bảo cho một sự hiểu biết chung về những tính năng nào đã được yêu cầu, ưu tiên tương đối của chúng, tình trạng phát triển của chúng, các lỗi và các rào cản có liên quan, và khi nào chúng được lên kế hoạch để phát hành.

Hình 2: Vòng đời của tính năng trong mô hình phát triển nguồn mở

Hình 3: Dòng chảy của mã nguồn từ những người đóng góp cho tới phiên bản dòng chính cho tới thị trường

Hình 3 chỉ ra qui trình đặc trưng được sử dụng để đảm bảo rằng các yêu cầu tính năng được theo dõi, được ưu tiên, được phát triển và được phát hành một cách tỉ mỉ chính xác.

Các yêu cầu tính năng có thể bắt đầu bằng một đề xuất tới một danh sách thư, một thảo luận trên trình chat có độ trễ trên Internet IRC (Internet Relay Chat), hoặc như một yêu cầu tính năng trong một chương trình quản lý lỗi phát sinh bugzilla của dự án. Yêu cầu đó thường được ai đó thực hiện mà người đó thường là người dẫn dắt triển khai công việc đó. Mục đích của yêu cầu là để lưu ý cho những người khác về nhu cầu, đề xuất xin ý kiến phản hồi, có được sự chấp nhận cho ý tưởng, và đi tới được một sự đồng thuận trong các bước tiếp sau.

Những người đóng góp và những người duy trì dự án sau đó đánh giá yêu cầu đó, và xác định liệu nó có nên là một ứng viên cho một phát hành trong tương lai hay không. Sẽ thường có những thảo luận giữa người đưa ra yêu cầu và cộng đồng phát triển để làm sáng tỏ các nhu cầu và các yêu cầu. Nếu yêu cầu được chấp nhận, thì một phát hành đích sẽ được thiết lập, và sự phát triển bắt đầu.

2. Thảo luận về kiến trúc và thiết kế

Một trong những yếu tố đóng góp chính cho thành công của mô hình phát triển nguồn mở là sự minh bạch của nó, và khả năng dàn xếp sự cộng tác phân tán giữa các đội dự án. Điều này được hoàn thành bằng việc sử dụng các phương pháp giao tiếp truyền thông có khả năng truy cập được đối với tất cả mọi người trong cộng đồng của dự án để đưa ra quyết định chiến lược, những thảo luận về kiến trúc và rà soát lại mã nguồn.

Các danh sách thư là một trong những kênh giao tiếp thường được sử dụng nhất vì chúng là tự ghi thành tài liệu, minh bạch, và thường bất kỳ ai có liên quan trong dự án đều có thể tham gia. Điều này bao gồm cả những người sử dụng đầu cuối, những người có thể đang giám sát các danh sách để hiểu được các tính năng trong tương lai khi chúng tiến hóa hoặc để đưa ra những ý kiến phản hồi thực tế.

Bổ sung thêm vào với các danh sách thư của dự án, nhiều đội phân tán sử dụng IRC cho thảo luận trực tiếp và các cuộc gặp. Vì bản chất tự nhiên chỉ là văn bản của nó, IRC là hữu dụng cho các cuộc gặp về thiết kế và hỗ trợ của những người sử dụng, đặc biệt khi mà tiếng Anh không phải là ngôn ngữ đầu tiên được nói của tất cả những người tham gia.

3. Cộng tác trong triển khai

Mô hình phát triển nguồn mở nhấn mạnh mạnh mẽ vào sự phát triển cộng tác và rà soát lại ngang hàng, từ ý tưởng đầu tiên cho tới sự chấp nhận cuối cùng. Vì nó có liên quan trong việc hỗ trợ cho các đội được phi tập trung hóa cao độ, nơi mà những người đệ trình không phải tất cả đều được rõ về cá nhân những người duy trì, nên mô hình này có lợi cho những ai làm việc với những người khác về thiết kế và triển khai trong khi vẫn giao tiếp được rõ ràng với các kế hoạch của họ.

Bổ sung thêm, hầu hết các dự án nguồn mở sử dụng các công cụ đã tiến hóa để hỗ trợ đóng góp mã nguồn từ nhiều cộng tác viên phân tán và cùng một lúc. Ví dụ, hệ thống kho git nguồn mở đã được tạo ra đặc biệt để hỗ trợ cho sự phát triển của Linux, nơi mà hàng ngàn người đóng góp đang đệ trình mã nguồn cho bất kỳ phát hành nào được đưa ra. Mỗi lập trình viên làm việc để phát triển, dò tìm lỗi, xây dựng, và kiểm tra tính hợp lệ mã nguồn của riêng họ so với cơ sở mã nguồn hiện hành, sao cho khi tới thời gian để tích hợp vào dự án dòng chính, thì những thay đổi của họ áp dụng rõ ràng được và với một số nỗ lực hòa trộn tối thiểu. Nếu có một vấn đề chưa được thấy trước với mã nguồn, thì bất kỳ sự đề xuất cá nhân nào cũng có thể dễ dàng được đưa trở về tình trạng cũ trước đó.

4. Đệ trình mã nguồn

Vòng đời của một đệ trình mã nguồn mới, được minh họa trong Hình 4, thường hay là lặp đi lặp lại.

Qui trình này bắt đầu với sự phát triển cộng tác trong một tập hợp phụ các lập trình viên, những người đã nắm lấy quyền sở hữu cho việc đưa ra tính năng đó. Khi mã nguồn hoạt động và áp dụng một cách sạch sẽ so với dự án dòng chính, thì đội dự án đệ trình mã nguồn đó cho một người duy trì dự án qua danh sách thư của dự án.

Hình 4: Dòng chảy đặc trưng của mã nguồn từ người đóng góp cá nhân tới phiên bản dòng chính

Người duy trì và những người tham gia khác của dự án có thể đưa ra những ý kiến phản hồi về sự đệ trình và từ chối chấp nhận nó, trong trường hợp đó thì đội triển khai có thể sẽ rà soát lại và đệ trình lại mã nguồn đó.

Vì các bản vá nhỏ hơn là dễ dàng hơn để hiểu và kiểm thử, những người đệ trình thường được khuyến khích đệ trình những thay đổi nhỏ nhất có thể từng tí một. Những bản vá nhỏ hơn ít có khả năng gây ra những hậu quả ngoài ý muốn, và nếu chúng có, thì việc có được lý do gốc rễ của một vấn đề là dễ dàng hơn nhiều.

Khi người duy trì chấp nhận mã nguồn được đệ trình, thì nó sau đó sẽ được tích hợp vào trong cây phát triển của anh hoặc chị ta. Trong một dự án lớn, nhiều lớp, thì người duy trì có thể sau đó sẽ có trách nhiệm cho việc đệ trình nó cho những người duy trì bổ sung tiếp theo lên trên cây. Khi mã nguồn đã được người duy trì cao nhất phê chuẩn, thì nó sẽ được tích hợp cho sự phân phối trong phát hành dòng chính.

5. Kiểm thử và tích hợp liên tục

Vì công việc có thể là phân tán cao độ, mô hình phát triển nguồn mở đặt sự nhấn mạnh vào việc dò tìm ra các vấn đề sớm và sửa chúng nhanh chóng. Nhiều dự án lớn hơn tạo ra những bản xây dựng theo qua đêm và theo tuần có sử dụng một bộ xây dựng tự động, đánh giá mã nguồn sớm nhất có thể sau khi tích hợp.

Bổ sung thêm vào các bộ xây dựng tự động, một số dự án cũng tạo ra các bộ kiểm thử tùy biến để dò tìm ra các vấn đề về chức năng khi chúng xảy ra trong quá trình phát triển tích cực. Những bộ kiểm thử này thường cũng là nguồn mở nốt.

Mô hình phát triển nguồn mở có lợi cho những thay đổi nhỏ, từng tí một, mà có thể làm cho việc chuẩn đoán các vấn đề xây dựng, các lỗi, các lỗ hổng an ninh, và những hồi qui giật lùi dễ dàng hơn nhiều. Điều này đảm bảo rằng mã nguồn mở không ảnh hưởng tới sự tập trung tổng thể của dự án vào mã nguồn an ninh và chất lượng cao.

6. Phát hành mã nguồn

Với một ít ngoại lệ, các dự án sử dụng mô hình nguồn mở tạo nên hình ảnh chụp nhanh ổn định của phát hành mới nhất và cây phát triển sẵn sàng hiện hành. Điều này giúp đảm bảo rằng những người sử dụng có thể tìm kiếm để sử dụng được phát hành ổn định gần nhất, trong khi các lập trình viên có thể làm việc từ mã nguồn hiện hành nhất.

Những thực tiễn quản lý phát hành là khác nhau từ dự án này sang dự án khác, nhưng hầu hết đều đề cử một cá nhân hoặc đội để đánh giá độ chín của các tính năng trong cây phát triển, và giám sát các đo đếm về đảm bảo chất lượng (QA). Khi các tiêu chí của phát hành đạt được, thì đội này sẽ công bố phát hành đó là hoàn thành và phân nhánh cho cây phát triển.

B. NHỮNG ĐẶC TÍNH CỦA MÔ HÌNH PHÁT TRIỂN

1. Chu kỳ phát triển đan xen

Mô hình phát triển nguồn mở được đặc trưng bằng một loạt các qui trình đan xen, chúng liên tục cải thiện chất lượng của mã nguồn, thay vì một sự tiến bộ chính xác tuyến tính tới một phát hành. Không giống như “sự khám phá to lớn” thường đi kèm với mô hình phát triển phần mềm truyền thống, mô hình nguồn mở khuyến khích sự phát triển các tính năng liên tục và độc lập. Điều này cho phép những tính năng mới được tích hợp khi chúng sẵn sàng, mà tới lượt nó cho phép những lập trình viên khác xây dựng được trên chúng nhanh hơn và sản sinh ra một sản phẩm cạnh tranh hơn.

2. Phát hành sớm và thường xuyên

“Phát hành sớm và thường xuyên” tham chiếu tới thực tế phát triển của việc xuất bản mã nguồn alpha cho cộng đồng phát triển để rà soát lại tốt trước phát hành cuối cùng. Điều này làm cho sự phát triển lặp đi lặp lại cao độ, và giảm tối thiểu số thay đổi giữa các phát hành trong sự phát triển, làm cho những sự thoái lui và những chỗ đứt đoạn dễ dàng hơn để chuẩn đoán.

Triết lý phát hành này cho phép sự rà soát lại ngang hàng liên tục, nơi mà tất cả các thành viên của cộng đồng có cơ hội bình luận và đưa ra những gợi ý và các sửa lỗi. Nó cũng khuyến khích những thay đổi nhỏ, từng tí một, chúng là dễ dàng hơn để hiểu và kiểm thử trong khi các lập trình viên tham gia tích cực vào, hơn là được phát hiện ra trong một chu kỳ kiểm thử cuối cùng riêng biệt.

Một lợi ích phụ là việc mã nguồn thường xuyên được rà soát lại về sự tôn trọng kiểu lập trình và mã nguồn dễ vỡ hoặc không mềm dẻo có thể được thấy và được cải thiện sớm trong chu kỳ phát triển.

3. Rà soát ngang hàng

Qui trình phát triển nguồn mở nhấn mạnh sự rà soát lại ngang hàng xuyên qua khắp toàn bộ vòng đời phát triển. Các lập trình viên được mong đợi sẽ đệ trình mã nguồn của họ tới các danh sách thư của dự án cho việc rà soát lại ngang hàng công khai theo chu kỳ, đặc biệt khi một chức năng đạt được một cột mốc phát triển. Điều này giúp đảm bảo rằng những người khác bên ngoài đội phát triển nhận thức được về những thay đổi, và có thể đưa ra những ý kiến phản hồi trước khi thiết kế là cuối cùng và sự triển khai hoàn tất. Những thành viên khác của dự án nguồn mở rà soát lại mã nguồn, đưa ra các bình luận và ý kiến phản hồi để cải thiện chất lượng và chức năng, và kiểm thử để bắt các lỗi và đưa ra những cải tiến sớm nhất có thể trong chu kỳ phát triển.

Khi một tính năng hoàn tất và sẵn sàng để được xem xét cho sự tích hợp, thì ngươi duy trì của dự án cũng đưa ra một mức rà soát lại trước khi chấp nhận mã nguồn đó. Vào lúc mã nguồn được tích hợp vào sản phẩm chính, thì nó đã trải qua một số sự kiểm tra chi tiết của những người khác bên ngoài đội phát triển. Kết quả được cải thiện, mã nguồn có chất lượng cao hơn.

C. LỜI KẾT

Cùng với bài “Tìm hiểu mô hình phát triển phần mềm tự do nguồn mở”, chúng ta đã thảo luận về những yếu tố chính của vòng đời phát triển nguồn mở, và đã mô tả những đặc tính đặc trưng của phát triển nguồn mở. Mô hình phát triển nguồn mở đã được chứng minh là rất thành công, với hàng trăm câu chuyện thành công. Mô hình phát triển này có những đặc tính đặc biệt cho phép sự phát triển nhanh hơn của những đội phân tán một cách rộng khắp, sự kiểm thử liên tục và tỉ mỉ, đổi mới sáng tạo nhanh hơn, nhiều lớp rà soát lại ngang hàng, và toàn bộ tính mở và sự minh bạch xuyên suốt cả dự án.

Để có khả năng áp dụng được mô hình phát triển nguồn mở vào trong các doanh nghiệp phần mềm của Việt Nam trong tương lai, khi mà hầu hết những doanh nghiệp đó là vừa và nhỏ, tiềm lực rất hạn chế về cả nhân lực và vật lực, chưa quen với mô hình này, thì phải biết đứng trên vai của những người khổng lồ để phát triển mà để làm được điều này, các công ty phần mềm của Việt Nam rất nên làm việc với các dự án nguồn mở đã và đang có sẵn trên thế giới. Trong trường hợp này, một yếu tố quan trọng khác mà các doanh nghiệp phần mềm cần phải nắm vững và triển khai trong thực tiễn khi phát triển phần mềm là: ngược lên dòng trên. Ngược lên dòng trên là gì và tại sao lại phải ngược lên dòng trên là những nội dung chúng ta sẽ đề cập tới ở các bài tiếp sau của loạt bài này.

Thiết lập quyền sở hữu Vì những đề xuất mã nguồn có thể tới từ bất kỳ ai, hầu hết các dự án có các thủ tục chính thức hiện diện để theo dõi quyền sở hữu mã nguồn khi một bản vá được đệ trình. Dòng “Được ký bởi” đưa ra tên thực và thư điện tử của người có trách nhiệm đối với mã nguồn. Đây cũng là một thỏa thuận cho Chứng chỉ Gốc của Lập trình viên, nó đòi hỏi rằng người đệ trình có các quyền đóng góp mã nguồn. Ít nhất một dòng được-ký-bởi thường được yêu cầu, khi mà nó cho phép những người khác nhanh chóng xác định được ai đã đệ trình mã nguồn nếu bất kỳ lúc nào có một câu hỏi về gốc gác, giấy phép hoặc sự duy trì. Theo cách tương tự, một số dự án cũng theo dõi những người rà soát lại. Dòng “Được tiến hành bởi” chỉ ra khi ai đó không phải là tác giả hoặc người duy trì đã đưa ra sự rà soát lại tỉ mỉ và tin tưởng nó sẵn sàng để tích hợp.

Trần Lê

Bài đăng trên tạp chí Tin học & Đời sống, số tháng 04/2012, trang 62-65.