Suy Tư Hoang Tưởng
Hai tuần vừa qua trôi qua trong hỗn loạn, chủ yếu là do tôi vừa chuyển từ phần code sang viết kịch bản game. Không viết code nhiều khiến tâm hồn trống trải, bởi viết kịch bản toàn là công việc văn bản. Ý tưởng trong đầu tưởng rõ ràng, nhưng khi viết ra lại thành chuyện khác. Nhiều chi tiết vẫn còn mơ hồ vì chưa suy nghĩ thấu đáo, dẫn đến diễn đạt không rõ ràng. Vẫn còn nhiều việc phải làm lắm.
Hôm nay có độc giả blog nhắn qua GTalk nhắc nhở tôi cập nhật thường xuyên, đừng lười biếng vì còn nhiều người đang theo dõi. Thực ra từ đầu tôi đã không viết blog vì người khác, mà chỉ ghi lại những gì mình suy nghĩ. Dù có người đọc hay không, tôi vẫn viết theo nhịp sống của mình như những bản ghi chép cá nhân.
Bài viết hôm nay không hoàn toàn vì có người đẹp động viên. Thực ra buổi chiều rảnh rỗi tôi đã muốn viết gì đó, nhưng vừa chạm vào bàn phím lại thấy ý tưởng chưa rõ ràng. Trong giao diện quản lý blog đã có vài bản nháp như vậy, viết xong rồi cất đó mà chưa công bố. Nếu không phải vì sinh tồn, cuộc sống hẳn sẽ đầy ắp những suy nghĩ lung tung. Những năm qua tôi vẫn sống như vậy, thỉnh thoảng hiểu ra điều gì đó thì ghi lại, còn đa phần ý tưởng đến nhanh đi nhanh.
Ban đầu tôi định viết về kỹ thuật, đại khái có hai điểm chính.
Điểm thứ nhất liên quan đồng bộ thời gian mạng, vấn đề này đã giày vò tôi nhiều năm (năm ngoái từng viết một bài, nhưng vấn đề liên quan đến dự án của chúng tôi còn phức tạp hơn). Tất nhiên tôi không cần ai giải đáp ở đây, nếu bạn đọc xong muốn thảo luận về giao thức NTP hay chi tiết kỹ thuật, tôi xin từ chối. Đây không phải vấn đề phức tạp không giải được, mà là muốn mở rộng một vấn đề liên quan:
Hầu hết mô hình phần mềm hiện nay không tính đến yếu tố thời gian, chỉ quan tâm input và output. Các ngôn ngữ lập trình cũng vậy, thiết kế chỉ chú trọng hiệu suất thời gian chạy, không định nghĩa rõ ràng thời gian thực thi đoạn code. Dĩ nhiên thời gian tuyệt đối không thể định nghĩa vì sẽ thay đổi theo phần cứng, nhưng thời gian tương đối lý thuyết có thể xác định được, nhưng cuối cùng lại bị bỏ qua. Khi nghiên cứu thuật toán, ta chỉ bàn về độ phức tạp thời gian. Điều này liên quan đến mô hình máy tính hiện tại, trong đó thời gian thực thi chính xác của đoạn code là không thể đo đạc chính xác.
Đáng tiếc nhiều phần mềm phải tính đến yếu tố thời gian. Dù bỏ qua các hệ thống công nghiệp như nhà máy điện hạt nhân, nơi thời gian ảnh hưởng trực tiếp đến tính mạng con người, hãy nói về game - hệ thống tương tác thời gian thực. Khi có con người tham gia, chỉ cho ra kết quả đúng là chưa đủ, mà còn phải đảm bảo kết quả đúng cả về mặt giá trị lẫn thời điểm xuất hiện, mới gọi là chức năng game hoạt động đúng.
Bởi vì trong game tương tác, cảm nhận của con người mới là quan trọng nhất.
Vài hôm nay tôi đang đọc lại cuốn sách phổ thông “Dây đàn vũ trụ” xuất bản từ lâu. Cuốn này tôi mua ở Bắc Kinh năm 2002, bìa đen. Lúc đó đặc biệt muốn đọc nhưng Vũ Hán không tìm được, nhân dịp đi Bắc Kinh chơi, một người bạn net cùng tôi đi dạo phố sách Hải Điện, tìm mấy tiệm mới mua được. Đọc xong chưa đầy tuần đã bị bạn mượn mất.
Vài hôm trước lại ở Bắc Kinh, đi dạo phố sách cùng em họ, thấy cuốn này tái bản nên mua ngay. Thời gian trôi nhanh thật, thoáng đã năm năm rồi. Thở dài, sách muốn đọc lại tốt nhất đừng cho ai mượn.
Lúc rảnh rỗi đọc lại vài trang, phần đầu dành nhiều trang giải thích thuyết tương đối. Khác với “Ý nghĩa thuyết tương đối” tôi đọc gần đây, cuốn này bản phổ thông, không dùng toán nhưng giải thích rõ ràng. Đọc sách lại khiến tôi suy nghĩ lung tung: thời gian rốt cuộc là gì? Nếu không có chuyển động, thời gian vô nghĩa. Có lẽ thời gian con người hiểu là một dạng cảm giác tâm lý (hoạt động tâm lý?). Bạn không thể xác định 1 giây của bạn có bằng 1 giây của người khác không, chỉ có thể suy luận hai hệ thống con người cơ bản giống nhau dựa trên cấu trúc sinh lý.
Phương pháp debug phần mềm tôi thích nhất từ trước đến nay là ghi hình. Ghi lại toàn bộ input của phần mềm, sau đó phát lại khi debug. Dùng phương pháp hộp trắng, theo dõi từng bước bên trong hệ thống để tìm ra nguyên nhân sai sót rồi sửa chữa. Đối với phương pháp kiểm thử đơn vị (unit test) đang phổ biến trong ngành phần mềm, tôi lại không mấy mặn mà áp dụng trong các dự án mình tham gia.
Khi trao đổi với đồng nghiệp, nhiều người nói rằng cơ chế ghi hình khó thực hiện trong dự án thực tế. Theo tôi, đó hoàn toàn vì không đặt cơ chế ghi hình làm nền tảng thiết kế cấu trúc phần mềm. Với mô hình máy tính hiện tại, cơ chế ghi hình luôn có thể xây dựng. Dù hệ thống phức tạp như não người, mọi vấn đề đều có thể tìm ra nguyên nhân qua phát lại ghi hình (ps: Tất nhiên cần lưu ý mô hình máy tính hiện tại khác não người rất nhiều. “Phức tạp như não người” chỉ là ẩn dụ).
Điều này giống như kéo giãn vô hạn thời gian của hệ thống phức tạp (debug từng bước hoặc thêm bản ghi chi tiết), để con người phân tích kỹ lưỡng. Đối với hệ thống đó, thời gian là yếu tố không liên quan (bởi vì với mô hình máy tính hiện tại, thời gian là dữ liệu thêm vào tầng trên, cũng có thể coi là một phần input). Dù chạy thực tế hay bị phân tích, hệ thống đều giữ nguyên biểu hiện nhất quán.
Tuy nhiên, các phần mềm khổng lồ hiện nay phụ thuộc nhiều thư viện bên thứ ba đóng nguồn và các tiện ích hệ điều hành, mà các tiện ích này không xây dựng trên cùng một mô-đun ghi hình thống nhất. Điều này khiến công việc chúng ta phức tạp hơn nhiều. Nếu muốn hệ thống ghi hình phát lại hoạt động chính xác, cần xây dựng tầng trung gian cách ly riêng cho từng thành phần, rồi thêm bộ phận ghi hình thống nhất vào tầng trung gian đó.
Khi thực hiện cơ chế ghi hình phát