Fix bug là gì

     

Bug là gì? Những lợi ích mang đến từ việc “chiến đấu” cùng với bug là gì? Đó là một trong thắc mắc ko mấy vui tươi, vì chưng có lẽ phần lớn thiết kế viên phần lớn hy vọng làm cho tính năng mới, chứ đọng chả mấy ai đam mê cần gia hạn sản phẩm tất cả sẵn tốt là fix bug.

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

quý khách hàng đã xem: Fix bug là gì

Song, với cá thể tôi, việc tìm và đào bới với fix bug mang lại không hề ít thú vui cũng giống như thời cơ học hỏi và giao lưu, trở nên tân tiến công việc và nghề nghiệp. Sau đó là một số tổng kết của tôi về:

Bug là gì? 4 tác dụng của bài toán fix bugCách khắc ghi bug hiệu quả3 bài học to 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 trên ahtq.vn

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

Bug là gì? Bug là đầy đủ lỗi phần mềm vào lịch trình hoặc khối hệ thống máy tính làm cho kết quả không đúng mực hoặc không vận động suôn sẻ. – Theo Wikipedia

Debug là quy trình kiếm tìm tìm và phạt hiện nay lỗi vào ứng dụng trước khi launching, gửi thành phầm mang đến tay người dùng. Debug diễn ra ngay lập tức sau khoản thời gian đầy đủ loại code trước tiên được viết và tiếp tục được tiến hành cho tới khi kết hợp với phần lớn unit khác của lập trình sẵn tạo ra thành một sản phầm ứng dụng hoàn hảo.

Fixbug (sửa lỗi) là quá trình triển khai ngay lập tức sau debug, nhằm bảo trì hoặc nâng cao unique thành phầm.

Lợi ích của câu hỏi gặp bug là gì?

Trong mỗi ngôi trường hòa hợp, bạn gần như có thể học tập đôi điều về phong thái lập trình sẵn, sản phẩm hoặc về nghành nghề mà ứng dụng sẽ hoạt động.

Trên không còn, tất cả 4 lí do chủ yếu, cũng là 4 thú vui đặc biệt tuyệt nhất mà lại việc fix bug rất có thể đem về đến thiết kế viên nlỗi sau:

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

Feedbaông xã luôn là chiếc chìa khóa của cách tân và phát triển thành phầm và đồng thời cũng chính là triết lý cốt yếu của quy mô agile.

Cả unit testing với iterative sầu development mọi nhằm mục đích giới thiệu feedback nhanh hao rộng. Với unit testing, các bạn nhận được feedback về câu hỏi code gồm chạy hay là không. Với mỗi release, bạn có thể lắng nghe 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 feedback khác về code của công ty.

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

quý khách tất cả các câu lệnh if lồng nhau và vô tình lại đặt lệnh else sinh hoạt không đúng nhánh.Giả định ko đúng đắn. Chẳng hạn: truy xuất một thuộc tính không lâu dài, cố gắng là dính NullPointerExceptionKhông bao gồm không còn những ngôi trường vừa lòng. Chẳng hạn, bạn đề nghị trả về một cực hiếm khác đi ví như hàm được gọi cùng với tđê mê số XHoặc, khách hàng sử dụng ứng dụng Theo phong cách cơ mà chúng ta không ngờ cho tới (tuy vậy vẫn hòa hợp lệ), và cố là bùm! Dính bug!

Đào sâu khám phá nguyên nhân tạo ra bug, các bạn sẽ đúc rút được nhiều bài học kinh nghiệm giá trị.

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

Một Lúc đang phải quăng quật công sức, thời hạn ra để search cùng fix bug, trường đoản cú tương khắc các bạn sẽ mong muốn viết code càng dễ dàng debug càng xuất sắc. Bởi vày sẽ khá khốn khổ trường hợp không có phần lớn tài liệu cần thiết.

Một vấn đề rất là dễ dàng gặp gỡ là những Exceptions (biệt lệ) không cất dữ liệu hữu dụng.

lấy ví dụ nlỗi, gồm một đoạn code hưởng thụ quý hiếm từ 0 – đôi mươi. Bao nhiêu lần chúng ta dính exception chỉ vỏn vẹn “Illegal value”? Nó hoàn toàn không giúp gì nếu như khách hàng cần sửa lỗi. Chẳng hạn, ví như như quý giá 21 được nhập lệ, exception cần nói là “Illegal value: 21, not in range 0 – 20”.

Việc hiển thị giá trị được nhtràn vào thuộc với khoảng cực hiếm ước muốn, ví dụ vô cùng hữu dụng. Giá trị ngày nay rất có thể là 21, -128 tốt 65535. Chúng hồ hết khiến cho bạn có manh mối nhằm tìm ra lỗi, rộng được coi là dòng “Illegal value” ngắn gọn gàng.

mặc khi Steve McConnell thi thoảng cũng phá luật này trong cuốn nắn sách tuyệt vời nhất Code Complete. Chẳng hạn, trong cmùi hương 15, McConnell nêu ra tình huống vạc hiện một vẻ bên ngoài ký kết trường đoản cú không hề muốn, nhưng lại thông báo lỗi lại không hiển thị cam kết trường đoản cú đó.

do đó, mỗi một khi tra cứu với fix bug, bạn phải tự hỏi: liệu hoàn toàn có thể biến hóa điều gì trong code nhằm sau đây ko gặp nên hầu hết bug dạng này không? Liệu có giải pháp nào hoặc điều gì bản thân đề nghị có tác dụng, để sau đây tìm ra phần lớn bug dạng này thuận lợi rộng không?

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

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

Fix bug đem đến niềm vui cho cả chúng ta cùng khách hàng hàng

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

Bởi lẽ, để tạo ra một tính năng được cải thiện bắt buộc tốn khá nhiều thời gian, trong những khi bài toán fix một bug rất có thể chỉ việc một giờ đồng hồ đồng hồ thời trang. Mỗi bug được fix chấm dứt vẫn đưa về cảm giác sướng sẽ hoàn thành/đã có được điều gì. Và đó là 1 cảm giác giỏi vời!

Fix bug cũng mang lại nụ cười đến quý khách (dù nghe có vẻ oái oăm). Nếu ngay lập tức từ đầu không có bug, chưa phải fix bug, thì chẳng bắt buộc khách hàng đang vui hơn sao?. Nhưng, từ bỏ tay nghề rộng hai mươi năm thiết kế và “chiến đấu” cùng với bug, tôi dám khẳng định: người tiêu dùng đích thực bằng lòng mỗi một khi nhận về bug đã làm được fix xong xuôi nhanh chóng.

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

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

Niềm vui của câu hỏi giải câu đố


*

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

Thậm chí, gọi truyện trinh thám thịt người cũng mang về không hề ít hứng khởi: các bạn lần theo các dắt mối để tìm hiểu hầu như chuyện vẫn diễn ra ra sao.

Debug cùng fix bug cũng vậy. Mỗi bug là 1 trong những bí mật nên mày mò.

Thông thường, bội nghịch ứng đầu tiên của bạn lúc nhìn thấy một báo cáo 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ỏ kia, chúng ta bước đầu hành trình dài tò mò bí ẩn. Bạn lần theo các đầu mối. Logs nói gì? Có báo cáo lỗi làm sao tự hệ thống không? Tại thời điểm này, hệ thống bao gồm xẩy ra vấn đề gì không giống giỏi không? Gần phía trên có cái gì bị thay đổi ko – ứng dụng bắt đầu, thay đổi cấu hình, lưu lượng truy vấn ảnh hưởng?

Cách công dụng tốt nhất nhằm ghi lại bug là gì?

Lý bởi của bài toán rất cần được ghi lại bug là gì? Để bạn có thể học hỏi hiệu quả duy nhất từ bỏ đa số bug các bạn sẽ fix. Phương pháp cơ mà tôi sử dụng là luôn luôn dành ra vài phút ít nhằm ghi chụ lại những thông tin: bộc lộ bug, giải pháp fix, bài học tay nghề.

Nguim tắc

Chỉ ghi chụ phần đông bug nặng nề nhằn hoặc thực thụ thú vị. Đây không hẳn là bug tracker.Ghi chụ phần đa bug vì chưng bao gồm bản thân gây nên. (Trừ ngôi trường hòa hợp bug của bạn khác tuy vậy đầy đủ thụ vị).Ghi lại bug ngay lập tức sau thời điểm fix ngừng. Tránh ghi nhớ nhầm, nhớ ko cụ thể.

Cách đánh dấu bug

Tôi hay sử dụng size tiếp sau đây nhằm lưu lại bug dưới dạng file text (bugs.txt). Bạn có thể tìm hiểu thêm trải qua ví dụ sau:

tin tức nền:

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

Sửa: Nếu chiều lâu năm kiếm tìm thấy bởi 0, đặt nó lại bằng 1. bởi thế họ đã 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 tiếng.

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

Bài học: Đặt “ý thức lầm chỗ” vào tài liệu của biểu lộ gửi tới. Giá trị dữ liệu rất có thể quá to có tác dụng lịch trình chạy không đúng. Dường như Khi chiều dài bởi 0 cũng có thể là 1 trong dấu hiệu xấu.

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

Về coding


*

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

Trình từ bỏ sự kiện

Lúc xử lý sự khiếu nại, hầu như thắc mắc sau sẽ rất gồm ích:

Liệu sự kiện có thể mang lại theo biệt lập từ bỏ khác được không?Sẽ cầm cố làm sao nếu như không cảm nhận sự kiện này? Sẽ nạm như thế nào trường hợp sự kiện này ra mắt nhị lần liên tiếp?Thậm chí, ví như nó không khi nào xẩy ra, bugs sinh sống hầu như phần khác của hệ thống (hoặc của những hệ thống không giống có tương tác) vẫn có thể khiến cho nó xảy ra.Quá sớm

Cái này là 1 trong những trường phù hợp đặc biệt của phần “Trình từ sự kiện” nghỉ ngơi bên trên. Nhưng cũng chính vì nó gây ra một vài lỗi rất khó khăn tìm cho nên nó được đặt ra riêng biệt.

Chẳng hạn, nếu như biểu thị nhận được quá mau chóng, trước khi những quy trình tùy chỉnh thiết lập và khởi đụng hoàn toàn, tài năng công tác sẽ sở hữu được hồ hết thể hiện kỳ quái.

Một ví dụ khác: khi một kết nối được đánh dấu là down ngay cả trước lúc nó được gửi vào danh sách idle. khi bắt buộc search lỗi này, bọn họ luôn luôn khoác định rằng nó bị ghi lại down trong lúc đang làm việc vào danh sách idle (cơ mà thời gian kia vì sao nó ko được kéo ra khỏi danh sách?).

Đó là một trong sai trái trong dấn thức của họ lúc không xét đến trường hòa hợp bao gồm vật dụng xảy ra thừa sớm.

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

Một trong các phần đông lỗi cạnh tranh vạc hiện độc nhất vô nhị là khi bọn chúng âm thầm ra đi với chương trình thường xuyên được xúc tiến nhưng mà ko quăng ra exception làm sao.

Chẳng hạn nlỗi các lệnh hotline hệ thống (bind chẳng hạn) trả về mã lỗi tuy vậy ko được kiểm soát.

Hoặc như, phần code nhằm đối chiếu tín hiệu chỉ dễ dàng và đơn giản return Khi bắt gặp một yếu tắc chưa hợp lệ, trong những khi đáng lẽ phải quăng lỗi.

Cmùi hương trình thường xuyên chạy trong tâm trạng không nên, tạo cho debug càng nặng nề hơn. Nói chung tốt nhất là một trong lỗi đề nghị được quăng ra càng nhanh càng giỏi.

If

Lệnh if với tương đố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 thừa ttránh lỗi đến tôi.

Dù mang lại câu lệnh if về phương diện có mang thừa dễ dàng và đơn giản đi, chúng vẫn dễ bị không nên Khi có nhiều điều kiện kèm theo.

Bây tiếng tôi nỗ lực viết code dễ dàng và đơn giản rộng nhằm tách đề xuất giải pháp xử lý rất nhiều câu if tinh vi.

Else

Cũng bao gồm thừa ttránh lỗi là vì không xét cho ngôi trường vừa lòng bỏ qua lệnh else. Gần nhỏng tất cả ngôi trường phù hợp, luôn luôn nên tất cả một lệnh else cho từng câu if. Hơn nữa, nếu khách hàng đặt một đổi mới bên trong lệnh if, tài năng cao là chúng ta phải đặt nó sinh sống phần đông nơi khác nữa.

Xem thêm: Viên Đá Hiền Triết Học - Đá Hiền Triết:Dư Âm Đại Chiến Liverpool

Ttốt thay đổi các đưa định

Những lỗi khó khăn chống tách duy nhất vào quy trình tiến độ đầu hay là do đổi khác đưa định.

Chẳng hạn, lúc đầu có thể chỉ tất cả một sự khiếu nại customer từng ngày. Thế là không ít code được viết với trả định này. Một không bao lâu sau, xây đắp đổi khác có thể chấp nhận được các sự kiện customer diễn ra trong thời gian ngày. Khi cthị trấn này xảy ra, hoàn toàn có thể vô cùng cạnh tranh để đổi khác không còn tất cả ngôi trường phù hợp bị tác động vì xây dựng new.

Nói phổ biến không khó khăn nhằm search toàn bộ những phần phụ thuộc phân minh. Cái cạnh tranh là đưa ra hầu hết phần phụ thuộc tiềm tàng bên phía trong xây đắp cũ.

Chẳng hạn rất có thể có phần code thu thập tất cả sự khiếu nại của customers vào một ngày một mực. Một đưa định phân biệt rất có thể là kết quả trả về ko lúc nào to hơn con số customers.

Tôi không biết phương pháp nào xuất sắc để phòng ngừa gần như trường hòa hợp này, nếu như bạn làm sao biết thì lưu ý giúp tôi cùng với nhé.

Logging

Điều về tối đặc trưng là có nhận thức về hầu hết gì lịch trình vận động, đặc biệt quan trọng giữa những lịch trình tất cả lô ghích phức tạp.

Cần chắc hẳn rằng logging được đặt toàn vẹn với đúng địa điểm, nhằm bạn cũng có thể giải thích tại vì sao chương trình lại chạy điều đó.

lúc mọi vật dụng hoạt động trơn tru tru thì ko có gì, nhưng mà ngay trong lúc công tác xảy ra lỗi (cthị trấn cần yếu tách khỏi), ít ra bạn sẽ thấy hạnh phúc bởi vẫn logging đúng vị trí.

Về Testing


*

Có đầy đủ bug rõ ràng đề xuất được “khui” ra ngay vào quá trình demo. Nếu vậy, phần demo như thế nào vẫn thiếu thốn sót – unit, functional, tốt system? Test case nào đã biết thành thiếu?

0 cùng null

Luôn chắc chắn rằng soát sổ với giá trị 0 và null (nếu như có thể). Đối với chuỗi, đề xuất chú ý chuỗi trống rỗng, cùng chuỗi là null.

Một ví dụ khác: khám nghiệm ngôi trường hợp đứt kết nối TCPhường trước lúc bất cứ tài liệu (zero bytes) nào được gửi.

Bỏ qua Việc kiểm soát các trường đúng theo trên là nguyên nhân số một tạo cho bug lọt khỏi phần thử nghiệm của tôi.

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

Thường các tính năng được cải thiện vẫn bám cho tới chuyện thêm những cấu hình thiết lập bắt đầu vào hệ thống, chẳng hạn như một hình dáng định dạng bắt đầu số điện thoại cảm ứng thông minh.

Thường thì các bạn sẽ bình chọn coi hoàn toàn có thể thêm định hình mới hay không, cơ mà tôi thấy là rất dễ dàng quên kiểm soát ngôi trường hòa hợp xóa định dạng cũ.

Xử lý lỗi

Phần code dùng để làm xử lý lỗi hay cực kỳ nặng nề đánh giá. Tốt nhất là đề nghị tất cả những demo tự động hóa để soát sổ phần này, nhưng thỉnh thoảng câu hỏi này trlàm việc đề xuất bất khả.

Một mẹo tôi xuất xắc sử dụng là sửa code tạm thời nhằm kích hoạt phần cách xử trí lỗi. Dễ độc nhất vô nhị là lộn ngược ĐK if lại, chẳng hạn 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 không đúng thương hiệu một column trong database để 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 kiểm tra khác hoàn toàn có thể dùng làm phạt hiện tại bug là thực hiện tài liệu đầu 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 chuyển động bên trên tài liệu nhị phân. Bằng bí quyết gửi những bytes hốt nhiên nhằm giải mã, Cửa Hàng chúng tôi đã tìm thấy tương đối nhiều lỗi vào phần này.

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

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

Thường testing liên quan mang lại xem test hành động mong ước tất cả xẩy ra không. Nhưng lại rất đơn giản bỏ qua mất ngôi trường phù hợp ngược lại – đánh giá hành động không hề mong muốn thật sự ko diễn ra.

Tự có tác dụng tool

Tôi thường xuyên tự làm những tool nhỏ dại nhằm demo dễ rộng.

lấy một ví dụ, lúc Khi tôi thao tác làm việc với giao thức SIPhường mang đến VoIP, tôi viết một đoạn mã nhỏ dại hoàn toàn có thể trả lời với headers với quý giá tôi mong muốn. Đoạn mã này giúp tôi chất vấn đều trường thích hợp đặc biệt thuận lợi hơn.

Một ví dụ khác là 1 trong những chương trình dòng lệnh chuyên dùng làm điện thoại tư vấn API.

Bằng biện pháp bước đầu bé dại, với từ từ trở nên tân tiến thêm tài năng mang lại nó, ở đầu cuối tôi tất cả vào ni phần nhiều phương pháp rất bổ ích. Lợi ích của bài toán này là tôi bao gồm chế độ đúng như tôi ước muốn.

Về Debugging


*

Cách nkhô cứng rộng để “khui” bug là gì? Tôi đã sử dụng đúng tool chưa? Có yêu cầu tôi đã rộp đoán thù vượt nhiều? Tôi có cần logging xuất sắc rộng không?

Thảo luận

Nếu các bạn hỏi tôi bí quyết kết quả độc nhất vô nhị nhằm cách xử lý bug là gì? Tôi sẽ vấn đáp là bàn bạc cùng với người cùng cơ quan. Trong cơ hội tìm kiếm bí quyết lý giải mang đến họ hiểu vụ việc gặp mặt đề xuất là gì, tôi cũng đôi khi hiểu sâu cùng rõ rộng về nó.

Thêm nữa, mặc dù ko không còn xa lạ cùng với code trong thắc mắc, hay họ sẽ sở hữu cái nhìn rõ ràng nhằm đã cho thấy vấn đề hoàn toàn có thể phát sinh từ bỏ đâu.

Đây là phương pháp cực kỳ công dụng góp tôi giải quyết hầu như bug khó nhằn độc nhất vô nhị.

Cẩn thận mang lại từng tiểu tiết

Khi vấn đề debug ngốn không ít thời hạn, thì hay là do tôi đang suy đoán thù không đúng.

lấy ví dụ, tôi nghĩ về vụ việc xẩy ra tại 1 method như thế nào đó, trong lúc thực tế không lẽ nào chuyện đó xẩy ra.

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

Cho bắt buộc, hãy chắc chắn rằng các bạn vẫn chất vấn lại tất cả cụ thể gắng vị khoác định phần lớn thứ. Thật dễ dàng để xem số đông gì bạn muốn thấy, hơn là các thứ thật sự làm việc đó.

Ttuyệt thay đổi nhất

Lúc mọi thứ từng hoạt động đột nhiên trục sái, hay là do đầy đủ biến đổi mới nhất tạo ra.

Có trường vừa lòng, chúng ta chỉ thay đổi logging, tuy vậy một lỗi trong logging đã gây nên sự ráng lớn hơn những.

Để dễ truy tra cứu mọi sự ráng hình dạng này, chúng ta nên commit rất nhiều nuốm thay đổi nhau Một trong những commit không giống nhau, với ghi crúc cụ thể về Việc biến đổi.

Tin trên bạn dùng

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

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

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

Xem thêm: Mua Bán Xe Máy Honda Sh Độ 700 Triệu Đồng Tầm Sư Lên Đồ Kì Công Ra Sao?

Test phần vẫn sửa

Tuân theo đông đảo bước trên sẽ giúp chúng ta chắc chắn bug kia thực thụ là bug, với phần đã sửa đích thực công dụng. Đơn giản nhưng lại cần thiết.


*

Nếu bạn nghĩ về phần nhiều chia sẻ này hoàn toàn có thể mang lại lợi ích cho đồng đội hoặc người cùng cơ quan thì chớ hổ ngươi nhận nút ít Share dưới nhé!


Chuyên mục: Tin Tức