Bug là gì? Những lợi ích mang đến từ những việc “chiến đấu” với bug là gì? Đó là một trong những thắc mắc không mấy hân hoan, bởi chắc hẳn rằng phần lớn thiết kế viên hầu như mong mỏi có tác dụng tính năng mới, chđọng chả mấy ai say đắm buộc phải duy trì sản phẩm gồm sẵn tốt là fix bug.quý khách đã xem: Bug bug Tức là gì

Song, cùng với cá thể tôi, việc tìm kiếm và fix bug mang lại không hề ít thú vui tương tự như thời cơ học hỏi và giao lưu, cách tân và phát triển nghề nghiệp. Sau đó là một số tổng kết của tôi về:

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

Xem bài toán làm cho Developer chất trên inlichtet.vn

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

Bug là gì? Bug là phần nhiều lỗi ứng dụng trong công tác hoặc khối hệ thống máy tính làm cho kết quả không đúng chuẩn hoặc ko vận động như ý. – Theo Wikipedia

Debug là quy trình tìm kiếm kiếm với phân phát hiện lỗi trong phần mềm trước khi launching, chuyển thành phầm mang đến tay người dùng. Debug diễn ra ngay sau khi hồ hết mẫu code thứ nhất được viết và tiếp tục được triển khai cho tới Lúc kết phù hợp với rất nhiều unit khác của thiết kế tạo nên thành một sản phầm phần mềm hoàn chỉnh.

Bạn đang xem: Bug bug có nghĩa là gì

Fixbug (sửa lỗi) là quá trình thực hiện ngay lập tức sau debug, nhằm mục đích duy trì hoặc nâng cao unique thành phầm.

Lợi ích của bài toán chạm mặt bug là gì?

Trong mỗi trường thích hợp, chúng ta phần nhiều rất có thể học tập vài điều về phong thái lập trình, thành phầm hoặc về nghành nghề cơ mà phần mềm đã chuyển động.

Trên hết, có 4 lí do chính, cũng chính là 4 thú vui đặc trưng duy nhất nhưng mà vấn đề fix bug có thể mang lại cho lập trình viên như sau:

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

Feedback luôn là chìa khóa của trở nên tân tiến sản phẩm với đồng thời cũng chính là triết lý chủ đạo của quy mô agile.

Cả unit testing với iterative sầu development những nhằm mục tiêu đưa ra feedbachồng nhanh hao rộng. Với unit testing, các bạn cảm nhận feedback về câu hỏi code có chạy hay không. Với từng release, chúng ta cũng có thể lắng tai feedback của người tiêu dùng về những tính năng vượt trội.

Báo cáo bug cũng là bề ngoài feedbaông xã khác về code của công ty.

Có thể có rất nhiều nguim nhân gây ra một bug. Ví dụ:

Quý Khách gồm những câu lệnh if lồng nhau và vô tình lại đặt lệnh else làm việc không đúng nhánh.Giả định không chính xác. Chẳng hạn: truy nã xuất một trực thuộc tính không sống thọ, cố gắng là bám NullPointerExceptionKhông bao gồm không còn những ngôi trường thích hợp. Chẳng hạn, các bạn nên trả về một giá trị không giống đi trường hợp hàm được Call với ttê mê số XHoặc, quý khách thực hiện phần mềm theo cách nhưng các bạn không ngờ cho tới (nhưng mà vẫn phù hợp lệ), và cố gắng là bùm! Dính bug!

Đào sâu tìm hiểu nguim nhân tạo ra bug, bạn sẽ đúc rút được không ít bài học quý giá.

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

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

Một sự việc cực kỳ dễ dàng chạm mặt là những Exceptions (biệt lệ) ko cất dữ liệu hữu dụng.

Ví dụ nhỏng, có một quãng code đề xuất quý giá trường đoản cú 0 – đôi mươi. Bao nhiêu lần chúng ta bám exception chỉ vỏn vẹn “Illegal value”? Nó trọn vẹn không hỗ trợ gì nếu khách hàng đề xuất sửa lỗi. Chẳng hạn, ví như nlỗi giá trị 21 được nhập vào, 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 thuộc với tầm quý giá ước muốn, cụ thể khôn cùng hữu dụng. Giá trị bây giờ có thể là 21, -128 tốt 65535. Chúng số đông giúp cho bạn bao gồm làm mối để đưa ra lỗi, hơn là dòng “Illegal value” nlắp gọn gàng.

ngay khi Steve McConnell thi thoảng cũng phá cách thức này vào cuốn nắn sách tuyệt đối Code Complete. Chẳng hạn, vào chương thơm 15, McConnell nêu ra trường hợp phân phát hiện nay một loại ký từ bỏ không mong muốn, nhưng lại thông tin lỗi lại không hiển thị ký kết trường đoản cú đó.

Như vậy, mỗi một khi search và fix bug, bạn cần từ hỏi: liệu hoàn toàn có thể đổi khác điều gì trong code nhằm sau này không gặp mặt đề nghị mọi bug dạng này không? Liệu gồm bí quyết nào hoặc điều gì mình bắt buộc có tác dụng, nhằm sau đây đưa ra hầu như bug dạng này tiện lợi rộng không?

Việc làm Developer TP.. HCM

Việc có tác dụng Developer Hà Nội

Fix bug mang về thú vui cho cả chúng ta với khách hàng

trong số những thú vui nhưng công việc thiết kế đưa về, theo tôi, đó là làm cho điều bổ ích cho tất cả những người không giống. Fix bug cũng đem lại thú vui tựa như, cùng thậm chí là còn gấp rút hơn.

Bởi lẽ, để tạo thành một tính năng vượt trội đề nghị tốn tương đối nhiều thời hạn, trong khi Việc fix một bug hoàn toàn có thể chỉ việc một tiếng đồng hồ. Mỗi bug được fix hoàn thành sẽ đem về khoái cảm đang hoàn thành/đã có được điều gì. Và kia là một trong những xúc cảm tuyệt vời!

Fix bug cũng đưa về niềm vui mang lại khách hàng (cho dù nghe có vẻ như oái oăm). Nếu tức thì từ đầu không tồn tại bug, chưa phải fix bug, thì chẳng buộc phải người sử dụng đã vui hơn sao?. Nhưng, tự kinh nghiệm rộng hai mươi 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 thụ thích hợp mỗi lúc nhấn về bug đã được fix kết thúc lập cập.

Vấn đề là vậy: Tất cả đa số tín đồ hầu hết biết SẼ LUÔN CÓ BUG! Cho buộc phải, miễn sao có tín đồ chuẩn bị sẵn sàng fix thiệt nkhô hanh ngay trong lúc bug được khui ra.

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

Niềm vui của bài toán giải câu đố


*

Rất các lập trình viên ham mê giải câu đố, nlỗi đùa trò Sudoku, giải ô chữ, giải đố mẹo toán học, tốt tyêu thích gia các thử thách thiết kế.

Thậm chí, phát âm truyện trinc thám giết thịt người cũng đưa về tương đối nhiều hứng khởi: bạn lần theo các làm mai nhằm tìm hiểu đầy đủ cthị xã vẫn diễn ra thế nào.

Debug và fix bug cũng vậy. Mỗi bug là 1 trong bí ẩn bắt buộc tò mò.

thường thì, phản nghịch ứng thứ nhất của khách hàng khi trông thấy một báo cáo bug vẫn là: Không thể nào! Tại sao có thể xảy ra bug này được?!?

Và cũng từ kia, các bạn ban đầu hành trình tò mò bí ẩn. quý khách lần theo các dắt mối. Logs nói gì? Có report lỗi như thế nào từ bỏ khối hệ thống không? Tại thời đặc điểm này, hệ thống có xẩy ra vấn đề gì khác hay không? Gần đây gồm cái gì bị đổi khác ko – ứng dụng new, đổi khác cấu hình, lưu giữ lượng truy cập ảnh hưởng?

Cách công dụng độc nhất vô nhị để ghi lại bug là gì?

Lý bởi của câu hỏi rất cần phải đánh dấu bug là gì? Để chúng ta có thể học hỏi và chia sẻ tác dụng độc nhất trường đoản cú phần lớn bug chúng ta vẫn fix. Phương thơm pháp cơ mà tôi dùng là luôn để dành ra vài ba phút ít để ghi chú lại những thông tin: trình bày bug, cách fix, bài học kinh nghiệm.

Ngulặng tắc

Chỉ ghi crúc hầu hết bug khó nhằn hoặc đích thực thú vui. Đây không hẳn là bug tracker.Ghi chụ đầy đủ bug vì thiết yếu mình gây nên. (Trừ ngôi trường vừa lòng bug của người không giống nhưng mà đầy đủ thụ vị).Ghi lại bug tức thì sau thời điểm fix hoàn thành. Tránh nhớ nhầm, ghi nhớ không cụ thể.

Cách lưu lại bug

Tôi hay được sử dụng khung sau đây để ghi lại bug dưới dạng tệp tin text (bugs.txt). Quý khách hàng rất 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 lâu năm search thấy bởi 0, đặt nó lại bằng 1. do vậy bọn họ vẫ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 tiếng.

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

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

Ba bài học phệ dành cho lập trình sẵn viên

Về coding


*

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

Trình từ sự kiện

Lúc giải pháp xử lý sự kiện, gần như câu hỏi sau sẽ rất có ích:

Liệu sự kiện rất có thể mang lại theo chưa có người yêu từ bỏ không giống được không?Sẽ vắt làm sao còn nếu như không nhận thấy sự khiếu nại này? Sẽ chũm như thế nào giả dụ sự kiện này diễn ra nhì lần liên tiếp?Thậm chí, nếu như nó ko khi nào xẩy ra, bugs nghỉ ngơi phần lớn phần khác của khối hệ thống (hoặc của rất nhiều khối hệ thống khác có tương tác) vẫn rất có thể khiến nó xảy ra.Quá sớm

Cái này là một trường đúng theo đặc biệt của phần “Trình từ bỏ sự kiện” sinh hoạt trên. Nhưng bởi vì nó gây nên một số lỗi cực kỳ nặng nề search nên nó được đề ra riêng rẽ.

Chẳng hạn, ví như dấu hiệu nhận thấy thừa mau chóng, trước khi các các bước tùy chỉnh với khởi rượu cồn hoàn toàn, kỹ năng lịch trình sẽ sở hữu được đông đảo bộc lộ kỳ quái.

Một ví dụ khác: lúc một kết nối được đánh dấu là down trong cả trước khi nó được chuyển vào list idle. Khi cần kiếm tìm lỗi này, chúng ta luôn luôn mang định rằng nó bị khắc ghi down trong lúc đã làm việc trong list idle (mà lại thời gian đó vì sao nó ko được lôi ra ngoài danh sách?).

Đó là 1 sai trái vào dấn thức của bọn họ lúc không xét mang đến ngôi trường hợp có những máy xẩy ra thừa sớm.

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

Một trong số gần như lỗi cực nhọc phân phát hiện tại duy nhất là khi chúng lặng lẽ ra đi với công tác liên tiếp được triển khai cơ mà ko quăng ra exception làm sao.

Chẳng hạn nlỗi những lệnh Gọi khối hệ thống (bind chẳng hạn) trả về mã lỗi mà lại không được soát sổ.

Hoặc nhỏng, phần code để so sánh biểu thị chỉ đơn giản return khi bắt gặp một yếu tắc chưa hợp lệ, trong những lúc xứng đáng lẽ cần quăng lỗi.

Chương thơm trình tiếp tục chạy vào tâm lý sai, làm cho debug càng khó khăn rộng. Nói bình thường rất tốt là một trong lỗi cần được quăng ra càng nhanh càng tốt.

If

Lệnh if với nhiều điều kiện, if (a or b), nhất là khi được nối lại cùng nhau, if (x) else if (y), gây nên quá ttránh lỗi mang đến tôi.

Dù mang đến câu lệnh if về phương diện quan niệm vượt đơn giản đi, bọn chúng vẫn dễ dẫn đến không đúng Khi có khá nhiều ĐK đi kèm theo.

Bây giờ tôi nỗ lực viết code đơn giản dễ dàng hơn nhằm tránh đề nghị cách xử lý phần lớn câu if phức tạp.

Else

Cũng có thừa trời lỗi là vì không xét mang lại trường thích hợp làm lơ lệnh else. Gần như tất cả ngôi trường hợp, luôn phải gồm một lệnh else cho từng câu if. bên cạnh đó, nếu bạn đặt một vươn lên là phía bên trong lệnh if, năng lực cao là bạn phải để nó sinh hoạt những chỗ khác nữa.

Ttuyệt thay đổi những giả định

Những lỗi nặng nề phòng tránh tuyệt nhất vào quy trình tiến độ đầu thường xuyên là vì chuyển đổi giả định.

Xem thêm: Máy Cắt Tiếng Anh Là Gì ? Máy Cắt Cỏ Tiếng Anh Là Gì

Chẳng hạn, ban sơ rất có thể chỉ tất cả một sự khiếu nại customer hàng ngày. Thế là rất nhiều code được viết với giả định này. Một vài ngày sau, thi công thay đổi có thể chấp nhận được các sự khiếu nại customer diễn ra trong thời gian ngày. lúc cthị xã này xẩy ra, hoàn toàn có thể hết sức khó để đổi khác hết tất cả ngôi trường vừa lòng bị tác động vì thiết kế bắt đầu.

Nói phổ biến không khó nhằm tìm kiếm toàn bộ những phần phụ thuộc vào phân minh. Cái cạnh tranh là tìm thấy rất nhiều phần nhờ vào tiềm tàng phía bên trong xây dựng cũ.

Chẳng hạn rất có thể bao gồm 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 phân biệt rất 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 như thế nào tốt để phòng ngừa hồ hết trường vừa lòng này, nếu khách hàng làm sao biết thì nhắc nhở giúp tôi cùng với nhé.

Logging

Điều tối đặc trưng là bao gồm dấn thức về đều gì công tác hoạt động, quan trọng trong những chương trình tất cả xúc tích và ngắn gọn phức tạp.

Cần chắc chắn logging được đặt hoàn toản và đúng khu vực, để bạn có thể lý luận vì sao chương trình lại chạy như vậy.

Lúc phần lớn thiết bị chuyển động trơn tuột tru thì ko có gì, tuy thế ngay lúc lịch trình xảy ra lỗi (cthị xã cấp thiết rời khỏi), ít ra các bạn sẽ thấy niềm hạnh phúc vày đã logging đúng khu vực.

Về Testing


*

Có phần đa bug ví dụ đề nghị được “khui” ra ngay vào quy trình chạy thử. Nếu vậy, phần thử nghiệm làm sao sẽ thiếu thốn sót – unit, functional, giỏi system? Test case nào đã trở nên thiếu?

0 cùng null

Luôn chắc chắn kiểm tra với giá trị 0 với null (nếu có thể). Đối cùng với chuỗi, yêu cầu xem xét chuỗi trống rỗng, cùng chuỗi là null.

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

Bỏ qua câu hỏi kiểm soát các trường vừa lòng bên trên là nguyên do số một tạo cho bug lọt ngoài phần demo của mình.

Thêm vào cùng xóa đi

Thường những tính năng vượt trội sẽ bám tới chuyện thêm những tùy chỉnh thiết lập new vào hệ thống, chẳng hạn như một dạng hình format mới số điện thoại cảm ứng thông minh.

Thường thì các bạn sẽ đánh giá xem rất có thể thêm định dạng mới hay là không, nhưng tôi thấy là rất giản đơn quên soát sổ ngôi trường phù hợp xóa định dạng cũ.

Xử lý lỗi

Phần code dùng để làm giải pháp xử lý lỗi thường xuyên khôn cùng nặng nề chất vấn. Tốt độc nhất là buộc phải tất cả các chạy thử auto để khám nghiệm phần này, nhưng nhiều khi vấn đề này trsống phải bất khả.

Một mẹo tôi tốt sử dụng là sửa code trong thời điểm tạm thời nhằm kích hoạt phần xử trí lỗi. Dễ độc nhất là lật ngược ĐK if lại, ví dụ như gửi 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 nhằm kích hoạt lỗi.

Sử dụng tài liệu đầu vào ngẫu nhiên

Một biện pháp khám nghiệm không giống hoàn toàn có thể dùng để làm phạt hiện nay bug là áp dụng dữ liệu đầu vào hốt nhiên.

Chẳng hạn như, phần lời giải ASN.1 của giao thức H.323 hoạt động 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, chúng tôi vẫn đưa ra không hề ít lỗi trong phần này.

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

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

Thường testing liên quan đến coi thử hành động mong ước tất cả xẩy ra không. Nhưng lại rất giản đơn bỏ lỡ trường đúng theo ngược trở lại – kiểm tra hành vi không hề mong muốn thật sự ko diễn ra.

Tự làm cho tool

Tôi thường xuyên từ bỏ làm những tool bé dại để test dễ hơn.

Ví dụ, Khi lúc tôi thao tác làm việc với giao thức SIPhường mang lại VoIP, tôi viết một đoạn mã nhỏ tuổi có thể trả lời cùng với headers cùng cực hiếm tôi mong muốn. Đoạn mã này góp tôi kiểm tra phần nhiều ngôi trường đúng theo quan trọng đặc biệt thuận lợi hơn.

Một ví dụ không giống là một chương trình loại lệnh chăm dùng làm Call API.

Bằng biện pháp bắt đầu nhỏ, với dần dần cải tiến và phát triển thêm chức năng mang đến nó, sau cuối tôi bao gồm vào nay số đông nguyên tắc rất hữu ích. Lợi ích của việc này là tôi gồm có luật pháp quả như tôi mong ước.

Về Debugging


*

Cách nkhô nóng hơn nhằm “khui” bug là gì? Tôi đang sử dụng đúng tool chưa? Có buộc phải tôi đang phỏng đoán thù thừa nhiều? Tôi tất cả cần logging giỏi rộng không?

Thảo luận

Nếu các bạn hỏi tôi bí quyết công dụng tốt nhất nhằm giải pháp xử lý bug là gì? Tôi đã trả lời là thảo luận với đồng nghiệp. Trong cơ hội tìm giải pháp lý giải cho bọn họ phát âm vấn đề gặp mặt phải là gì, tôi cũng mặt khác phát âm sâu và rõ rộng về nó.

Thêm nữa, mặc dù không không còn xa lạ cùng với code trong câu hỏi, thường bọn họ sẽ sở hữu tầm nhìn rõ ràng để chỉ ra vấn đề hoàn toàn có thể nảy sinh trường đoản cú đâu.

Đây là giải pháp cực kì kết quả giúp tôi xử lý đều bug khó nhằn nhất.

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

Lúc vấn đề debug ngốn rất nhiều thời gian, thì hay là vì tôi vẫn suy đân oán sai.

ví dụ như, tôi nghĩ về vụ việc xảy ra tại một method như thế nào đó, trong lúc thực tế ko dễ thường cthị trấn đó 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 đoán. Hoặc, tôi nghĩ về ứng dụng chạy version tiên tiến nhất, trong lúc thực ra nó lại chạy một version cũ hơn.

Cho đề xuất, hãy chắc chắn là các bạn đã khám nghiệm lại tất cả chi tiết rứa vì mang định số đông đồ vật. Thật dễ dàng giúp xem đầy đủ gì bạn mong muốn thấy, hơn là các thứ thiệt sự sinh hoạt đó.

Thay đổi mới nhất

Khi số đông sản phẩm công nghệ từng vận động bỗng nhiên trục sái, thường là vì đông đảo biến đổi mới nhất gây ra.

Có ngôi trường hợp, các bạn chỉ biến hóa logging, tuy nhiên một lỗi vào logging vẫn gây ra sự ráng lớn hơn nhiều.

Để dễ truy hỏi tra cứu rất nhiều sự thay loại này, chúng ta nên commit hầu hết thế thay đổi nhau giữa những commit không giống nhau, cùng ghi chụ ví dụ về bài toán chuyển đổi.

Tin ở tín đồ dùng

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

Những kinh nghiệm thương thơm nhức sẽ dạy dỗ tôi rằng: Hãy tin vào người tiêu dùng.

Dĩ nhiên tôi vẫn nên chất vấn lại để thấy phần đa lắp thêm đã làm được tùy chỉnh cấu hình đúng chưa. Nhưng tôi đang gặp mặt không ít trường phù hợp kì quặc xảy ra bởi vì một tùy chỉnh cấu hình không hay gặp gỡ, một cách sử dụng ko được dự đoán trước, xuất xắc trả định lúc đầu của tớ rằng bọn chúng nên như vậy. Và cầm là công tác chạy không đúng.

Test phần sẽ sửa

Sau Lúc đang sửa chấm dứt, bước tiếp sau bạn cần làm cho cùng với bug là gì? lúc bug sẽ sửa kết thúc thì chúng ta nên chạy thử lại. trước hết, hãy chạy code mà lại không cần sử dụng phần đã sửa cùng quan sát và theo dõi bug. Sau đó, sử dụng phần đang sửa với chạy lại chạy thử case.

Tuân theo gần như bước trên để giúp bạn chắc chắn là bug đó thực sự là bug, và phần vẫn sửa thực thụ kết quả. Đơn giản nhưng cần thiết.


*

Nếu các bạn suy nghĩ phần lớn share này có thể giúp ích mang lại bạn bè hoặc người cùng cơ quan thì đừng xấu hổ dấn nút Share bên dưới nhé!