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ì sản phẩm có sẵn hay là fix bug.
Bạn đang xem: Fix bug là gì
Song, với cá thể tôi, việc tìm và fix bug đem lại rất nhiều niềm vui cũng như thời cơ học hỏi, tăng trưởng nghề nghiệp. Sau đây là 1 số ít 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 bugBug là gì ? 4 quyền lợi của việc fix bugCách ghi lại bug hiệu quả3 bài học kinh nghiệm lớn và 18 kinh nghiệm tay nghề xương máu về fix bug
Xem việc làm Developer chất tại thienmaonline.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 hoạt động như mong muốn. – Theo Wikipedia
Debug là quá trình tìm kiếm và phát hiện lỗi trong phần mềm trước khi launching, đưa sản phẩm đế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à quá trình triển khai ngay sau debug, nhằm duy trì hoặc nâng cao chất lượng sản phẩm.
Lợi ích của việc gặp bug là gì?
Trong mỗi trường hợp, bạn đều hoàn toàn có thể học đôi điều về phong thái lập trình, mẫu sản phẩm hoặc về nghành nghề dịch vụ mà ứng dụng đang hoạt động giải trí .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 hoàn toàn có thể đ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 tăng trưởng mẫu sản phẩm và đồng thời cũng là triết lý cốt lõi của quy mô agile .Cả unit testing và iterative development đều nhằm mục đích đư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 hoàn toàn có thể lắng nghe feedback của người mua về những tính năng mới .Báo cáo bug cũng là hình thức feedback khác về code của bạn .Có thể có rất nhiều nguyên do gây 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 giá trị khác đi nếu hàm được gọi với tham số XHoặc, khách hàng sử 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!Bạn có những 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 đúng chuẩn. Chẳng hạn : truy xuất một thuộc tính không sống sót, thế là dính NullPointerExceptionKhông bao quát hết những trường hợp. Chẳng hạn, bạn phải trả về một giá trị khác đi nếu hàm được gọi với tham số XHoặc, người mua sử dụng ứng dụng 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 khám phá nguyên do gây ra bug, bạn sẽ đúc rút được nhiều bài học kinh nghiệm quý giá .
Code của bạn sẽ dễ debug hơn
Một khi đã phải bỏ sức lực lao động, thời hạn 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 tài liệu thiết yếu .Một yếu tố cực kỳ dễ gặp là những Exceptions ( biệt lệ ) không chứa tài liệu hữu dụng .Ví dụ như, có một đoạn code nhu yếu giá trị từ 0 – 20. Bao nhiêu lần bạn dính exception chỉ vỏn vẹn “ Illegal value ” ? Nó trọn vẹn không giúp gì nếu bạn phải sửa lỗi. Chẳng hạn, nếu như 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ị giá trị được nhập vào cùng với khoảng chừng giá trị mong ước, rõ ràng vô cùng hữu dụng. Giá trị hiện tại hoàn toàn có thể 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 trường hợp phát hiện một kiểu ký tự không mong ước, nhưng thông tin 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 hoàn toàn có thể biến hóa đ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 thuận tiện hơn không ?Việc làm Developer TP. TP HCMViệc làm Developer TP.HN
Fix bug đem lại niềm vui cho cả bạn và khách hàng
Một trong những niềm vui mà việc làm lập trình mang 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ự như, và thậm chí còn còn nhanh gọn 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 hạn, trong khi việc fix một bug hoàn toàn có thể chỉ cần một giờ đồng hồ đeo tay. Mỗi bug được fix xong sẽ đem đến khoái cảm đã hoàn thành xong / đạt được điều gì. Và đó là một cảm xúc tuyệt vời !Fix bug cũng đem lại niềm vui cho người mua ( dù nghe có vẻ như oái oăm ). Nếu ngay từ đầu không có bug, không phải fix bug, thì chẳng phải người mua sẽ vui hơn sao ?. Nhưng, từ kinh nghiệm tay nghề hơn 20 năm lập trình và “ chiến đấu ” với bug, tôi dám khẳng định chắc chắn : người mua thực sự hài lòng mỗi khi nhận về bug đã được fix xong nhanh gọn .
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 những 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 những manh mối để khám phá 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 huyền bí cần mày mò .Thông thường, phản ứng tiên phong của bạn khi trông thấy một báo cáo giải trình bug sẽ là : Không thể nào ! Tại sao hoàn toàn có thể xảy ra bug này được ? ! ?Và cũng từ đó, bạn mở màn hành trình dài mày mò huyền bí. Bạn lần theo những manh mối. Logs nói gì ? Có báo cáo lỗi nào từ mạng lưới hệ thống không ? Tại thời gian đó, mạng lưới hệ thống có xảy ra yếu tố gì khác hay không ? Gần đây có cái gì bị đổi khác không – ứng dụng mới, đổi khác thông số kỹ thuật, lưu lượng truy vấn tác động ảnh hưở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 hoàn toàn có thể học hỏi hiệu suất cao 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 những thông tin : miêu tả bug, cách fix, bài học kinh nghiệm kinh nghiệm tay nghề .
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. (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
Chỉ ghi chú những bug khó nhằn hoặc thực sự mê hoặc. Đây không phải là bug tracker. Ghi chú những bug do chính mình gây ra. ( Trừ trường hợp bug của người khác nhưng đủ mê hoặc ). Ghi lại bug ngay sau khi fix xong. Tránh nhớ nhầm, nhớ không chi tiết cụ thể .Tôi thường dùng form dưới đây để ghi lại bug dưới dạng file text ( bugs.txt ). Bạn hoàn toàn có thể tìm hiểu 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 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.cxxThủ phạm là tôi: Đúng vậy.Thời gian sửa bug: 1 giờ.Nếu chiều dài tìm thấy bằng 0, đặt nó lại bằng 1. Như vậy tất cả chúng ta sẽ luôn đi tiếp được. callh / q931_msg. cxxĐúng vậy. 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. Giá trị dữ liệu có thể quá lớn làm chương trình chạy sai. Ngoài ra khi chiều dài bằng 0 cũng có thể 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
Đặt “ niềm tin lầm chỗ ” vào tài liệu của tín hiệu gửi tới. Giá trị tài liệu hoàn toàn có thể quá lớn làm chương trình chạy sai. Ngoài ra khi chiều dài bằng 0 cũng hoàn toàn có thể là một tín hiệu xấu .
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 mạng lưới hệ thống bị thất bại, nhưng trả lời chưa được check ? Làm sao chỉnh sửa code để tránh những yếu tố này trong tương lai ?Trình tự sự kiệnTrình tự sự kiệnKhi xử lý sự kiện, những câu hỏi sau sẽ rất có ích :Liệu sự kiện có thể đế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 có thể khiến nó xảy ra.Quá sớmLiệu sự kiện hoàn toàn có thể đế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 tục ? Thậm chí, nếu nó không khi nào xảy ra, bugs ở những phần khác của mạng lưới hệ thống ( hoặc của những mạng lưới hệ thống khác có tương tác ) vẫn hoàn toàn có thể khiến nó xảy ra .Cái này là một trường hợp đặc biệt quan trọng của phần “ Trình tự sự kiện ” ở trên. Nhưng chính bới nó gây ra một số ít 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 những tiến trình thiết lập và khởi động hoàn tất, năng lực chương trình sẽ có những bộc lộ kỳ lạ .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 đưa vào list idle. Khi phải tìm lỗi này, tất cả chúng ta luôn mặc định rằng nó bị ghi lại down trong khi đang ở trong list idle ( nhưng lúc đó tại sao nó không được lấy ra khỏi list ? ) .Đó là một sai lầm đáng tiếc trong nhận thức của tất cả 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”“ 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 liên tục được thực thi mà không quăng ra exception nào .
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 để nghiên cứu và phân tích tín hiệu chỉ đơn thuần return khi phát hiện 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 liên 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 .IfLệnh if với nhiều điều kiện kèm theo, if ( a or b ), đặc biệt quan trọng là khi được nối lại với nhau, if ( x ) else if ( y ), gây 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 thuần đi, chúng vẫn dễ bị sai khi có nhiều điều kiện kèm theo đi kèm .Bây giờ tôi nỗ lực viết code đơn thuần hơn để tránh phải giải quyết và xử lý những câu if phức tạp .ElseCũng có quá trời lỗi là do không xét đến trường hợp bỏ lỡ lệnh else. Gần như toàn bộ 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, năng lực 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á dễ dàng 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 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 các giả địnhNhững lỗi khó phòng tránh nhất trong quy trình tiến độ đầu thường là do đổi khác giả định .Chẳng hạn, bắt đầu hoàn toàn có thể 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 hạn sau, phong cách thiết kế biến hóa được cho phép nhiều sự kiện customer diễn ra trong ngày. Khi chuyện này xảy ra, hoàn toàn có thể rất khó để biến hóa hết tổng thể trường hợp bị ảnh hưởng tác động bởi phong cách thiết kế mới .Nói chung không khó để tìm toàn bộ những 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 phong cách thiết kế cũ .Chẳng hạn hoàn toàn có thể có phần code tích lũy tổng thể sự kiện của customers trong một ngày nhất định. Một giả định hiển nhiên hoàn toàn có thể là hiệu quả trả về không khi nào 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 nhé .LoggingĐiều tối quan trọng là có nhận thức về những gì chương trình hoạt động giải trí, đặc biệt quan trọng trong những chương trình có logic phức tạp .Cần chắc như đinh logging được đặt vừa đủ và đúng chỗ, để bạn hoàn toàn có thể lý luận tại sao chương trình lại chạy như vậy .Khi mọi thứ hoạt động giải trí trơn tru thì không sao, nhưng ngay khi chương trình xảy ra lỗi ( chuyện không hề tránh khỏi ), ít ra bạn sẽ thấy niềm 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à nullLuôn chắc như đinh kiểm tra với giá trị 0 và null ( nếu hoàn toàn có thể ). Đối với chuỗi, cần chú ý quan tâm chuỗi rỗng, và chuỗi là null .Một ví dụ khác : kiểm tra trường hợp đứt liên kết TCP trước khi bất kể tài liệu ( zero bytes ) nào được gửi .Bỏ qua việc kiểm tra những trường hợp trên là nguyên 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 điThêm vào và xóa điThường những tính năng mới sẽ dính tới chuyện thêm những thiết lập mới vào mạng lưới hệ thống, ví dụ điển hình như một kiểu định dạng mới số điện thoại thông minh .Thường thì bạn sẽ kiểm tra xem hoàn toàn có thể 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ỗiPhần code dùng để giải quyết và xử lý lỗi thường rất khó kiểm tra. Tốt nhất là nên có những test tự động hóa để kiểm tra phần này, nhưng đôi lúc việc này trở nên bất khả .Một mẹo tôi hay dùng là sửa code trong thời điểm tạm thời để kích hoạt phần giải quyết và xử lý lỗi. Dễ nhất là lật ngược điều kiện kèm theo if lại, ví dụ điển hình như chuyển if error_count > 0 thành if error_count = = 0 .Một ví dụ khác là vờ vịt viết sai tên một column trong database để kích hoạt lỗi .Sử dụng dữ liệu đầu vào ngẫu nhiênMột cách kiểm tra khác hoàn toàn có thể dùng để phát hiện bug là sử dụng tài liệu nguồn vào ngẫu nhiên .Chẳng hạn như, phần giải thuật ASN. 1 của giao thức H. 323 hoạt động giải trí trên tài liệu nhị phân. Bằng cách gửi những bytes ngẫu nhiên để giải thuật, 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 hạn gọi, độ trễ khi vấn đáp, 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 raThường testing tương quan đến xem thử hành vi mong ước có xảy ra không. Nhưng lại rất dễ bỏ lỡ trường hợp ngược lại – kiểm tra hành vi không mong ước thật sự không diễn ra .Tự làm toolTôi thường tự làm những tool nhỏ để test dễ hơn .Ví dụ, khi khi tôi thao tác với giao thức SIP cho VoIP, tôi viết một đoạn mã nhỏ hoàn toàn có thể vấn đáp với headers và giá trị tôi mong ước. Đoạn mã này giúp tôi kiểm tra những trường hợp đặc biệt quan trọng thuận tiệ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 khởi đầu nhỏ, và từ từ tăng trưởng thêm tính năng cho nó, sau cuối tôi có 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 ước .
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ậnNếu bạn hỏi tôi cách hiệu suất cao nhất để giải quyết và xử lý bug là gì ? Tôi sẽ vấn đáp là tranh luận với đồng nghiệp. Trong lúc tìm cách lý giải cho họ hiểu yếu tố gặp phải là gì, tôi cũng đồng thời 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 yếu tố hoàn toàn có thể phát sinh từ đâu .Đây là cách cực kỳ hiệu suất cao giúp tôi xử lý những bug khó nhằn nhất .Cẩn thận đến từng tiểu tiếtKhi việc debug ngốn quá nhiều thời hạn, thì thường là do tôi đã suy đoán sai .Ví dụ, tôi nghĩ yếu tố xảy ra ở một method nào đó, trong khi thực tiễn 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ĩ ứng dụng 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 như đinh bạn đã kiểm tra lại tổng thể cụ thể thay vì mặc định mọi thứ. Thật dễ để thấy những gì bạn mong ước thấy, hơn là những gì thật sự ở đó .Thay đổi mới nhấtKhi những thứ từng hoạt động giải trí tự dưng trục trặc, thường là do những thay đổi mới nhất gây nên .Có trường hợp, bạn chỉ biến hóa logging, tuy nhiên một lỗi trong logging đã gây nên sự cố lớn hơn nhiều .Để dễ truy lùng những sự cố kiểu này, bạn nên commit những đổi khác khác nhau trong những commit khác nhau, và ghi chú rõ ràng về việc biến hóa .Tin ở người dùngĐôi khi người dùng report một yếu tố nào đó, ý nghĩ tiên phong 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 tay nghề 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 chính bới một thiết lập không thường gặp, một cách dùng không được Dự kiến trước, hay giả định khởi đầ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 đó, sử 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 cần thiết.
Nếu bạn nghĩ những chia sẻ này có thể 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 nhé!
Chuyên mục: Chuyên mục : Hỏi Đáp
