Đánh phiên bản và xử lý breaking change ra sao

Thay đổi phá vỡ, hay breaking change (thay đổi làm hỏng cách dùng cũ), là phần không thể tránh trong vòng đời của bất kỳ design system nào đang trưởng thành. Vấn đề không phải là có nên thay đổi hay không, mà là thay đổi như thế nào để các đội đang dùng hệ thống không bị bất ngờ và có đủ thời gian chuyển đổi.

Chuẩn nền: đặt phiên bản theo ngữ nghĩa

Chuẩn được dùng rộng rãi nhất là SemVer, tức Semantic Versioning (đặt phiên bản theo ngữ nghĩa), với ký hiệu MAJOR.MINOR.PATCH. Ba con số này không phải trang trí, mỗi con số truyền đạt một cam kết với người dùng hệ thống.

• MAJOR: tăng khi có thay đổi phá vỡ, tức người dùng phải điều chỉnh code hoặc thiết kế của họ để tiếp tục dùng được.
• MINOR: tăng khi thêm tính năng mới nhưng tương thích ngược, tức không làm hỏng cái đang chạy.
• PATCH: chỉ dùng cho sửa lỗi không thay đổi hành vi hoặc giao diện.

Ý nghĩa thực tế của quy ước này là: khi đội khác thấy số lớn nhảy lên, họ biết ngay rằng cần đọc nhật ký thay đổi (changelog) và kiểm tra lại trước khi nâng cấp. Nếu chỉ thấy số giữa hay số cuối tăng, họ có thể nâng cấp tự tin hơn.

Phá vỡ thị giác: loại hay bị bỏ qua

Phá vỡ giao diện lập trình (API breaking change) thì tương đối dễ nhận ra vì code sẽ báo lỗi. Nguy hiểm hơn là phá vỡ thị giác (visual breaking change): đổi giá trị token màu, khoảng cách, hay cỡ chữ làm cho giao diện của đội khác lệch so với thiết kế gốc, dù không có dòng code nào báo lỗi.

Một thay đổi là breaking change nếu nó làm bất cứ điều gì người dùng đang dựa vào hoạt động khác đi, kể cả khi giao diện lập trình không thay đổi.

Nathan Curtis, Visual Breaking Change in Design Systems, EightShapes

Trước mỗi lần thay đổi token hoặc style dùng chung, Anh / Chị cần hỏi: liệu thay đổi này có làm bất kỳ màn hình nào của đội khác trông khác đi không? Nếu có, đó là phá vỡ thị giác và phải được đánh số MAJOR, không phải PATCH.

Cửa sổ ngừng dùng: quy trình không thể bỏ

Ngừng dùng, hay deprecation (thông báo một tính năng sẽ bị gỡ trong tương lai), cần có hai yếu tố: thông báo rõ ràng và thời gian đủ dài để các đội chuyển đổi. Gỡ đột ngột mà không báo trước là nguyên nhân phổ biến nhất khiến các đội mất tin tưởng vào design system.

Tốt nhất là cho cái mới sống cạnh cái cũ một thời gian trước khi chính thức lên bản lớn. Morningstar từng giữ song song bản component cũ và mới sáu tháng trước khi ra phiên bản 2.0.0, để các đội có đường lui nếu cần.

Đánh phiên chung hay theo từng component

Đây là quyết định cần chốt sớm trong giai đoạn dựng quản trị.

• Đánh phiên chung cho cả thư viện: một số duy nhất đại diện toàn bộ hệ thống. Dễ điều phối khi cần các đội nâng cấp đồng loạt. Nhược điểm là nếu chỉ có một component thay đổi, toàn bộ thư viện vẫn phải tăng số lớn.
• Đánh phiên riêng theo component: mỗi component có số phiên độc lập. Các đội biết chính xác component nào có phá vỡ và có thể nâng cấp chọn lọc. Nhược điểm là phức tạp hơn để theo dõi và điều phối.

Chọn hướng nào tùy vào cách các đội thực sự làm việc với nhau, không phải tùy vào lý thuyết nào nghe hay hơn.

Lỗi thường gặp khi quản trị phiên bản

• Đổi token màu hay khoảng cách rồi đánh số PATCH vì giao diện lập trình không đổi, bỏ qua phá vỡ thị giác.
• Gỡ component cũ không báo trước, các đội đang dùng vỡ hàng loạt.
• Không có nhật ký thay đổi, đội khác không biết bản mới đổi gì và có cần điều chỉnh không.
• Nhồi nhiều thay đổi phá vỡ vào một bản MINOR để tránh phải lên số MAJOR, dẫn đến bản MINOR gây bất ngờ cho người dùng.
• Gom các thay đổi phá vỡ rải rác ở nhiều bản nhỏ thay vì gom lại và kích một bản MAJOR có lộ trình rõ.

Góc nhìn của Sinh Vũ

Trong quy trình A3 của Sinh Vũ, đánh phiên bản và nhật ký thay đổi đi kèm với token theo chuẩn trung lập DTCG JSON (Design Token Community Group, định dạng token dùng chung giữa các công cụ). Cấu trúc này có nghĩa là một thay đổi ở tầng token có thể lan ra toàn bộ hệ thống nếu thiếu kỷ luật phiên bản, đây chính là nơi phá vỡ thị giác xảy ra nhiều nhất và ít ai ngờ nhất.

Sinh Vũ đặt cửa sổ ngừng dùng và quy trình duyệt để mỗi thay đổi phá vỡ đều được báo trước và có đường lui. Nhịp phát hành cụ thể và độ dài cửa sổ nên được chốt trong lúc dựng quản trị ban đầu, vì con số đúng phụ thuộc vào số đội dùng chung và mức độ gần gũi giữa họ, không có con số mặc định áp dụng cho mọi tổ chức.