Fix bug là gì

Bởi

vuialo.net

16/08/2021

Bug là gì? Những tác dụng mang đến từ những việc “chiến đấu” với bug là gì? Đó là một trong thắc mắc ko mấy hí hửng, vày chắc hẳn rằng hầu hết xây dựng viên phần đông mong muốn có tác dụng tính năng lạ, chứ đọng chả mấy ai phù hợp phải duy trì sản phẩm bao gồm sẵn xuất xắc là fix bug.

Bạn đang xem: Fix bug là gì

Song, cùng với cá thể tôi, việc đào bới tìm kiếm cùng fix bug đem lại rất nhiều thú vui tương tự như cơ hội học hỏi, trở nên tân tiến nghề nghiệp. Sau đây là một vài tổng kết của tôi về:

Bug là gì? 4 công dụng của vấn đề fix bugCách ghi lại bug hiệu quả3 bài học phệ với 18 kinh nghiệm tay nghề xương máu về fix bug

Xem Việc có tác dụng Developer hóa học tại vuialo.net

Bug là gì? Debug là gì? Fixbug là gì?

Bug là gì? Bug là rất nhiều lỗi phần mềm trong lịch trình hoặc khối hệ thống máy tính xách tay tạo cho tác dụng ko chính xác hoặc không hoạt động suôn sẻ. – Theo Wikipedia

Debug là quá trình tra cứu tìm với phạt hiện tại lỗi trong phần mềm trước lúc launching, gửi thành phầm cho tay người dùng. Debug ra mắt tức thì sau thời điểm rất nhiều dòng code đầu tiên được viết cùng liên tiếp được triển khai cho tới Khi kết hợp với số đông unit khác của thiết kế tạo nên thành một sản phầm ứng dụng hoàn hảo.

Fixbug (sửa lỗi) là quá trình xúc tiến tức thì sau debug, nhằm mục tiêu bảo trì hoặc cải thiện chất lượng thành phầm.

Lợi ích của việc gặp bug là gì?

Trong mỗi ngôi trường đúng theo, các bạn rất nhiều rất có thể học tập vài nét về phong thái lập trình sẵn, sản phẩm hoặc về lĩnh vực nhưng mà ứng dụng đang chuyển động.

Trên không còn, bao gồm 4 lí vì thiết yếu, cũng là 4 nụ cười đặc biệt quan trọng tuyệt nhất nhưng việc fix bug có thể đem đến mang lại xây dựng viên như sau:

Mỗi bug luôn luôn dạy dỗ chúng ta điều gì đó

Feedbaông xã luôn là chìa khóa của trở nên tân tiến sản phẩm và bên cạnh đó cũng chính là triết lý chính yếu của mô hình agile.

Cả unit testing với iterative sầu development gần như nhằm đưa ra feedbaông xã nkhô nóng rộng. Với unit testing, bạn nhận thấy feedbaông chồng về Việc code gồm chạy hay không. Với mỗi release, chúng ta cũng có thể lắng tai feedbaông chồng của người tiêu dùng về những tính năng mới.

Báo cáo bug cũng là vẻ ngoài feedbaông chồng khác về code của người tiêu dùng.

cũng có thể có khá nhiều nguim nhân gây nên một bug. Ví dụ:

quý khách gồm các câu lệnh if lồng nhau và vô tình lại đặt lệnh else sinh sống sai nhánh.Giả định không đúng mực. Chẳng hạn: truy xuất một nằm trong tính ko vĩnh cửu, rứa là bám NullPointerExceptionKhông bao gồm không còn những trường phù hợp. Chẳng hạn, bạn đề xuất trả về một giá trị không giống đi trường hợp hàm được gọi với tmê mẩn số XHoặc, người tiêu dùng áp dụng ứng dụng theo cách cơ mà bạn không ngờ tới (tuy vậy vẫn hợp lệ), với ráng là bùm! Dính bug!

Đào sâu tò mò nguim nhân tạo ra bug, các bạn sẽ đúc kết được nhiều bài học kinh nghiệm cực hiếm.

Code của bạn sẽ dễ dàng debug hơn

Một Lúc vẫn nên bỏ sức lực, thời gian ra nhằm tìm cùng fix bug, từ tương khắc các bạn sẽ mong muốn viết code càng dễ debug càng giỏi. Bởi vì sẽ khá khốn khổ nếu như không tồn tại gần như dữ liệu cần thiết.

Một vấn đề cực kì dễ dàng chạm chán là các Exceptions (biệt lệ) ko chứa tài liệu hữu dụng.

lấy ví dụ nhỏng, tất cả một quãng code đòi hỏi cực hiếm tự 0 – đôi mươi. Bao nhiêu lần các bạn dính exception chỉ vỏn vẹn “Illegal value”? Nó hoàn toàn không giúp gì nếu như bạn cần sửa lỗi. Chẳng hạn, trường hợp như cực hiếm 21 được nhtràn lên, exception đề xuất nói là “Illegal value: 21, not in range 0 – 20”.

Việc hiển thị quý hiếm được nhập vào cùng với mức giá trị mong ước, rõ ràng khôn xiết có ích. Giá trị ngày nay rất có thể là 21, -128 xuất xắc 65535. Chúng hầu như giúp cho bạn có mối lái nhằm tìm ra lỗi, rộng là dòng “Illegal value” ngắn thêm gọn gàng.

ngay khi Steve sầu McConnell thi phảng phất cũng phá phương pháp này trong cuốn nắn sách hoàn hảo và tuyệt vời nhất Code Complete. Chẳng hạn, vào cmùi hương 15, McConnell nêu ra trường hợp phân phát hiện tại một đẳng cấp cam kết trường đoản cú không mong muốn, dẫu vậy thông báo lỗi lại ko hiển thị cam kết tự kia.

do vậy, mỗi một khi search cùng fix bug, bạn phải từ bỏ hỏi: liệu hoàn toàn có thể biến đổi điều gì trong code để sau này không gặp đề xuất hầu như bug dạng này không? Liệu bao gồm bí quyết như thế nào hoặc điều gì mình bắt buộc làm cho, nhằm trong tương lai đưa ra số đông bug dạng này tiện lợi hơn không?

Việc có tác dụng Developer TP. HCM

Việc làm cho Developer Hà Nội

Fix bug đem về thú vui cho cả chúng ta cùng khách hàng hàng

trong số những thú vui cơ mà công việc thiết kế đem đến, theo tôi, sẽ là làm cho điều bổ ích cho người khác. Fix bug cũng mang về thú vui tựa như, và thậm chí còn còn nhanh chóng rộng.

Bởi lẽ, để tạo nên một tính năng mới yêu cầu tốn tương đối nhiều thời hạn, trong lúc vấn đề fix một bug rất có thể chỉ việc một tiếng đồng hồ thời trang. Mỗi bug được fix chấm dứt đang đem về khoái cảm vẫn trả thành/có được điều gì. Và đó là một trong những xúc cảm xuất xắc vời!

Fix bug cũng đem về niềm vui mang lại quý khách hàng (cho dù nghe dường như oái oăm). Nếu tức thì từ trên đầu không có bug, chưa hẳn fix bug, thì chẳng nên quý khách đã vui hơn sao?. Nhưng, từ tay nghề rộng 20 năm lập trình sẵn với “chiến đấu” với bug, tôi dám khẳng định: người tiêu dùng đích thực ưa thích mỗi một khi nhấn về bug đã có fix chấm dứt gấp rút.

Vấn đề là vậy: Tất cả hầu như bạn phần đông biết SẼ LUÔN CÓ BUG! Cho buộc phải, miễn sao gồm tín đồ sẵn sàng fix thật nkhô nóng ngay trong khi bug được khui ra.

Thư giãn cùng với video: Fix bug “chất” nlỗi Vinch Râu

Niềm vui của Việc giải câu đố

Rất các thiết kế viên say đắm giải câu đố, nhỏng nghịch trò Sudoku, giải ô chữ, giải đố mẹo tân oán học, tuyệt tmê mệt gia các thử thách lập trình sẵn.

Thậm chí, phát âm truyện trinc thám thịt người cũng đem lại rất nhiều hứng khởi: bạn lần theo những manh mối để tò mò rất nhiều cthị xã đã diễn ra ra sao.

Debug cùng fix bug cũng thế. Mỗi bug là 1 trong bí hiểm yêu cầu tò mò.

Đôi khi, làm phản ứng thứ nhất của bạn khi nhận ra một report bug đang là: Không thể nào! Tại sao có thể xảy ra bug này được?!?

Và cũng tự kia, bạn bắt đầu hành trình dài mày mò bí mật. Quý Khách lần theo các mối manh. Logs nói gì? Có report lỗi làm sao trường đoản cú hệ thống không? Tại thời đặc điểm này, khối hệ thống bao gồm xảy ra sự việc gì khác giỏi không? Gần đây bao gồm cái gì bị đổi khác ko – phần mềm bắt đầu, chuyển đổi thông số kỹ thuật, lưu giữ lượng truy cập ảnh hưởng?

Cách hiệu quả nhất để khắc ghi bug là gì?

Lý bởi của Việc rất cần được đánh dấu bug là gì? Để chúng ta có thể học hỏi và giao lưu hiệu quả nhất trường đoản cú rất nhiều bug các bạn đang fix. Phương pháp mà lại tôi sử dụng là luôn luôn bỏ ra vài phút nhằm ghi crúc lại các thông tin: diễn đạt bug, bí quyết fix, bài học kinh nghiệm kinh nghiệm tay nghề.

Nguim tắc

Chỉ ghi chụ hồ hết bug cực nhọc nhằn hoặc thực sự thú vị. Đây chưa hẳn là bug tracker.Ghi crúc các bug vị thiết yếu bản thân gây ra. (Trừ ngôi trường hòa hợp bug của bạn khác tuy nhiên đủ thú vị).Ghi lại bug tức thì sau khoản thời gian fix ngừng. Tránh nhớ nhầm, lưu giữ không cụ thể.

Cách khắc ghi bug

Tôi hay được dùng size tiếp sau đây nhằm ghi lại bug bên dưới dạng tệp tin text (bugs.txt). Quý Khách rất có thể xem thêm trải qua ví dụ sau:

Thông tin nền:

Cách sửa – Quá trình sửa:

Sửa: Nếu chiều lâu năm tra cứu thấy bằng 0, đặt nó lại bởi 1. Bởi vậy bọn họ vẫn luôn luôn đi tiếp được.Sửa vào file(s): callh/q931_msg.cxxThủ phạm là tôi: Đúng vậy.Thời gian sửa bug: 1 giờ đồng hồ.

Bài học đúc kết được:

Bài học: Đặt “niềm tin lầm chỗ” vào dữ liệu của biểu hiện gửi tới. Giá trị dữ liệu có thể quá lớn làm lịch trình chạy không nên. Dường như lúc chiều nhiều năm bởi 0 cũng có thể là 1 tín hiệu xấu.

Ba bài học kinh nghiệm béo giành cho thiết kế viên

Về coding

Những lỗi phạm bắt buộc vào code? Có đề nghị đang quên một else-part? Có đề nghị một lệnh Gọi hệ thống bị thất bại, cơ mà trả lời không được check? Làm sao sửa đổi code nhằm rời đa số vấn đề này vào tương lai?

Trình trường đoản cú sự kiện

Khi giải pháp xử lý sự kiện, hầu hết thắc mắc sau sẽ khá có ích:

Liệu sự khiếu nại rất có thể mang lại theo đơn lẻ trường đoản cú khác được không?Sẽ nuốm như thế nào nếu như không nhận thấy sự khiếu nại này? Sẽ vậy như thế nào giả dụ sự khiếu nại này ra mắt hai lần liên tiếp?Thậm chí, giả dụ nó không lúc nào xảy ra, bugs nghỉ ngơi những phần không giống của hệ thống (hoặc của các khối hệ thống không giống có tương tác) vẫn rất có thể khiến cho nó xẩy ra.Quá sớm

Cái này là 1 trong những trường vừa lòng quan trọng đặc biệt của phần “Trình trường đoản cú sự kiện” nghỉ ngơi trên. Nhưng bởi vì nó gây nên một vài lỗi rất nặng nề tìm kiếm cho nên nó được đặt ra riêng.

Chẳng hạn, ví như bộc lộ nhận thấy quá nhanh chóng, trước lúc những quy trình cấu hình thiết lập cùng khởi đụng hoàn toàn, kỹ năng lịch trình sẽ sở hữu được đều biểu hiện kỳ quái.
Một ví dụ khác: khi một liên kết được lưu lại là down ngay cả trước khi nó được gửi vào list idle. khi buộc phải tìm lỗi này, bọn họ luôn luôn mang định rằng nó bị đánh dấu down trong lúc đang sinh hoạt trong danh sách idle (tuy vậy thời điểm kia tại vì sao nó không được lấy ra khỏi danh sách?).
Đó là một sai lạc trong thừa nhận thức của chúng ta khi không xét mang đến trường hòa hợp gồm có thiết bị xảy ra quá nhanh chóng.
“Cái bị tiêu diệt êm đềm”

Một trong những phần đông lỗi cực nhọc phát hiện nay độc nhất là lúc bọn chúng lặng lẽ âm thầm ra đi và chương trình liên tục được triển khai cơ mà ko quăng ra exception làm sao.

Chẳng hạn nhỏng các lệnh gọi hệ thống (bind chẳng hạn) trả về mã lỗi tuy thế ko được đánh giá.
Hoặc nlỗi, phần code để phân tích biểu thị chỉ dễ dàng return Khi phát hiện một yếu tắc không hợp lệ, trong lúc xứng đáng lẽ nên quăng lỗi.
Chương thơm trình liên tục chạy vào tâm lý không đúng, tạo cho debug càng khó hơn. Nói thông thường rất tốt là một trong lỗi phải được quăng ra càng sớm càng tốt.
If
Lệnh if với tương đối nhiều điều kiện, if (a or b), đặc biệt là lúc được nối lại với nhau, if (x) else if (y), gây nên vượt trời lỗi đến tôi.
Dù cho câu lệnh if về phương diện khái niệm thừa dễ dàng và đơn giản đi, chúng vẫn dễ dẫn đến không nên lúc có không ít ĐK đi kèm theo.
Bây giờ đồng hồ tôi cố gắng viết code dễ dàng hơn để tách buộc phải xử lý hồ hết câu if phức hợp.
Else
Cũng gồm thừa ttách lỗi là do không xét mang lại trường vừa lòng bỏ qua mất lệnh else. Gần như tất cả trường vừa lòng, luôn phải có một lệnh else cho mỗi câu if. Ngoài ra, nếu bạn đặt một thay đổi phía bên trong lệnh if, khả năng cao là bạn phải để nó nghỉ ngơi phần nhiều nơi khác nữa.
Một ví dụ vô cùng tương quan là những đoạn lệnh soát sổ cờ (flag). Quá thuận lợi khi để điều kiện nhằm bật cờ, tuy thế lại rất hay quên đặt ĐK để tại vị lại cờ. Để lá cờ nhảy liên tiếp có khả năng cao là sẽ có lỗi trong tương lai.
Xem thêm: Cách Download Dau Truong Thu, Tải Game Đấu Trường Thú 2 Cực Hay Trên Máy Tính
Tgiỏi thay đổi các trả định
Những lỗi khó khăn chống tách độc nhất trong quá trình đầu thường xuyên là vì chuyển đổi trả định.
Chẳng hạn, thuở đầu hoàn toàn có thể chỉ gồm một sự kiện customer từng ngày. Thế là không ít code được viết với đưa định này. Một ít ngày sau, thiết kế chuyển đổi cho phép các sự kiện customer ra mắt trong thời gian ngày. Khi chuyện này xảy ra, có thể khôn cùng nặng nề để đổi khác hết toàn bộ ngôi trường vừa lòng bị tác động vì thiết kế mới.
Nói tầm thường không khó để tra cứu toàn bộ các phần phụ thuộc vào rõ ràng. Cái cực nhọc là tìm ra số đông phần phụ thuộc tiềm ẩn bên phía trong thiết kế cũ.
Chẳng hạn có thể gồm phần code tích lũy tất cả sự kiện của customers vào một ngày cố định. Một đưa định phân minh hoàn toàn có thể là hiệu quả trả về ko bao giờ lớn hơn số lượng customers.
Tôi ko biết phương pháp nào tốt nhằm đề phòng đầy đủ ngôi trường phù hợp này, nếu như khách hàng như thế nào biết thì lưu ý giúp tôi cùng với nhé.
Logging
Điều về tối đặc biệt là có nhấn thức về mọi gì lịch trình vận động, đặc biệt quan trọng giữa những công tác tất cả lô ghích phức hợp.
Cần chắc chắn rằng logging được đặt trọn vẹn và đúng địa điểm, nhằm chúng ta có thể lý luận tại sao công tác lại chạy điều đó.
khi mọi đồ vật hoạt động trơn tru tru thì không sao, dẫu vậy ngay trong khi công tác xẩy ra lỗi (cthị trấn tất yêu tách khỏi), ít ra các bạn sẽ thấy hạnh phúc do đã logging đúng nơi.
Về Testing
Có phần đông bug cụ thể đề xuất được “khui” ra ngay vào quy trình chạy thử. Nếu vậy, phần thử nghiệm như thế nào sẽ thiếu thốn sót – unit, functional, tốt system? Test case như thế nào đã trở nên thiếu?
0 cùng null
Luôn chắc hẳn rằng kiểm tra với cái giá trị 0 với null (nếu như tất cả thể). Đối cùng với chuỗi, bắt buộc chú ý chuỗi trống rỗng, và chuỗi là null.
Một ví dụ khác: kiểm soát ngôi trường đúng theo đứt kết nối TCP trước lúc bất kể tài liệu (zero bytes) như thế nào được gửi.
Bỏ qua Việc đánh giá các ngôi trường thích hợp bên trên là nguyên do số một tạo cho bug lọt ngoài phần kiểm tra của tớ.
Thêm vào cùng xóa đi

Thường các tính năng lạ vẫn bám cho tới cthị xã thêm các thiết lập new vào khối hệ thống, chẳng hạn như một mẫu mã định dạng new số điện thoại.

Thông thường bạn sẽ đánh giá coi rất có thể thêm định dạng mới hay là không, mà lại tôi thấy là rất đơn giản quên kiểm tra ngôi trường đúng theo xóa định hình cũ.

Xử lý lỗi

Phần code dùng để làm xử lý lỗi hay vô cùng cạnh tranh chất vấn. Tốt độc nhất là phải có các thử nghiệm tự động hóa nhằm chất vấn phần này, tuy thế nhiều lúc câu hỏi này trsống bắt buộc bất khả.

Một mẹo tôi tốt cần sử dụng là sửa code tạm thời để kích hoạt phần giải pháp xử lý lỗi. Dễ độc nhất vô nhị là lật ngược điều kiện if lại, chẳng hạn như chuyển if error_count > 0 thành if error_count == 0.

Một ví dụ không giống là giả vờ viết sai tên một column vào database để kích hoạt lỗi.

Sử dụng dữ liệu nguồn vào ngẫu nhiên

Một bí quyết khám nghiệm không giống hoàn toàn có thể dùng để vạc hiện bug là thực hiện dữ liệu nguồn vào tình cờ.

Chẳng hạn nhỏng, phần giải thuật ASN.1 của giao thức H.323 vận động bên trên tài liệu nhị phân. Bằng giải pháp gửi những bytes tình cờ để giải thuật, công ty chúng tôi sẽ tìm ra rất nhiều lỗi vào phần này.

Một ví dụ không giống là tạo nên đông đảo cuộc gọi xem sét, với thời hạn Hotline, độ trễ lúc vấn đáp, bên làm sao ngắt sản phẩm trước, v.v.. được tạo thành ngẫu nhiên. Những cuộc hotline này có tác dụng lòi ra một lô bug, đặt biệt là lúc chúng xen vào phần đông sự khiếu nại xẩy ra gần như cùng lúc.

Kiểm tra hành vi không mong muốn bao gồm thật sự KHÔNG diễn ra

Thường testing tương quan cho coi test hành vi ước muốn tất cả xẩy ra ko. Nhưng lại rất dễ làm lơ ngôi trường phù hợp ngược trở lại – kiểm soát hành động không muốn thật sự ko ra mắt.

Tự làm cho tool

Tôi thường xuyên từ làm những tool nhỏ dại nhằm chạy thử dễ rộng.

lấy ví dụ, Khi Lúc tôi thao tác làm việc với giao thức SIP mang lại VoIPhường., tôi viết một đoạn mã nhỏ tuổi rất có thể vấn đáp cùng với headers và giá trị tôi mong ước. Đoạn mã này góp tôi kiểm soát phần lớn ngôi trường hòa hợp đặc biệt dễ dàng rộng.
Một ví dụ khác là 1 trong những chương trình dòng lệnh chăm dùng để điện thoại tư vấn API.
Bằng bí quyết bước đầu bé dại, với từ từ cách tân và phát triển thêm khả năng mang lại nó, cuối cùng tôi tất cả vào ni đều qui định hết sức bổ ích. Lợi ích của Việc này là tôi bao gồm mức sử dụng quả như tôi mong muốn.
Về Debugging
Cách nhanh rộng nhằm “khui” bug là gì? Tôi đang cần sử dụng đúng tool chưa? Có phải tôi đã rộp đoán thừa nhiều? Tôi có nên logging xuất sắc hơn không?
Thảo luận
Nếu chúng ta hỏi tôi phương pháp kết quả tuyệt nhất nhằm xử trí bug là gì? Tôi sẽ trả lời là bàn bạc với người cùng cơ quan. Trong thời điểm kiếm tìm bí quyết giải thích đến chúng ta gọi sự việc gặp phải là gì, tôi cũng đôi khi hiểu sâu với rõ rộng về nó.
Thêm nữa, mặc dù không thân quen với code trong thắc mắc, thường họ sẽ có được ánh nhìn khách quan để đã cho thấy vụ việc rất có thể nảy sinh từ đâu.
Đây là cách cực kỳ tác dụng giúp tôi giải quyết và xử lý mọi bug khó nhằn độc nhất vô nhị.
Cẩn thận mang lại từng tiểu tiết
khi bài toán debug ngốn rất nhiều thời hạn, thì thường là vì tôi sẽ suy đoán không đúng.
lấy ví dụ, tôi nghĩ vấn đề xẩy ra ở một method như thế nào kia, trong những lúc thực tiễn không chẳng lẽ chuyện kia xẩy ra.
Hoặc, một nước ngoài lệ xảy ra trái cùng với ngoại lệ tôi suy đân oán. Hoặc, tôi nghĩ về phần mềm chạy version mới nhất, trong những lúc thực ra nó lại chạy một version cũ rộng.
Cho đề nghị, hãy chắc chắn bạn đã bình chọn lại tất cả chi tiết cầm cố vì chưng mang định phần nhiều máy. Thật dễ dàng để xem các gì bạn muốn thấy, rộng là tất cả những gì thiệt sự làm việc đó.
Tgiỏi thay đổi nhất

Khi số đông lắp thêm từng vận động thốt nhiên trục trặc, thường xuyên là vì hồ hết biến hóa tiên tiến nhất gây ra.

Có trường phù hợp, các bạn chỉ biến đổi logging, song một lỗi trong logging sẽ gây nên sự vắt lớn hơn nhiều.

Để dễ truy nã tìm kiếm rất nhiều sự nỗ lực giao diện này, bạn nên commit phần lớn gắng thay đổi nhau trong số những commit khác nhau, với ghi chú rõ ràng về vấn đề đổi khác.

Tin vào tín đồ dùng

Đôi khi người dùng report một vấn đề làm sao đó, ý suy nghĩ thứ nhất của tôi là: Không thể nào! Chắc bọn họ lầm lẫn chứ cthị trấn kia sao xảy ra được! Nhưng rồi, hóa ra chúng ta vẫn report đúng.

Những kinh nghiệm tay nghề thương thơm nhức đã dạy dỗ tôi rằng: Hãy tin lên trên người dùng.

Dĩ nhiên tôi vẫn đề nghị đánh giá lại để xem hồ hết lắp thêm đã có cấu hình thiết lập đúng không. Nhưng tôi vẫn chạm chán tương đối nhiều ngôi trường đúng theo lạ mắt xảy ra chính vì một tùy chỉnh ko thường xuyên gặp gỡ, một biện pháp dùng ko được dự đân oán trước, hay mang định ban sơ của mình rằng bọn chúng cần điều đó. Và thế là công tác chạy sai.

Test phần đã sửa

Sau Lúc sẽ sửa xong, bước tiếp sau bạn cần làm cho với bug là gì? khi bug đã sửa xong xuôi thì chúng ta nên demo lại. Đầu tiên, hãy chạy code cơ mà ko cần sử dụng phần vẫn sửa cùng theo dõi và quan sát bug. Sau đó, thực hiện phần đã sửa với chạy lại thử nghiệm case.

Tuân theo phần đa bước bên trên sẽ giúp đỡ bạn chắc chắn rằng bug kia thực thụ là bug, và phần sẽ sửa đích thực hiệu quả. Đơn giản nhưng mà quan trọng.