Trang chủ > Uncategorized > Đừng “hack”

Đừng “hack”

(Bạn có biết máy tính của Lunar Module và Command Module của tàu Apollo chỉ có 36K 16-bit words ROM và 2K 16-bit words RAM.)

Gần đây tôi gặp phải một vấn đề với Dojo trên IE9. Có một chức năng cần phải refresh DataGrid nằm trong một Dialog mỗi khi Dialog đó xuất hiện, nhưng Dialog này lại trống trơn khi chạy trên IE9. Nguyên nhân là vì DataGrid của Dojo sẽ không render đúng khi bị ẩn đi, nên việc refresh DataGrid phải được thực hiện sau khi Dialog đã xuất hiện. Đây không phải là bug, chỉ là cách mà DataGrid hoạt động. Tuy nhiên, có người đã debug và bỏ bớt một đoạn code của DataGrid để nó không gây ra lỗi, mặc dù họ không biết tại sao đoạn mã đó gây lỗi, và nó dùng để làm gì, nên cũng không thể đảm bảo việc này sẽ không gây lỗi ở chỗ khác. Đây không phải là lần đâu tiên tôi bắt gặp một cách “hack” như vậy, và không may nó lại là một trong những hướng giải quyết vấn đề thường gặp. Khi chuyện nảy sinh, đầu tiên lập trình viên sẽ nhìn quanh xem có method hay API nào đó giúp giải quyết khó khăn. Bước hai, họ tìm kiếm nguyên nhân từ các công cụ. Chậm là do đường truyền, tại trình duyệt, lỗi thì do framework, v.v. Bước ba, “đoán” rằng IE, Spring, Dojo, hay một công cụ nào khác là nguyên nhân (công cụ làm sao mà nói được), họ tìm kiếm các phương pháp để “trick” trình duyệt hay framework để che lấp phần hiện tượng của vấn đề, và thế là xong.

Thật ra, phải nói rằng cách giải quyết đã nói ở trên rất thông minh và có thể cho hiệu quả tốt. Tuy nhiên, rắc rối không nằm ở chuyện dùng cách “hack” hay không, mà là ở quan điểm của lập trình viên với những giải pháp kiểu này. Cần nhớ là đây chỉ đơn giản là cách thức cuối cùng, khi không còn con đường nào khác. Có thể nó thể hiện sự thông minh, nhanh trí của một lập trình viên, nhưng hơn hết, nên xem nó như là dấu hiệu cho thấy việc lựa chọn framework không phù hợp, thiết kế chương trình không tối ưu cho platform, hay sự thiếu hiếu biết của lập trình viên về hệ thống v.v. Mặt khác, giải pháp kiểu này sẽ góp phần couple hệ thống vào cơ chế hoạt động bên trong của framework, một runtime hay một phiên bản nào đó của chúng—những thứ vốn có thể thay đổi bất cứ lúc nào. Do vậy, nếu không tổ chức mã nguồn gọn gàng (và theo kinh nghiệm cá nhân thì thường là không) những người đi sau kế thừa tất nhiên sẽ phải rất vất vả nếu cần nắm bắt ý tưởng “sáng tạo” của người đi trước.

Nếu bạn là một người cẩn thận, hãy cố gắng thuyết phục bản thân rằng lỗi là điều bản thân khó tránh khỏi khi viết code. Và khi vấn đề xảy ra, thay vì giành thời gian để chê bai một library hay framework nào đó, hãy dùng nó để xem lại phần code của mình, cách mình hiểu và sử dụng các library hay framework, cũng như cơ chế hoạt động của chúng, để tìm ra một giải pháp gọn đẹp và hiệu quả.

Tags:
  1. Chưa có phản hồi.
  1. No trackbacks yet.

Gửi phản hồi

Mời bạn điền thông tin vào ô dưới đây hoặc kích vào một biểu tượng để đăng nhập:

WordPress.com Logo

Bạn đang bình luận bằng tài khoản WordPress.com Log Out / Thay đổi )

Twitter picture

Bạn đang bình luận bằng tài khoản Twitter Log Out / Thay đổi )

Facebook photo

Bạn đang bình luận bằng tài khoản Facebook Log Out / Thay đổi )

Google+ photo

Bạn đang bình luận bằng tài khoản Google+ Log Out / Thay đổi )

Connecting to %s

%d bloggers like this: