Bài viết Fix Bug Là Gì – Giải Đáp Đầy Đủ Nhất Về Vấn Đề Liên Quan Đến Bug thuộc chủ đề về Thắc Mắt đang được rất nhiều bạn quan tâm đúng không nào !! Hôm nay, Hãy cùng TruongGiaThien.Com.Vn tìm hiểu Fix Bug Là Gì – Giải Đáp Đầy Đủ Nhất Về Vấn Đề Liên Quan Đến Bug trong bài viết hôm nay nha !
Các bạn đang xem bài : “Fix Bug Là Gì – Giải Đáp Đầy Đủ Nhất Về Vấn Đề Liên Quan Đến Bug”

Bug là gì? Những lợi ích đến từ việc “chiến đấu” với bug là gì? Đó là một câu hỏi không mấy vui vẻ, bởi có lẽ hầu hết lập trình viên đều muốn làm tính năng mới, chứ chả mấy ai thích phải bảo trì danh mục có sẵn hay là fix bug.

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

Song, với cá nhân tôi, việc tìm và fix bug đem lại rất nhiều niềm vui cũng như cơ hội học hỏi, phát triển nghề nghiệp. Sau đây là một vài tổng kết của tôi về:

Bug là gì? 4 lợi ích của việc fix bugCách ghi lại bug hiệu quả3 bài học lớn và 18 kinh nghiệm xương máu về fix bug

Xem việc làm Developer chất tại TruongGiaThien.Com.VN

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

Bug là gì? Bug là những lỗi phần mềm trong chương trình hoặc hệ thống máy tính làm cho kết quả không chính xác hoặc không vận hành như mong muốn. – Theo Wikipedia

Debug là quy trình tìm kiếm và phát hiện lỗi trong phần mềm trước khi launching, đưa danh mục đến tay người dùng. Debug diễn ra ngay sau khi những dòng code đầu tiên được viết và tiếp tục được thực hiện cho đến khi kết hợp với những unit khác của lập trình tạo thành một sản phầm phần mềm hoàn chỉnh.

Fixbug (sửa lỗi) là quy trình triển khai ngay sau debug, nhằm duy trì hoặc nâng cao chất lượng danh mục.

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

Trong mỗi trường hợp, bạn đều khả năng học đôi điều về phong cách lập trình, danh mục hoặc về lĩnh vực mà phần mềm đang vận hành.

Trên hết, có 4 lí do chính, cũng là 4 niềm vui quan trọng nhất mà việc fix bug khả năng đem lại cho lập trình viên như sau:

Mỗi bug luôn dạy bạn điều gì đó

Feedback luôn là chìa khóa của phát triển danh mục và cùng lúc ấy cũng là triết lý cốt lõi của mô hình agile.

Cả unit testing và iterative development đều nhằm đưa ra feedback nhanh hơn. Với unit testing, bạn nhận được feedback về việc code có chạy hay không. Với mỗi release, bạn khả năng lắng nghe feedback của khách hàng về các tính năng mới.

Báo cáo bug cũng là phương pháp thức feedback khác về code của bạn.

khả năng có rất nhiều tác nhân gây ra ra một bug. Ví dụ:

Bạn có các câu lệnh if lồng nhau và vô tình lại đặt lệnh else ở sai nhánh.Giả định không chính xác. Chẳng hạn: truy xuất một thuộc tính không tồn tại, thế là dính NullPointerExceptionKhông bao quát hết các trường hợp. Chẳng hạn, bạn phải trả về một tổng giá trị khác đi nếu hàm được gọi với tham số XHoặc, khách hàng dùng phần mềm theo cách mà bạn không ngờ tới (nhưng vẫn hợp lệ), và thế là bùm! Dính bug!

Đào sâu tìm hiểu tác nhân gây ra ra bug, bạn sẽ đúc kết được nhiều bài học quý giá.

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

Một khi đã phải bỏ công sức, thời gian ra để tìm và fix bug, tự khắc bạn sẽ muốn viết code càng dễ debug càng tốt. Bởi vì sẽ rất khốn khổ nếu không có mọi dữ liệu rất cần thiết.

Một vấn đề cực kì dễ gặp là các Exceptions (biệt lệ) không chứa dữ liệu hữu ích.

Ví dụ như, có một đoạn code bắt buộc tổng giá trị từ 0 – 20. Bao nhiêu lần bạn dính exception chỉ vỏn vẹn “Illegal value”? Nó hoàn toàn không giúp gì nếu bạn phải sửa lỗi. Chẳng hạn, nếu như tổng giá trị 21 được nhập vào, exception nên nói là “Illegal value: 21, not in range 0 – 20”.

Việc hiển thị tổng giá trị được nhập vào cùng với khoảng tổng giá trị mong muốn, rõ ràng vô cùng hữu ích. tổng giá trị hiện nay khả năng là 21, -128 hay 65535. Chúng đều giúp bạn có manh mối để tìm ra lỗi, hơn là dòng “Illegal value” ngắn gọn.

Ngay cả Steve McConnell thi thoảng cũng phá luật này trong cuốn sách tuyệt vời Code Complete. Chẳng hạn, trong chương 15, McConnell nêu ra tình huống phát hiện một kiểu ký tự không mong muốn, nhưng thông báo lỗi lại không hiển thị ký tự đó.

Như vậy, mỗi khi tìm và fix bug, bạn cần tự hỏi: liệu khả năng thay đổi ngay điều gì trong code để sau này không gặp phải những bug dạng này không? Liệu có cách nào hoặc điều gì mình nên làm, để sau này tìm ra những bug dạng này đơn giản hơn không?

Bài Nổi Bật  Take Initiative Là Gì - Initiative Là Gì, Nghĩa Của Từ Initiative

Việc làm Developer TP. HCM

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

Fix bug đem lại niềm vui cho cả bạn và khách hàng

một trong số những niềm vui mà công việc lập trình đem lại, theo tôi, đó là làm điều có ích cho người khác. Fix bug cũng đem đến niềm vui tương tự, và thậm chí còn nhanh chóng hơn.

Bởi lẽ, để tạo ra một tính năng mới cần tốn khá nhiều thời gian, trong khi việc fix một bug khả năng chỉ cần một giờ đồng hồ. Mỗi bug được fix xong sẽ đem đến cảm hứng đã hoàn thành/đạt được điều gì. Và đó là một cảm giác tuyệt vời!

Fix bug cũng đem lại niềm vui cho khách hàng (dù nghe có vẻ oái oăm). Nếu ngay từ đầu không có bug, không phải fix bug, thì chẳng phải khách hàng sẽ vui hơn sao?. Nhưng, từ kinh nghiệm hơn 20 năm lập trình và “chiến đấu” với bug, tôi dám khẳng định: khách hàng thực sự hài lòng mỗi khi nhận về bug đã được fix xong nhanh chóng.

Vấn đề là vậy: Tất cả mọi người đều biết SẼ LUÔN CÓ BUG! Cho nên, miễn là có người sẵn sàng fix thật nhanh ngay khi bug được khui ra.

Thư giãn với video: Fix bug “chất” như Vinh Râu

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

*

Rất nhiều lập trình viên thích giải câu đố, như chơi trò Sudoku, giải ô chữ, giải đố vui toán học, hay tham gia các thử thách lập trình.

Thậm chí, đọc truyện trinh thám giết người cũng đem lại rất nhiều hứng khởi: bạn lần theo các manh mối để tìm hiểu mọi chuyện đã diễn ra như thế nào.

Debug và fix bug cũng vậy. Mỗi bug là một bí ẩn cần khám phá.

Thông thường, phản ứng đầu tiên của bạn khi trông thấy một báo cáo bug sẽ là: Không thể nào! Tại sao khả năng xảy ra bug này được?!?

Và cũng từ đó, bạn bắt đầu hành trình khám phá bí ẩn. Bạn lần theo các manh mối. Logs nói gì? Có báo cáo lỗi nào từ hệ thống không? Tại thời điểm đó, hệ thống có xảy ra vấn đề gì khác hay không? Gần đây có cái gì bị thay đổi ngay không – phần mềm mới, thay đổi ngay cấu hình, lưu lượng truy cập tác động?

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

Lý do của việc cần phải ghi lại bug là gì? Để bạn khả năng học hỏi hiệu quả nhất từ những bug bạn đã fix. Phương pháp mà tôi dùng là luôn dành ra vài phút để ghi chú lại các thông tin: mô tả bug, cách fix, bài học kinh nghiệm.

Nguyên tắc

Chỉ ghi chú những bug khó nhằn hoặc thực sự thú vị. Đây không phải là bug tracker.Ghi chú những bug do chính mình gây ra ra. (Trừ trường hợp bug của người khác nhưng đủ thú vị).Ghi lại bug ngay sau khi fix xong. Tránh nhớ nhầm, nhớ không chi tiết.

Cách ghi lại bug

Tôi thường dùng form dưới đây để ghi lại bug dưới dạng file text (bugs.txt). Bạn khả năng tham khảo thông qua ví dụ sau:

Thông tin nền:

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

Sửa: Nếu chiều dài tìm thấy bằng 0, đặt nó lại bằng 1. Như vậy chúng ta sẽ luôn đi tiếp được.Sửa trong file(s): callh/q931_msg.cxxhung thủ là tôi: Đúng vậy.Thời gian sửa bug: 1 giờ.

Bài học rút ra được:

Bài học: Đặt “niềm tin lầm chỗ” vào dữ liệu của tín hiệu gửi tới. tổng giá trị dữ liệu khả năng quá lớn làm chương trình chạy sai. mặt khác khi chiều dài bằng 0 cũng khả năng là một dấu hiệu xấu.

Ba bài học lớn dành cho lập trình viên

Về coding

*

Những lỗi phạm phải trong code? Có phải đã quên một else-part? Có phải một lệnh gọi hệ thống bị thất bại, nhưng hồi đáp chưa được check? Làm sao chỉnh sửa code để tránh những vấn đề này trong tương lai?

Trình tự sự kiện

Khi xử lý sự kiện, những câu hỏi sau sẽ rất có ích:

Liệu sự kiện khả năng đến theo trật tự khác được không?Sẽ thế nào nếu không nhận được sự kiện này? Sẽ thế nào nếu sự kiện này diễn ra hai lần liên tiếp?Thậm chí, nếu nó không bao giờ xảy ra, bugs ở những phần khác của hệ thống (hoặc của những hệ thống khác có tương tác) vẫn khả năng khiến nó xảy ra.Quá sớm

Cái này là một trường hợp đặc biệt của phần “Trình tự sự kiện” ở trên. Nhưng bởi vì nó gây ra ra một vài lỗi rất khó tìm nên nó được đặt ra riêng.

Chẳng hạn, nếu tín hiệu nhận được quá sớm, trước khi các tiến trình thiết lập và khởi động hoàn tất, khả năng chương trình sẽ có những biểu hiện kỳ lạ.

Một ví dụ khác: Khi một kết nối được đánh dấu là down ngay cả trước khi nó được đưa vào danh sách idle. Khi phải tìm lỗi này, chúng ta luôn mặc định rằng nó bị đánh dấu down trong khi đang ở trong danh sách idle (nhưng lúc đó tại sao nó không được lấy ra khỏi danh sách?).

Đó là một sai lầm trong nhận thức của chúng ta khi không xét đến trường hợp có những thứ xảy ra quá sớm.

“Cái chết êm đềm”

Một trong số những lỗi khó phát hiện nhất là khi chúng lặng lẽ ra đi và chương trình tiếp tục được thực thi mà không quăng ra exception nào.

Bài Nổi Bật  Phân Biệt Phong Cách Vintage Là Gì ? Nguồn Gốc Của Thời Trang Vintage

Chẳng hạn như các lệnh gọi hệ thống (bind chẳng hạn) trả về mã lỗi nhưng không được kiểm tra.

Hoặc như, phần code để phân tích tín hiệu chỉ đơn giản return khi bắt gặp một thành phần không hợp lệ, trong khi đáng lẽ phải quăng lỗi.

Chương trình tiếp tục chạy trong trạng thái sai, làm cho debug càng khó hơn. Nói chung tốt nhất là một lỗi nên được quăng ra càng sớm càng tốt.

If

Lệnh if với nhiều điều kiện, if (a or b), đặc biệt là khi được nối lại với nhau, if (x) else if (y), gây ra ra quá trời lỗi cho tôi.

Dù cho câu lệnh if về mặt khái niệm quá đơn giản đi, chúng vẫn dễ bị sai khi có nhiều điều kiện đi kèm.

Bây giờ tôi cố gắng viết code đơn giản hơn để tránh phải xử lý những câu if phức tạp.

Else

Cũng có quá trời lỗi là do không xét đến trường hợp bỏ qua lệnh else. Gần như tất cả trường hợp, luôn phải có một lệnh else cho mỗi câu if. Hơn nữa, nếu bạn đặt một biến bên trong lệnh if, khả năng cao là bạn phải đặt nó ở những chỗ khác nữa.

Một ví dụ rất liên quan là các đoạn lệnh kiểm tra cờ (flag). Quá đơn giản khi đặt điều kiện để bật cờ, nhưng lại rất hay quên đặt điều kiện để đặt lại cờ. Để lá cờ bật liên tục khả năng cao là sẽ có lỗi về sau.

Xem thêm: Photoshop Cc Là Gì – Đâu Là Phiên Bản Photoshop Dành Cho Bạn

thay đổi ngay các giả định

Những lỗi khó phòng tránh nhất trong giai đoạn đầu thường là do thay đổi ngay giả định.

Chẳng hạn, ban đầu khả năng chỉ có một sự kiện customer mỗi ngày. Thế là rất nhiều code được viết với giả định này. Một thời gian sau, thiết kế thay đổi ngay cho phép nhiều sự kiện customer diễn ra trong ngày. Khi chuyện này xảy ra, khả năng rất khó để thay đổi ngay hết tất cả trường hợp bị tác động bởi thiết kế mới.

Nói chung không khó để tìm tất cả các phần phụ thuộc hiển nhiên. Cái khó là tìm ra những phần phụ thuộc tiềm ẩn bên trong thiết kế cũ.

Chẳng hạn khả năng có phần code thu thập tất cả sự kiện của customers trong một ngày nhất định. Một giả định hiển nhiên khả năng là kết quả trả về không bao giờ lớn hơn số lượng customers.

Tôi không biết cách nào tốt để đề phòng những trường hợp này, nếu bạn nào biết thì gợi ý giúp tôi với nha.

Logging

Điều tối quan trọng là có nhận thức về những gì chương trình vận hành, đặc biệt trong những chương trình có logic phức tạp.

Cần chắc chắn logging được đặt vừa đủ và đúng chỗ, để bạn khả năng lý luận tại sao chương trình lại chạy như vậy.

Khi mọi thứ vận hành trơn tru thì không sao, nhưng ngay khi chương trình xảy ra lỗi (chuyện không thể tránh khỏi), ít ra bạn sẽ thấy hạnh phúc vì đã logging đúng chỗ.

Về Testing

*

Có những bug rõ ràng nên được “khui” ra ngay trong quy trình test. Nếu vậy, phần test nào đã thiếu sót – unit, functional, hay system? Test case nào đã bị thiếu?

0 và null

Luôn chắc chắn kiểm tra với tổng giá trị 0 và null (nếu khả năng). Đối với chuỗi, cần lưu ý chuỗi rỗng, và chuỗi là null.

Một ví dụ khác: kiểm tra trường hợp đứt kết nối TCP trước khi bất cứ dữ liệu (zero bytes) nào được gửi.

Bỏ qua việc kiểm tra các trường hợp trên là lý do số một làm cho bug lọt khỏi phần test của tôi.

Thêm vào và xóa đi

Thường các tính năng mới sẽ dính tới chuyện thêm các thiết lập mới vào hệ thống, chẳng hạn như một kiểu định dạng mới số điện thoại.

Thường thì bạn sẽ kiểm tra xem khả năng thêm định dạng mới hay không, nhưng tôi thấy là rất dễ quên kiểm tra trường hợp xóa định dạng cũ.

Xử lý lỗi

Phần code dùng để xử lý lỗi thường rất khó kiểm tra. Tốt nhất là nên có các test tự động để kiểm tra phần này, nhưng đôi khi việc này trở nên bất khả.

Một mẹo tôi hay dùng là sửa code tạm thời để kích hoạt phần xử lý lỗi. Dễ nhất 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ác là giả vờ viết sai tên một column trong database để kích hoạt lỗi.

dùng dữ liệu đầu vào ngẫu nhiên

Một cách kiểm tra khác khả năng dùng để phát hiện bug là dùng dữ liệu đầu vào ngẫu nhiên.

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

Một ví dụ khác là tạo ra những cuộc gọi thử nghiệm, với thời gian gọi, độ trễ khi trả lời, bên nào ngắt máy trước, v.v.. được tạo ra ngẫu nhiên. Những cuộc gọi này làm lộ ra một đống bug, đặt biệt là khi chúng xen vào những sự kiện xảy ra gần như cùng lúc.

Kiểm tra hành động không mong muốn có thật sự KHÔNG diễn ra

Thường testing liên quan đến xem thử hành động mong muốn có xảy ra không. Nhưng lại rất dễ bỏ qua trường hợp ngược lại – kiểm tra hành động không mong muốn thật sự không diễn ra.

Bài Nổi Bật  Khi Muỗi Đốt Vì Sao Muỗi Cắn Lại Ngứa, Tại Sao Muỗi Đốt Lại Ngứa

Tự làm tool

Tôi thường tự làm các tool nhỏ để test dễ hơn.

Ví dụ, khi khi tôi làm việc với giao thức SIP cho VoIP, tôi viết một đoạn mã nhỏ khả năng trả lời với headers và tổng giá trị tôi mong muốn. Đoạn mã này giúp tôi kiểm tra những trường hợp đặc biệt đơn giản hơn.

Một ví dụ khác là một chương trình dòng lệnh chuyên dùng để gọi API.

Bằng cách bắt đầu nhỏ, và dần dần phát triển thêm tính năng cho nó, cuối cùng tôi xuất hiện trong nay những công cụ rất hữu dụng. Lợi ích của việc này là tôi có những công cụ đúng như tôi mong muốn.

Về Debugging

*

Cách nhanh hơn để “khui” bug là gì? Tôi đã dùng đúng tool chưa? Có phải tôi đã phỏng đoán quá nhiều? Tôi có cần logging tốt hơn không?

Thảo luận

Nếu bạn hỏi tôi cách hiệu quả nhất để xử lý bug là gì? Tôi sẽ trả lời là thảo luận với đồng nghiệp. Trong lúc tìm cách giải thích cho họ hiểu vấn đề gặp phải là gì, tôi cũng cùng lúc ấy hiểu sâu và rõ hơn về nó.

Thêm nữa, dù không quen thuộc với code trong câu hỏi, thường họ sẽ có cái nhìn khách quan để chỉ ra vấn đề khả năng nảy sinh từ đâu.

Đây là phương pháp cực kì hiệu quả giúp tôi giải quyết những bug khó nhằn nhất.

Cẩn thận đến từng tiểu tiết

Khi việc debug ngốn quá nhiều thời gian, thì thường là do tôi đã suy đoán sai.

Ví dụ, tôi nghĩ vấn đề xảy ra ở một method nào đó, trong khi thực tế không đời nào chuyện đó xảy ra.

Hoặc, một ngoại lệ xảy ra trái với ngoại lệ tôi suy đoán. Hoặc, tôi nghĩ phần mềm chạy version mới nhất, trong khi thực ra nó lại chạy một version cũ hơn.

Cho nên, hãy chắc chắn bạn đã kiểm tra lại tất cả chi tiết thay vì mặc định mọi thứ. Thật dễ để thấy những gì bạn mong muốn thấy, hơn là những gì thật sự ở đó.

thay đổi ngay mới nhất

Khi những thứ từng vận hành tự dưng trục trặc, thường là do những thay đổi ngay mới nhất gây ra nên.

Có trường hợp, bạn chỉ thay đổi ngay logging, song một lỗi trong logging đã gây ra nên sự cố lớn hơn nhiều.

Để dễ truy tìm những sự cố kiểu này, bạn nên commit những thay đổi ngay khác nhau trong những commit khác nhau, và ghi chú rõ ràng về việc thay đổi ngay.

Tin ở người dùng

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

Những kinh nghiệm thương đau đã dạy tôi rằng: Hãy tin ở người dùng.

Dĩ nhiên tôi vẫn phải kiểm tra lại để xem mọi thứ đã được thiết lập đúng chưa. Nhưng tôi đã gặp rất nhiều trường hợp kì quặc xảy ra bởi vì một thiết lập không thường gặp, một cách dùng không được dự đoán trước, hay giả định ban đầu của tôi rằng chúng phải như vậy. Và thế là chương trình chạy sai.

Test phần đã sửa

Sau khi đã sửa xong, bước tiếp theo bạn cần làm với bug là gì? Khi bug đã sửa xong thì bạn buộc phải test lại. Trước tiên, hãy chạy code mà không dùng phần đã sửa và theo dõi bug. Sau đó, dùng phần đã sửa và chạy lại test case.

Xem thêm: Hardware Store Là Gì – Nghĩa Của Từ Hardware Store Trong Tiếng Việt

Tuân theo những bước trên sẽ giúp bạn chắc chắn bug đó thực sự là bug, và phần đã sửa thực sự hiệu quả. đơn giản nhưng rất cần thiết.

*

Nếu bạn nghĩ những chia sẻ này khả năng giúp ích cho bạn bè hoặc đồng nghiệp thì đừng ngại nhấn nút Share bên dưới nha!

Chuyên mục: Hỏi Đáp

Các câu hỏi về Fix Bug Là Gì – Giải Đáp Đầy Đủ Nhất Về Vấn Đề Liên Quan Đến Bug


Nếu có bắt kỳ câu hỏi thắc mắt nào vê Fix Bug Là Gì – Giải Đáp Đầy Đủ Nhất Về Vấn Đề Liên Quan Đến Bug hãy cho chúng mình biết nha, mõi thắt mắt hay góp ý của các bạn sẽ giúp mình nâng cao hơn hơn trong các bài sau nha <3 Bài viết Fix Bug Là Gì - Giải Đáp Đầy Đủ Nhất Về Vấn Đề Liên Quan Đến Bug ! được mình và team xem xét cũng như tổng hợp từ nhiều nguồn. Nếu thấy bài viết Fix Bug Là Gì - Giải Đáp Đầy Đủ Nhất Về Vấn Đề Liên Quan Đến Bug Cực hay ! Hay thì hãy ủng hộ team Like hoặc share. Nếu thấy bài viết Fix Bug Là Gì - Giải Đáp Đầy Đủ Nhất Về Vấn Đề Liên Quan Đến Bug rât hay ! chưa hay, hoặc cần bổ sung. Bạn góp ý giúp mình nha!!

Các Hình Ảnh Về Fix Bug Là Gì – Giải Đáp Đầy Đủ Nhất Về Vấn Đề Liên Quan Đến Bug

Fix Bug Là Gì - Giải Đáp Đầy Đủ Nhất Về Vấn Đề Liên Quan Đến Bug

Các từ khóa tìm kiếm cho bài viết #Fix #Bug #Là #Gì #Giải #Đáp #Đầy #Đủ #Nhất #Về #Vấn #Đề #Liên #Quan #Đến #Bug

Tra cứu thêm báo cáo về Fix Bug Là Gì – Giải Đáp Đầy Đủ Nhất Về Vấn Đề Liên Quan Đến Bug tại WikiPedia

Bạn khả năng tìm thêm nội dung về Fix Bug Là Gì – Giải Đáp Đầy Đủ Nhất Về Vấn Đề Liên Quan Đến Bug từ web Wikipedia.◄

Tham Gia Cộng Đồng Tại

💝 Nguồn Tin tại: https://truonggiathien.com.vn/

💝 Xem Thêm Chủ Đề Liên Quan tại : https://truonggiathien.com.vn/hoi-dap/

Give a Comment