Người dùng không quan tâm — nhưng bạn thì phải quan tâm
(lewiscampbell.tech)- Người dùng coi trọng việc sản phẩm hoạt động hơn là các thuộc tính nội tại của chính đoạn mã, nhưng mã kém chất lượng có tác động hạ nguồn trực tiếp đến hiệu năng, lỗi và tốc độ phát triển
- Câu nói “người dùng không quan tâm đến tech stack hay kiểm thử” bề ngoài có vẻ đúng, nhưng chất lượng mã càng thấp thì việc sửa lỗi và bổ sung tính năng càng khó và chậm hơn
- Giống như các phép ví von về việc kiểm định cầu, phi công say rượu hay nền móng tòa nhà không ổn định, dù người dùng không nhìn thấy chính quy trình đó, kết quả của nó vẫn ảnh hưởng đến an toàn và độ tin cậy
- Đằng sau sự phổ biến của kiểu ngộ nhận này có thể là cơ chế tự vệ bản ngã, khi con người có xu hướng hạ thấp giá trị của những gì mình không giỏi
- Công việc phần mềm nghiêm túc là sự pha trộn của nhiều mối quan tâm và góc nhìn khác nhau, và tất cả đều góp phần vào thành bại, nên không được xem nhẹ chất lượng mã
Sáo ngữ lặp đi lặp lại và giới hạn của chúng
- Trong ngành phần mềm, người ta thường lặp lại những câu kiểu như
- “Khách hàng không quan tâm đến kiểm thử, họ chỉ quan tâm sản phẩm có chạy hay không”
- “Người dùng không quan tâm đến tech stack”
- “Sự thanh nhã về kỹ thuật không đồng nghĩa với giá trị thị trường”
- “Người dùng không quan tâm sản phẩm do AI viết hay do con người viết, hoặc dùng framework nào, họ chỉ quan tâm nó có hoạt động hay không”
- Tất cả những câu này đều là các biến thể của cùng một chủ đề: “khách hàng không quan tâm đến điều đó”
- Nó như thể một nhà thực dụng lão luyện đang nói ra sự thật lạnh lùng của thế giới cho những người duy tâm hoặc thiển cận
- Nhưng thực ra, tất cả chỉ là lời nhảm nhí (horseshit), và
nếu áp dụng cùng logic đó sang lĩnh vực khác thì lỗ hổng sẽ lộ ra- Người tham gia giao thông không quan tâm cây cầu đã được kiểm định cuối cùng hay chưa, họ chỉ quan tâm nó có đỡ được xe hay không
- Hành khách không quan tâm phi công có say rượu hay không, họ chỉ quan tâm máy bay có đến đúng giờ hay không
- Nhân viên văn phòng không quan tâm nền móng của tòa nhà cao tầng có ổn định hay không, họ chỉ quan tâm đến việc kiếm tiền
- Những phép ví von này bề ngoài có vẻ đúng, nhưng lại phớt lờ các tác động hạ nguồn (downstream effects) rất rõ ràng
Các tác động hạ nguồn bị bỏ qua
- Đúng là khách hàng không quan tâm đến các thuộc tính nội tại của mã máy tính, nhưng
chất lượng mã ảnh hưởng đến hiệu năng, sự tồn tại của lỗi, thời gian sửa lỗi và thời gian bổ sung tính năng - Mã càng tệ thì việc giải quyết những vấn đề này càng khó và càng chậm
- Những công ty như AirBnB, OpenAI và Meta có thể ép những lo ngại này xuống nhờ sức thống trị thị trường khổng lồ, nguồn vốn VC dồi dào và tính hợp pháp đáng ngờ
nhưng nếu không phải những công ty như vậy thì sẽ khó che lấp vấn đề theo cùng cách đó
Sự dai dẳng của “Folk Wisdom” và nhiều mối quan tâm trong phần mềm
-
Sức sống dai dẳng của ngộ nhận phổ biến (The Persistence of Folk Wisdom)
- Quan điểm cho rằng chỉ hiệu ứng bậc một mới quan trọng đã trở thành một dạng ngộ nhận dân gian rất phổ biến trong phần mềm
- Con người có xu hướng xem nhẹ hoặc thu nhỏ những gì mình làm không tốt
- Khi ai đó nhận thấy mình thiếu khả năng tạo ra mã tốt, họ dễ đi đến quan điểm rằng mã tốt không những không quan trọng mà thậm chí những người có thể viết mã tốt mới là vấn đề
- Từ góc nhìn đó, những người ngăn việc phát hành vì các thứ khách hàng không quan tâm sẽ bị xem như kẻ gây rắc rối
- Thái độ này vận hành như một cơ chế tự vệ bản ngã (ego defence mechanism) nhằm né tránh điểm yếu của bản thân và đổ trách nhiệm sang người khác
-
Chúng ta sống trong một xã hội (We Live in a Society)
- Công việc phần mềm nghiêm túc là sự pha trộn của các mối quan tâm và các góc nhìn khác nhau
- Từ tech sales đến tech stack, từ trải nghiệm người dùng (UX) đến định danh duy nhất (unique identifiers), rất nhiều yếu tố cùng tham gia vào nỗ lực phần mềm
- Tất cả những yếu tố này đều góp phần vào thành công hoặc thất bại
1 bình luận
Ý kiến trên Lobste.rs
Những câu kiểu này có thể vừa tốt vừa không tốt, cả ở cách truyền đạt lẫn cách người đọc tiếp nhận
Ví dụ, câu “Khách hàng hoàn toàn không quan tâm đến việc test. Họ quan tâm sản phẩm có hoạt động hay không” không có nghĩa là “cứ tung bug ra”, mà có thể được hiểu là hãy tập trung vào việc sản phẩm thực sự hoạt động hơn là một hệ tư tưởng về test cụ thể
Vì test chỉ là một trong những phương tiện để làm cho code hoạt động, nên dù test coverage cao và tất cả đều pass mà sản phẩm vẫn không chạy thì vẫn là thất bại; ngược lại, nếu không chỉ dựa vào test mà vẫn làm sản phẩm chạy tốt thì cũng không sao, và dù không theo giáo điều hình thức mà vẫn bắt bug tốt thì cũng ổn
Ngoài ra, từ góc nhìn người dùng và doanh nghiệp, việc “sản phẩm/tính năng không tồn tại” cũng có thể là một bug, nên việc sửa bug hiện có và ra mắt tính năng mới không phải lúc nào cũng tách bạch gọn gàng
Tuy vậy, trên thực tế tôi cũng từng nghe những câu như thế được dùng với nghĩa “làm ẩu rồi tung rác ra thị trường”
Tôi hoàn toàn bác bỏ ý nghĩ rằng lập trình tệ hại vẫn có thể là “thực dụng” ngay cả khi nhìn theo mốc vài tháng
Xây tính năng mới trên một codebase thiết kế tệ và thiếu test là việc chậm và tốn kém
Lập trình viên cần ý thức xem mình có đang dành thời gian vào nơi tạo ra giá trị hay không, và lý tưởng nhất là ban quản lý cũng hiểu vì sao những việc đó đang được làm
Khi thiếu hiểu biết kết hợp với cấu trúc incentive sai lệch thì cuối cùng sẽ dẫn đến kiểu “làm ẩu rồi tung rác ra thị trường”
Thành thật mà nói, nhiều người nói kiểu này lại thường trông như những người cũng chẳng mấy quan tâm đến người dùng
Để người dùng nhận được một sản phẩm hoạt động, trong quy trình phát triển phải có những cơ chế làm tăng khả năng đó; tôi đã nói điều này trong một bình luận vài ngày trước
Kiểu cảm xúc này thường xuất hiện khi người dùng không có cách phản hồi đúng nghĩa về sản phẩm, và cũng không có chỉ số sử dụng thực tế
Có rất nhiều kịch bản thất bại ảnh hưởng đến người dùng dù họ không nhìn thấy hay để tâm ngay lúc đó
Điển hình là bảo mật: người dùng có thể không quan tâm việc “không an toàn” cho đến khi dữ liệu của họ xuất hiện trong các bản rò rỉ trực tuyến; tương tự, hiệu năng cũng có thể không bị xem là vấn đề cho đến khi họ biết nó đáng lẽ có thể tốt hơn nhiều
Dù là quá trình cải thiện nào đi nữa thì cũng khó mà chỉ chọn một yếu tố để tối ưu rồi có được kết quả tốt, nhưng để tạo ra tiến triển trong thảo luận thì nhiều khi lại buộc phải làm vậy
Vì thế, sẽ hữu ích nếu điều chỉnh đường đi của thảo luận theo kênh phản hồi để xác định vấn đề nào đang hiển hiện rõ ràng trước mắt
Tôi xem những bài viết kiểu này là nỗ lực nhằm gợi người đọc nghĩ đến các yếu tố ảnh hưởng đến thành công của một dự án phần mềm nhưng lại có vẻ loại trừ lẫn nhau
Việc diễn đạt và biện hộ bằng lời cho những thứ vốn chỉ người có cảm quan kỹ thuật mới nhận ra là điều có giá trị, nhưng có vẻ nhiều người làm kỹ thuật không giỏi cân bằng hay thuyết phục hiệu quả về công việc vô hình, và bản thân tôi cũng đang tiếp tục luyện phần đó
Việc quan tâm đến bên trong là quan trọng, và trên thực tế cũng mang lại lợi ích cho người dùng
Tôi thích góc nhìn này
Tôi không muốn đi sang cực đối diện là over-engineering, nhưng cũng mong chúng ta thoát khỏi lối nghĩ “move fast and break things”
Theo kinh nghiệm của tôi, trong thế giới phát triển web nó gần như là một bệnh dịch
Tôi hy vọng làn sóng phần mềm chất lượng thấp do LLM tạo điều kiện sẽ ngược lại khiến người dùng biết tưởng thưởng cho phần mềm đáng tin cậy
Tôi đang ngày càng trở thành một lập trình viên kiểu grug brain nên cũng không chắc đây có phải cảm nhận phổ biến không, nhưng tôi đã mệt mỏi với kiểu “thêm một tính năng nữa đi”
Chúng ta thường mắc sai lầm khi chỉ đo chi phí phần mềm bằng ngày phát hành, còn chi phí bảo trì trong suốt vòng đời của nó thì hầu như không tính đến
Người ta nói “không khó đâu, chưa đến một tuần là xong!” nhưng lại không nói về 2~4 tuần mỗi năm sẽ phải dành cho bảo trì, sửa lỗi, mở rộng, cập nhật, tích hợp và viết tài liệu
Tôi cũng hay nói những câu có ý tương tự
“Người dùng cuối không quan tâm phần mềm có 100% test coverage hay được viết 100% bằng assembly không tài liệu với các nhãn như
lbl0. Họ quan tâm đến tính đúng đắn, hiệu năng và trải nghiệm người dùng”Nhưng chính software engineering lại giúp đạt được những mục tiêu đó dễ hơn và giữ chất lượng ở mức tốt
Vấn đề là con đường này cũng có thể dẫn đến cargo cult và over-engineering, và tôi chắc chắn cũng có phần tội trong đó
Dù vậy, rốt cuộc vẫn phải mang lại giá trị thực cho người dùng
Cũng như Boeing và Airbus, có những kết quả tối ưu có thể chứng minh được
Điều cốt lõi không phải là vì sao máy bay của hai công ty trông giống nhau đến vậy, hay ai thiết kế trước và ai ăn cắp của ai
Chẳng ai ăn cắp cả; chỉ là những kỹ sư giỏi nhất thế giới từ các đội khác nhau cùng thiết kế trong cùng một tập ràng buộc, nên những thiết kế lệch khỏi đó theo định nghĩa sẽ kém hơn
Phải nằm trên biên Pareto, nếu không thì sẽ bị đào thải
Trong lĩnh vực của chúng ta cũng tồn tại một điểm tối ưu nào đó; vấn đề là liệu ta có công cụ, ngân sách và đúng người để chạm tới nó hay không, và liệu có đủ người dùng để biết được ta đã thực sự tới đó hay chưa