Tìm thấy bug khá khôi hài trong phần mềm

Theo dõi blog này một thời gian hẳn bạn cũng biết một điều rằng nhóm KACBT có mông má một phần mềm trong lĩnh vực thư viện để sử dụng cho chính mình. Sau đó, có một vài đơn vị cảm thấy thích phần mềm này nên nhóm cũng chia sẻ, cho thuê phần mềm thư viện. Câu chuyện liên quan đến bug được chia sẻ cho vui như sau.

Bug trong lập trình, chuyện thường ngày ở huyện

Bug nghe như con bọ nhưng nó lại là một thứ liên quan đến máy tính. Vì sao người ta sử dụng chữ bug? Nó có cả một lịch sử lỗi phần mềm khá thú vị. Kacbt không muốn bê lịch sử đó vào đây, bạn tiện qua bên Wikipedia để xem nhé.

Vậy thì việc xử lý lỗi phần mềm cũng hình dung giống như việc bắt, gắp con bọ ra khỏi máy móc hoặc vật chủ nếu đó là con bọ ký sinh. Việc bắt này dĩ nhiên là mang tính tích cực, có dụng ý tốt chứ không phải xấu.

Việc phần mềm có lỗi, có bug là rất thường xảy ra, ngay cả một lập trình viên kỳ cựu vẫn có thể dính phải lỗi như thường bởi có những lỗi thuộc chủ quan của người lập trình không đủ giỏi, nhưng có những lỗi do nhiều nhân tố tác động nên không ai có khả năng lường trước được mọi việc.

Những ngộ nhận đáng buồn cười

Nếu bạn có thời gian lang thang các cộng đồng lập trình viên trao đổi với nhau bạn sẽ thấy có một tình trạng rất vừa thú vị nhưng vừa cảm thấy bực mình nếu bạn đã có một số năm viết mã.

Tại sao lại có chuyện vừa thú vị vừa bực mình cơ chứ? Đúng như vậy đó. Có thể bạn nhớ lại những ngày bạn mới chập chững vào nghề viết code hoặc học lập trình? Nhớ lại, bạn mới thấy là có những câu hỏi, những chia sẻ hoặc “phát hiện động trời” khi một bạn học sinh, sinh viên nói rằng cô ấy hoặc anh ấy phát hiện ra lỗi trong phần mềm nào đó. Họ còn khẳng định chắc như đinh đóng cột rằng họ đã kiểm tra rất kỹ rằng chương trình họ viết hoàn toàn chính xác, không có khả năng tạo ra lỗi, mà chỉ có thể là do IDE, trình biên dịch hoặc hệ điều hành.

Ngày đó bạn có từng vậy? Nếu không, bạn là một trong những kẻ may mắn quá đỗi hoặc già trước tuổi nên không còn những phút trẻ trâu nữa.

Cũng có ngộ nhận khác đó là khi đã được sửa lỗi bởi người có kinh nghiệm hơn, như trưởng nhóm, thầy giáo chẳng hạn, phần mềm sẽ hết lỗi. Điều này là có khi chỉ trong thời gian ngắn mà thôi. Một ngày nào đó có thể hóa ra lỗi đã được làm cho nghiêm trọng hơn thay vì được sửa.

Có bug ngay trong SLiMS Fork

Phần mềm SLiMS Bulian của Indonesia được nhóm Kacbt đục đẽo cải tiến thêm một số tính năng để phù hợp với nhu cầu sử dụng. Trong quá trình này chúng tôi thừa nhận rằng mình làm cho phần mềm trở nên mất ổn định hơn dù có thể có những chức năng như ý.

Nếu đúng logic ra đó là bạn đọc chỉ được mượn sách khi tư cách thành viên hợp lệ, thẻ bạn đọc cũng còn hạn sử dụng. Đàng này, lỗi lập trình đã có sự kiểm tra tính hợp lệ của bạn đọc trước khi thực hiện giao dịch nhưng cách nào đó người viết mã đã “quên” việc tắt nút cho mượn sách.

Lỗi này sẽ dẫn đến việc bạn đọc vẫn mượn được sách như bình thường. Có khả năng vẫn chẳng có gì xảy ra cho đến ngày cuốn sách được trả về lại thư viện. Nhưng cũng có thể xảy ra nhiều việc rắc rối như khi trả lại thì lại bị chức năng cho trả sách cảnh báo rằng không thể thực hiện giao dịch bởi vì bạn đọc bị treo tư cách thành viên, thẻ hết hạn.

Giả sử lỗi trên mà liên quan đến tiền bạc như ở ngân hàng, cửa hàng, rạp chiếu phim… không rõ chuyện gì xảy ra nhỉ? Ông bà ta có câu “sai một con số bán một con trâu” hoặc “sai một ly, đi một dặm” là nhằm để tự răn mình và răn các thế hệ sau cần phải cẩn thận hơn trước việc ăn nói, viết lách.

Có những lỗi lập trình rất đắt giá, hàng triệu đô la mất đi, mà có khi chỉ là lỗi… chính tả.

Để hạn chế bug người ta làm gì?

Thiệt hại liên quan đến bug gây ra những hậu quả tai hại. Do đó, người ta, những lập trình viên cần phải nghĩ ra cách để phòng ngừa theo phương châm “phòng bệnh hơn chữa bệnh”.

Trong thực tế, khi làm phần mềm có tính phức tạp một chút, có từ hai người chung sức trở lên hoặc chỉ một người nhưng luôn tâm niệm “thực hành tốt” thì việc kiểm tra trước khi phát hành là cần thực hiện.

Người trực tiếp viết code sẽ phải theo một quy trình các bước phát triển phần mềm khá nghiêm ngặt. VIệc test trong quá trình viết code được áp dụng ngay, thường có một phương pháp khá phổ biến được gọi là unit test.

Khi phần mềm đã thành hình hài, chạy được rồi thì có cả một đội ngũ thực hiện việc test phần mềm. Việc test phân làm 2 nhóm chính đó là test thủ công và test tự động. Dù là test nào đi nữa cũng có con người thực hiện chứ chưa thể giao phó hoàn toàn cho máy tính xử lý luôn được.

Test thủ công được thực hiện khá giống với người dùng thực sự sẽ sử dụng phần mềm đó trong tương lai, các chức năng dành cho người dùng từ thông thường cho đến quản trị viên,… test từ giao diện sử dụng cho đến xử lý số liệu, báo cáo… Test thủ công thì mất nhiều thời gian hơn

Trong thực tế, nhiều phần mềm cần được test tự động trước rồi sau đó trải qua bước test thủ công trước khi phát hành.

Ngày nay các phần mềm vận hành có liên quan đến mạng Internet nhiều nên người ta còn có thêm test về bảo mật. Việc này có khi phải thuê công ty chuyên về bảo mật làm bởi vì nhiều đơn vị phát triển phần mềm không đủ khả năng thực hiện.

Gợi mở: ngoài bug phần mềm, có những cái được gọi là “tính năng” nhưng với người dùng đó là thứ rất bực mình. Bạn có thể tìm hiểu thêm về việc tại sao khi nhập đúp chuột để chọn một từ trong Word nói riêng, vài phần mềm soạn / hiển thì thảo văn bản trên hệ điều hành Windows thì thể nào khi bạn copy dán chỗ khác nó cũng “tặng kèm” cho bạn một khoảng cách phía sau từ đó.

Bạn có từng nghe đến “quả trứng phục sinh” trong phần mềm, trò chơi điện tử chưa? Nếu chưa, giờ là lúc bạn mở mang thêm chút kiến thức vui vui nhé.

Kết bài: trong thực tế cũng đã từng xảy ra bug nhưng rồi trở thành tính năng được yêu thích.