Sáng nay khi chạy thử một chương trình nhỏ tôi viết đêm qua, hệ thống bất ngờ không thực thi được mà không có bất kỳ cảnh báo nào. Khi dùng gdb (phiên bản 6.3) để debug, chương trình lặng lẽ thoát ngay lập tức mà không kịp vào hàm main. Dù đã thử comment bớt gần như toàn bộ mã nguồn, vấn đề vẫn không được giải quyết.

Tình cờ nâng cấp gdb lên phiên bản 6.8, tôi bất ngờ phát hiện một ngoại lệ lạ được ghi nhận. Sau khi tiếp tục loại bỏ hoàn toàn các đoạn code nghi ngờ, chương trình bỗng hoạt động bình thường. Phân tích kỹ lại, tôi nhận ra phần code bị comment trước đó có chứa các tham chiếu gián tiếp đến thư viện Lua. Điều này dẫn đến việc chương trình khi chạy sẽ cố gắng tải tệp tin DLL của Lua nhưng không thành công.

9 năm trước, tôi đã thiết kế định dạng dữ liệu cho gói tài nguyên và gói bản vá của trò chơi NetEase. Mục tiêu ban đầu là tạo ra một hệ thống dễ phân tích, định vị nhanh tệp tin trong gói, đồng thời tối ưu hóa việc cập nhật để tiết kiệm băng thông. Dù qua năm tháng, nhiều dự án đã cải tiến định dạng gói tài nguyên, nhưng về bản chất, cấu trúc cốt lõi vẫn giữ nguyên.

Đoạn video mở đầu game do nhóm họa sĩ thiết kế chuẩn bị tích hợp vào sản phẩm thì phát hiện ra engine của chúng ta居然居然 không hỗ trợ tính năng phát video. Tôi nghĩ việc này hẳn có nhiều thư viện mã nguồn mở sẵn sàng hỗ trợ, việc triển khai chắc sẽ rất đơn giản. Không ngờ mất nguyên một ngày trời mới hoàn thành được.

Điều đầu tiên cần xem xét là giấy phép sử dụng. Thử khảo sát thì thấy ffmpeg - thư viện được sử dụng rộng rãi nhất - lại mang giấy phép GPL, không phù hợp với ứng dụng thương mại. Dù một số thành phần có thể dùng theo giấy phép LGPL, nhưng việc tuân thủ các điều khoản cũng phức tạp không kém. Cân nhắc kỹ, tôi quyết định từ bỏ ý định dùng ffmpeg, không muốn dẫm vào vết xe đổ như các phần mềm như Bão Phong Ảnh hay QQ Player từng vướng vào tai tiếng.

Năm ngoái tôi từng giới thiệu giao diện mô-đun mảng động mà mình triển khai trong một dự án. Trên thực tế, mô-đun này còn hỗ trợ nhiều thao tác phong phú hơn, ví dụ như chức năng xóa phần tử được chỉ định bởi một trình lặp (iterator):

1

void array_erase(struct array *, seqi iter);

Theo thiết kế ban đầu, hàm array_erase sẽ xóa phần tử mà tham số iter trỏ đến. Tuy nhiên, điều này đặt ra một câu hỏi quan trọng: sau khi xóa, iter có nên tiếp tục duy trì tính hợp lệ hay không?
Về mặt lý thuyết, sau khi thực hiện xóa, iter nên trở thành một trình lặp vô hiệu vì phần tử mà nó trỏ đến đã bị hủy bỏ. Trên thực tế, khi duyệt mảng để xóa các phần tử thỏa mãn điều kiện nào đó, việc làm mất hiệu lực của tất cả iterator hiện tại sẽ khiến người dùng gặp nhiều bất tiện.

Trong quá trình phát triển phiên bản Windows của dự án hiện tại, nhóm chúng tôi đã sử dụng môi trường MinGW để xây dựng. Mặc dù có thể dùng gdb để gỡ lỗi và xem luồng thực thi khi ứng dụng gặp sự cố, nhưng phương pháp này vẫn chưa thực sự tối ưu trong nhiều trường hợp.

Trong một sự cố gần đây, phần mềm trình chỉnh sửa mô hình do nhóm phát triển khi triển khai cho đồng nghiệp tại Học viện Mỹ thuật Quảng Châu đã gặp lỗi nghiêm trọng. Điều này một lần nữa khẳng định tính “khó chiều” của ứng dụng 3D khi chạy trên các nền tảng card đồ họa khác nhau. Đặc biệt là khi phải gỡ lỗi từ xa, việc xác định nguyên nhân gặp rất nhiều khó khăn. Đây chính là lúc chúng tôi mong muốn có công cụ hiển thị luồng gọi hàm để phân tích nguyên nhân sự cố.

Việc chia nhỏ hệ thống máy chủ game trực tuyến thành nhiều tiến trình độc lập, triển khai phân tán mang lại nhiều lợi thế đáng kể. Thiết kế này tự nhiên tạo ra sự phân tách module, cho phép phát triển từng thành phần riêng biệt. Việc phân bổ tải trọng giữa các tiến trình không chỉ giúp tối ưu hiệu năng mà còn nâng cao khả năng mở rộng tổng thể của hệ thống.