Chuyển giao diện cũ sang hệ mới mà không phải làm lại từ đầu
Cách tiếp cận đúng không phải đập đi xây lại, mà thay thế dần từng phần trong khi sản phẩm vẫn chạy.
Anh Chị không cần dừng sản phẩm hay bỏ hết mã nguồn cũ. Cách đúng là giữ giao diện cũ chạy, chuyển dần từng phần sang hệ mới theo lối thay thế tăng dần, bắt đầu từ token rồi đến component. Chỉ khi một phần đã ổn định trong hệ mới thì mới tắt phần cũ tương ứng đi.
- sản phẩm đang chạy thật, không được dừng, mã nguồn lớn
- ưu tiên token và một màn hình điểm mẫu trước khi cam kết nhân rộng
- đập đi làm lại một lần (big bang) khi sản phẩm lớn đang chạy
Câu hỏi Sinh Vũ nghe nhiều nhất khi khách bắt đầu xây design system (hệ thống thiết kế): "Giao diện cũ còn hàng trăm màn hình, chẳng lẽ phải làm lại hết?" Không phải. Làm lại toàn bộ một lần là cách tốn kém nhất và rủi ro nhất. Có một lối đi khác, đã được kiểm chứng trong thực hành, gọi là thay thế tăng dần.
Tại sao không nên đập làm lại một lần
Kiểu tiếp cận đập đi làm lại (thường gọi là "big bang rewrite", tức viết lại toàn bộ cùng lúc) tạo ra một nhánh mã nguồn song song kéo dài hàng tháng. Trong thời gian đó, sản phẩm thật vẫn phải chạy và nhận yêu cầu chỉnh sửa. Kết quả là hai nhánh ngày càng lệch nhau, đội ngũ kiệt sức vá hai nơi cùng lúc, và ngày ra mắt hệ mới cứ lùi mãi.
Nguy hiểm hơn: một lỗi thiết kế hoặc kỹ thuật phát hiện muộn sẽ lan khắp toàn bộ giao diện đã làm mới, không có đường lùi đơn giản.
Lối đi đúng: thay thế tăng dần
Nguyên tắc nền là Strangler Fig Pattern (kiểu thay thế dần, đặt theo hình ảnh cây bóp nghẹt mọc xung quanh cây cũ rồi thay thế từ từ), được Microsoft Azure Architecture Center ghi nhận như một trong những cách chuyển hệ thống đang chạy an toàn nhất. Áp dụng vào design system, lộ trình gồm ba giai đoạn:
- Giai đoạn 1, rà soát và chuẩn hóa token: Kiểm kê toàn bộ giao diện hiện có, tìm ra các giá trị màu sắc, cỡ chữ, khoảng cách đang dùng lẻ tẻ, rồi đặt tên và gom lại thành token. Đây là nền tảng, làm chắc ở bước này thì mọi thứ sau nhẹ hơn nhiều.
- Giai đoạn 2, dựng component và tài liệu trên nền token: Xây dần các component (thành phần giao diện) mới dùng token vừa chuẩn hóa, kèm tài liệu hướng dẫn sử dụng cho đội thiết kế và đội kỹ thuật.
- Giai đoạn 3, chuyển sản phẩm điểm mẫu trước, rồi nhân rộng: Chọn một màn hình hoặc một luồng nhỏ, chuyển sang hệ mới hoàn toàn, quan sát vấn đề phát sinh, điều chỉnh, rồi mới nhân rộng ra phần còn lại.
Công cụ hỗ trợ: codemod và cờ tính năng
Khi nhân rộng, việc đổi tên component hoặc thay cấu trúc mã nguồn hàng loạt bằng tay rất dễ sót và mất thời gian. Codemod (công cụ đổi mã tự động, script thay đổi mã theo quy tắc định sẵn) giúp thực hiện việc này nhanh và nhất quán. Atlassian và MUI là hai tổ chức có công bố cách dùng codemod trong quy trình chuyển design system.
Song song đó, feature flag (cờ tính năng, công tắc bật tắt tính năng theo môi trường hoặc nhóm người dùng) cho phép bật hệ mới cho một nhóm nhỏ trước, quan sát kết quả, và tắt lại ngay nếu có vấn đề mà không cần deploy lại. Đây là đường lùi quan trọng khi triển khai trên sản phẩm thật.
Chuyển dần phù hợp khi sản phẩm đang chạy thật, không được dừng, mã nguồn lớn, hoặc có nhiều màn hình cần giữ ổn định. Đập làm lại chỉ hợp lý khi sản phẩm thật sự nhỏ, ít người dùng thật, và đội ngũ sắp thay toàn bộ công nghệ nền cùng lúc. Ngay cả khi đó, kiểm kê giao diện cũ vẫn cần làm trước để không mất thông tin thiết kế quan trọng.
Lỗi thường gặp khi chuyển hệ
- Bỏ qua kiểm kê giao diện cũ: Không biết mình đang có gì thì không biết cần chuyển gì. Kết quả là sót điểm lệch chuẩn, migrate nửa vời, hệ mới và cũ lẫn lộn không rõ ranh giới.
- Nhân rộng trước khi qua điểm mẫu: Một lỗi trong component hoặc token chưa được kiểm tra sẽ nhân lên khắp nơi, và phải sửa lại đồng loạt.
- Thiếu tài liệu và quy trình quản trị (governance): Đội thiết kế và đội kỹ thuật không biết component nào đã chuyển, component nào chưa, dẫn đến dùng lẫn lộn cả hệ cũ lẫn hệ mới mà không có lộ trình thoát.
Góc nhìn của Sinh Vũ
Trong thực hành, phần tốn thời gian nhất không phải là xây component mới mà là giai đoạn kiểm kê và chuẩn hóa token đầu tiên. Đội ngũ thường muốn bỏ qua bước này vì nó ít "nhìn thấy được" so với việc có component mới lấp lánh. Nhưng nếu token không ổn, mọi thứ xây lên đều sẽ phải sửa lại.
Sinh Vũ cũng khuyến nghị xác định rõ ranh giới giữa phần cũ và phần mới ngay từ đầu: tài liệu nào là tài liệu hệ mới, component nào đã chính thức chuyển, component nào vẫn đang trong giai đoạn chuyển tiếp. Không có ranh giới rõ thì sau sáu tháng, Anh Chị sẽ không còn biết mình đang dùng hệ nào nữa.
Giữ hệ cũ chạy trong khi cắt chuyển từng phần. Không đập đi làm lại một lần.
Strangler Fig Pattern, Microsoft Azure Architecture Center
Checklist quyết định
Chủ đề: Chuyển từ giao diện cũ sang design system mới không cần làm lại từ đầu. Cẩm nang Sinh Vũ, sinhvu.com
Bấm chọn từng mục Anh / Chị thấy đúng, rồi bấm in hoặc lưu thành PDF để mang theo.
Nếu Anh / Chị đánh dấu phần lớn ở nhóm dấu hiệu trên, đây là lúc nên trao đổi kỹ hơn. Sinh Vũ có thể cùng Anh / Chị soi lại và đề xuất hướng đi.
Nguồn tham khảo
Microsoft Azure Architecture Center, Strangler Fig Pattern. Atlassian và MUI codemods, tài liệu vận hành thực hành. Quan điểm lộ trình ba giai đoạn: kinh nghiệm thực hành Sinh Vũ.
Câu hỏi thường gặp
Dự án nhỏ, ít người dùng, có nên đập đi làm lại không?
Có thể cân nhắc nếu sản phẩm thật sự nhỏ, ít người dùng, và Anh Chị sắp thay toàn bộ công nghệ nền. Nhưng ngay cả khi đó, hãy kiểm kê giao diện cũ trước để không bỏ sót quyết định thiết kế quan trọng. Với đa số trường hợp, chuyển dần vẫn an toàn hơn vì giữ được lịch sử và giảm rủi ro ra mắt.
Token là gì và tại sao phải chuẩn hóa trước?
Token (biến số thiết kế) là các giá trị nền tảng như màu sắc, cỡ chữ, khoảng cách, được đặt tên và dùng nhất quán thay vì ghi cứng từng nơi. Chuẩn hóa token trước vì mọi component đều dùng chung nền này. Nếu token chưa ổn thì component xây lên cũng sẽ lệch chuẩn, và phải sửa lại nhiều lần.
Codemod là gì, có cần kỹ sư mới dùng được không?
Codemod (công cụ đổi mã tự động) là script thay đổi mã nguồn hàng loạt theo quy tắc định sẵn, ví dụ đổi tên component cũ sang tên mới trên toàn bộ dự án. Dùng codemod cần kỹ sư frontend có kinh nghiệm. Sinh Vũ khuyến nghị Anh Chị làm việc với đội kỹ thuật để đánh giá phạm vi trước khi áp dụng, không chạy thử trực tiếp trên nhánh chính.