Trang bấm thử hay tệp tĩnh: chọn theo cách đội dùng
Câu trả lời nằm ở một điểm duy nhất: hệ của Anh / Chị có mã nguồn thành phần giao diện (component) cho lập trình viên dùng hay không.
Nếu hệ có mã nguồn thành phần giao diện cho đội kỹ thuật dùng, tài liệu tương tác kiểu Storybook (trang cho xem và bấm thử từng thành phần như khi chạy thật) gần như bắt buộc. Tệp tĩnh như PDF hay ảnh đủ cho tài liệu hướng dẫn nhận diện dành cho người đọc. Nhưng chúng sẽ lệch với bản đang chạy ngay khi hệ thay đổi. Ranh giới quyết định là có mã nguồn hay không, bất kể quy mô hay ngân sách.
- có mã nguồn component, nhiều đội, người mới vào thường xuyên
- hệ thay đổi thường xuyên, cần tài liệu luôn khớp bản chạy
- chỉ là hướng dẫn nhận diện cho người đọc, không kèm mã nguồn
- ít thay đổi, tệp tĩnh đủ dùng
Câu hỏi về Storybook thường bị hỏi nhầm hướng. Nhiều chủ doanh nghiệp hỏi "có nên dùng Storybook không" như thể đây là câu hỏi về công cụ hay ngân sách. Thực ra đây là câu hỏi về bản chất tài liệu: tài liệu đó dùng cho ai và cái gì đang thay đổi bên dưới nó.
Ranh giới quyết định: có mã nguồn hay không
Có thể chia tài liệu của một hệ thiết kế thành hai loại theo đối tượng nhận.
Loại thứ nhất là tài liệu cho con người đọc: hướng dẫn nhận diện thương hiệu, bộ quy tắc về màu sắc, kiểu chữ và bố cục, thường ở dạng PDF hoặc tệp Figma (phần mềm thiết kế giao diện) chia sẻ. Người nhận là quản lý thương hiệu, đối tác in ấn, đơn vị thứ ba. Ở đây không ai cần làm việc với mã nguồn.
Loại thứ hai là tài liệu cho máy đọc được: bộ thành phần giao diện viết bằng mã nguồn và token thiết kế (các giá trị như màu, cỡ chữ, khoảng cách được đặt tên và lưu thành biến số), dành cho lập trình viên đưa vào sản phẩm. Người nhận cần biết thành phần ấy trông và hoạt động ra sao trong trình duyệt, không chỉ trong ảnh chụp màn hình.
Khi hệ thuộc loại thứ hai, tài liệu tĩnh không đủ, vì tệp tĩnh chỉ chụp lại một thời điểm, còn mã nguồn tiếp tục chạy và thay đổi sau đó.
Storybook làm được gì mà tệp tĩnh không làm được
Storybook là một trình khám phá component (công cụ cho phép lập trình viên xây dựng, xem và thử từng component tách biệt khỏi ứng dụng chính). Điểm cốt lõi là nó chạy component thật, trong môi trường trình duyệt thật, không phải mô phỏng hay ảnh.
Nhờ vậy, lập trình viên thấy thành phần chạy thế nào ngay trong trình duyệt, không phải đoán qua ảnh chụp.
Storybook, Why Storybook
Điều này có nghĩa thực tế: khi lập trình viên cập nhật một component, Storybook phản ánh thay đổi đó ngay. Tệp PDF vẫn hiện bản cũ cho đến khi ai đó nhớ vào cập nhật thủ công, thường là không ai nhớ.
Khi nào chọn hướng nào
Chọn tài liệu tương tác (Storybook hoặc tương đương) khi hệ có mã nguồn thành phần giao diện cho đội kỹ thuật. Cũng nên chọn khi thành phần nhiều và thay đổi thường xuyên. Cũng nên chọn khi nhiều đội hoặc người mới vào liên tục cần làm quen hệ thống (onboarding). Và khi Anh / Chị muốn bớt thời gian tra cứu, tránh để bản thiết kế lệch với bản chạy.
Tệp tĩnh là đủ khi tài liệu chỉ dành cho người đọc, không kèm mã nguồn. Cũng đủ khi hệ ít thành phần và rất ít thay đổi. Cũng đủ khi không có đội kỹ thuật nội bộ nhận mã nguồn.
Lỗi thường gặp khi chọn sai định dạng
- Viết tài liệu PDF cho một hệ có mã nguồn. Vài tháng sau PDF lệch hẳn với bản đang chạy, lập trình viên dừng đọc tài liệu vì không tin nó còn đúng.
- Dựng Storybook nhưng không gắn vào quy trình cập nhật. Kết quả là tài liệu tương tác nhưng chết, còn tệ hơn PDF vì tạo ảo giác đang được duy trì.
- Dùng Storybook cho một bộ hướng dẫn nhận diện không kèm mã nguồn. Khoản đầu tư này không có chỗ dùng.
Cách cân cho tình huống của Anh / Chị
Figma Code Connect (tính năng của Figma, nối thành phần trong bản thiết kế với đoạn mã đang chạy) giúp người thiết kế nhìn vào một thành phần là thấy đúng mã tương ứng, không phải đoạn mã ai đó gõ tay vào tài liệu rồi quên cập nhật. Cách này giúp bản vẽ và bản chạy không lệch nhau.
Nếu Anh / Chị chỉ cần hướng dẫn nhận diện cho đối tác in ấn và truyền thông, tệp tĩnh hoàn toàn hợp lý. Nếu sắp tới có đội kỹ thuật nhận component để xây sản phẩm số, nên tính Storybook ngay từ đầu, đừng để hệ chạy rồi mới quay lại viết tài liệu cho nó.
Bảng kiểm quyết định
Chủ đề: Tài liệu thư viện giao diện: trang bấm thử được hay tệp tĩnh là đủ. Cẩm nang Sinh Vũ, sinhvu.com
Bấm chọn từng mục Anh / Chị thấy đúng hoặc đã trả lời được, rồi bấm Tải bản gửi nhanh để gửi đi, hoặc bấm In nếu cần bản giấy.
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
Storybook, Why Storybook. Brad Frost, Atomic Design (phần công cụ và tài liệu sống). Kinh nghiệm thực hành của Sinh Vũ khi bàn giao A3 kèm Storybook và Figma Code Connect.
Câu hỏi thường gặp
Chúng tôi chỉ có một lập trình viên, có cần Storybook không?
Số người không phải yếu tố chính. Yếu tố chính là hệ có mã nguồn thành phần hay không và tần suất thay đổi. Nếu hệ có mã nguồn và thành phần thay đổi thường xuyên, thì dù chỉ có một lập trình viên, Storybook vẫn giúp bớt công tra cứu và sớm phát hiện chỗ lệch. Nếu hệ chỉ là hướng dẫn màu sắc và kiểu chữ cho người đọc, tệp tĩnh là đủ.
Dựng Storybook có tốn công duy trì không?
Có, và đây là rủi ro thật sự. Storybook dựng sai quy trình, không gắn vào quy trình đưa sản phẩm lên chạy (pipeline triển khai), sẽ thành tài liệu chết nhanh hơn PDF. Điều kiện để Storybook sống là mỗi lần cập nhật thành phần đều kèm cập nhật trang mô tả tương ứng (gọi là story), lý tưởng nhất là tự động hoá trong quy trình kiểm thử.
Figma đã có bản dựng thử (prototype) rồi, Storybook còn cần không?
Prototype trong Figma mô phỏng giao diện theo ý định của người thiết kế. Storybook chạy thành phần thật trong trình duyệt thật. Hai công cụ phục vụ hai đối tượng khác nhau: Figma cho người thiết kế và các bên liên quan xem luồng thao tác, Storybook cho lập trình viên kiểm tra và lấy mã. Nếu dùng Figma Code Connect, hai bên còn được nối với nhau từng thành phần một, nên bản vẽ và bản chạy ít lệch nhau hơn.
Bài viết là thông tin tham khảo. Phạm vi, giá và cam kết cụ thể của Sinh Vũ ghi trong hồ sơ đề xuất và hợp đồng đã ký.