Prototypes and Post-it Notes

Mở đầu

Mấy bạn ơi, mình lại tiếp tục series đọc sách "The Pragmatic Programmer" rồi nè. Lần này mình vừa đọc xong Topic 13 trong Chương 2 – A Pragmatic Approach, và phải nói là cái topic này làm mình suy nghĩ lại rất nhiều về cách mình vẫn thường làm việc mấy năm qua. Chuyện là về prototype – tưởng chỉ dành cho code, ai ngờ còn dùng được cả Post-it Notes nữa chứ!

Trong sách, tác giả nói một câu mà mình thấy tâm đắc: "Prototype là để học hỏi, không phải để dùng lại".

Nghe đơn giản vậy thôi, nhưng mà mấy năm đi làm mình thấy không ít lần cả mình và đồng nghiệp rơi vào cái bẫy: làm prototype xong thấy "cũng ổn ổn" rồi đem nó thành production luôn. Kết quả? Bảo trì như địa ngục, code như mớ bòng bong, và mỗi lần thêm tính năng là mỗi lần khóc thầm.

Prototype khác gì Production?

Điểm mấu chốt mà cuốn sách nhấn mạnh: Prototype được viết ra để trả lời câu hỏi, không phải để đưa vào sử dụng thật. Nó giống như vẽ nháp trên giấy trước khi vẽ tranh sơn dầu vậy — không ai đi đóng khung tờ giấy nháp đem treo tường bao giờ.

Prototype có những đặc điểm mà production code không nên có:

Bỏ qua tính đúng đắn (correctness) — Miễn là nó chạy được để trả lời câu hỏi, không cần xử lý hết mọi edge case
Bỏ qua độ tin cậy (reliability) — Crash cũng được, miễn là trong quá trình chạy nó cho mình insight cần
Bỏ qua phong cách code (style) — Không cần convention, không cần clean code
Bỏ qua documentation — Comment cũng không cần, miễn là mình hiểu
Không quan tâm hiệu năng lâu dài — Chạy được trên máy mình là được

Còn production code thì ngược lại hoàn toàn: phải đúng, phải tin cậy, phải maintain được, phải document rõ ràng, và phải scale được.

Khi nào nên làm Prototype?

Theo sách, prototype giúp mình trả lời các câu hỏi rủi ro trước khi quyết định kiến trúc. Cụ thể:

Bạn làm prototype khi:

Cần kiểm chứng architecture có khả thi không
Cần show cho khách hàng/sếp thấy cái nhìn cụ thể về sản phẩm
Cần thăm dò performance của một công nghệ mới
Cần tìm hiểu xem một thư viện/API có đáp ứng nhu cầu không
Cần làm rõ requirement mà nói mãi không thông

Bạn KHÔNG làm prototype khi:

Bạn biết tỏng đáp án rồi — làm prototype lúc này là lãng phí thời gian
Bạn cần code để đưa vào production — lúc này hãy làm thật luôn
Bạn không biết mình muốn học hỏi điều gì từ prototype

Post-it Notes — Cái mới mẻ làm mình bất ngờ

Cái làm mình ấn tượng nhất trong topic này là tác giả nói về việc dùng Post-it Notes làm prototype cho UI/UX.

Nghe thì đơn giản, nhưng mà thử nghĩ xem: bạn cần thiết kế một màn hình phức tạp với các luồng tương tác chằng chịt. Thay vì ngồi Figma cả tuần rồi mới show cho khách, sao không lấy Post-it Notes dán lên bảng trắng, mỗi cái note là một màn hình, và dùng tay để "click" bằng cách di chuyển qua lại giữa các note?

Lợi ích mình thấy:

Siêu nhanh — 1-2 tiếng là có cái để bàn
Không sợ ai đó "vô tình" giữ code prototype làm production — Post-it Notes làm sao mà deploy?
Dễ thay đổi — Muốn thêm màn hình? Dán thêm một cái note. Xóa? Bỏ cái note đó đi
Mọi người đều tham gia được — Không cần biết code, BA, PO, khách hàng đều có thể góp ý
Tập trung vào luồng (flow) thay vì màu sắc, font chữ — Ép mọi người phải nghĩ về UX logic thay vì cãi nhau về cái nút màu xanh hay đỏ

Mình áp dụng thử cách này trong một dự án gần đây và thấy hiệu quả bất ngờ. Team bàn luận sôi nổi hơn hẳn so với mấy buổi "cùng nhau nhìn màn hình Figma".

Mấy lưu ý khi làm Prototype

Từ những gì đọc được và rút kinh nghiệm xương máu, mình tổng kết mấy cái cần nhớ:

Phải setting expectation từ đầu — Nói rõ với mọi người "đây là prototype, code này sẽ bỏ đi". Đừng để ai đó nhìn vào khen "ốm ngon" rồi đem lên production.
Prototype không phải là mã nguồn mẫu — Code prototype thường rất bẩn. Đừng dùng nó làm chuẩn mực cho production code. Mình từng thấy một team giữ nguyên database migration của prototype lên production — chuyện gì xảy ra tiếp theo thì mấy bạn cũng đoán được.
Khi đã trả lời xong câu hỏi thì bỏ đi — Prototype hoàn thành sứ mệnh rồi thì vứt đi, không tiếc. Clean code từ đầu khi đã rõ requirement luôn tiết kiệm hơn là vừa chữa vừa vá code prototype.
Không prototype những gì bạn đã biết rõ — Nếu đã làm 10 cái CRUD API rồi, đừng làm cái thứ 11 dưới dạng prototype. Những cái quen thuộc thì làm production luôn cho nhanh.

Kết luận

Topic 13 này remind mình một bài học quan trọng: biết khi nào nên làm prototype, khi nào nên làm thật, và quan trọng nhất là biết vứt bỏ prototype đúng lúc.

Cái hay của cuốn sách là không chỉ dừng lại ở code, mà còn mở rộng ra các công cụ vật lý như Post-it Notes, giúp mình thấy prototype không phải lúc nào cũng cần viết code. Đôi khi chỉ cần giấy bút và một cái bảng trắng là đã có thể học hỏi được rất nhiều.

Hẹn mấy bạn ở bài sau nha!