Số 417Quản lý Phạm vi

PHP 6 (2005–2010): dự án Unicode bị bỏ dở và quyết định nhảy thẳng lên PHP 7

Từ năm 2005, cộng đồng PHP phát triển PHP 6 với hỗ trợ Unicode gốc, lưu chuỗi nội bộ dưới dạng UTF-16. Thiếu người có chuyên môn và vấn đề hiệu năng khiến dự án trì trệ; tháng 3/2010 PHP 6 "ở dạng hiện tại" bị bỏ, các tính năng khác được đưa vào PHP 5.3 và 5.4. Phiên bản lớn tiếp theo được đặt tên PHP 7 (12/2015), tập trung vào hiệu năng. Bài học về gói phạm vi rủi ro cao làm con tin cho cả bản phát hành.

Nguyễn Thu Hà, PMP

20/09/2026

3 phút đọc 0

Bình luận0

Bối cảnh thực tế

PHP là ngôn ngữ lập trình web phổ biến. Năm 2005, một dự án do Andrei Zmievski dẫn dắt bắt đầu đưa Unicode gốc vào PHP bằng cách nhúng thư viện ICU — đây là trọng tâm của PHP 6.

Thiết kế: chuỗi văn bản được lưu nội bộ dạng UTF-16, kéo theo thay đổi lớn ở lõi ngôn ngữ và mã của người dùng.
Thiếu lập trình viên có chuyên môn cần thiết, và việc chuyển đổi UTF-16 gây vấn đề hiệu năng trong môi trường web — nơi UTF-16 hiếm khi được dùng. Dự án bị trễ kéo dài.
PHP 5.3 (2009) đã nhận một số tính năng vốn dự kiến cho 6.0 như namespace và closure.
Tháng 3/2010, dự án "ở dạng hiện tại" chính thức bị bỏ; PHP 5.4 (3/2012) nhận phần lớn tính năng không liên quan Unicode còn lại.
Sau tranh luận trong 2014–2015 và một cuộc bỏ phiếu, phiên bản lớn tiếp theo được đặt tên PHP 7, một phần vì sách báo đã dùng tên "PHP 6". PHP 7.0 phát hành 3/12/2015, xây trên nhánh phpng tập trung tối ưu hiệu năng.

Phân tích nguyên nhân theo chuẩn PMP

Một gói công việc rủi ro cao chặn cả bản phát hành
Gắn mọi tính năng mới vào cùng phiên bản với thay đổi Unicode khiến các tính năng sẵn sàng không thể đến tay người dùng. Phạm vi phát hành nên tách theo mức độ sẵn sàng.
Giả định nguồn lực không được kiểm chứng
Thiết kế đòi hỏi chuyên môn hiếm; khi nguồn lực không có, tiến độ không thể đi tiếp. Lập kế hoạch nguồn lực (Plan Resource Management) phải xác nhận có người làm được trước khi chốt phạm vi.
Yêu cầu phi chức năng (hiệu năng) phát hiện muộn
Chi phí hiệu năng của UTF-16 là rủi ro có thể đo bằng nguyên mẫu sớm. Phát hiện muộn biến nó thành lý do dừng dự án.
Điểm sáng: biết dừng và chuyển phần giá trị ra
Việc đưa tính năng vào 5.3/5.4 và đổi hướng sang hiệu năng ở PHP 7 cho thấy cộng đồng đã cắt lỗ và giữ lại giá trị thay vì cố giữ phạm vi ban đầu.

PHP 6 (2005–2010): dự án Unicode bị bỏ dở và quyết định nhảy thẳng lên PHP 7

Bối cảnh thực tế

Phân tích nguyên nhân theo chuẩn PMP

Một gói công việc rủi ro cao chặn cả bản phát hành

Giả định nguồn lực không được kiểm chứng

Yêu cầu phi chức năng (hiệu năng) phát hiện muộn

Điểm sáng: biết dừng và chuyển phần giá trị ra

Lẽ ra PM nên làm gì

Bước 1: Phát hành theo "tàu" thay vì theo tính năng lớn

Bước 2: Kiểm chứng sớm bằng nguyên mẫu đo hiệu năng

Bước 3: Công bố lại phạm vi khi đổi hướng

PM Takeaway (Bài học rút ra)

Nguồn tham khảo

Trắc nghiệm tình huống PMP

Thay đổi kiến trúc đã trễ 3 năm và thiếu người có chuyên môn. Bạn chọn gì?

Tình huống này hữu ích với bạn?

Bình luận (0)