Làm thế nào để mã gỡ lỗi hiệu quả nhất? [đóng cửa]

Lỗi phát triển thành mã có thể được giảm thiểu, nhưng không được loại bỏ hoàn toàn như được viết - các lập trình viên, mặc dù nhiều người sẽ không đồng ý , chỉ có con người.

Khi chúng tôi phát hiện ra một lỗi trong mã của chúng tôi, chúng tôi có thể làm gì để loại bỏ nó? Làm thế nào chúng ta nên tiếp cận nó để sử dụng hiệu quả nhất thời gian quý báu của mình và cho phép chúng ta dành ít thời gian hơn để cố gắng tìm kiếm nó và nhiều thời gian hơn để mã hóa? Ngoài ra, những gì chúng ta nên tránh khi gỡ lỗi?

Lưu ý ở đây rằng chúng ta không nói về việc ngăn chặn lỗi; chúng ta đang nói về những việc cần làm khi lỗi làm xuất hiện. Đây là một lĩnh vực rộng, tôi biết, và có thể phụ thuộc nhiều vào ngôn ngữ, nền tảng và công cụ. Nếu vậy, hãy tiếp tục bao gồm các câu trả lời như tư duy và phương pháp chung.

Suy nghĩ và thái độ đối với việc gỡ lỗi có lẽ là phần quan trọng nhất, bởi vì nó quyết định mức độ hiệu quả của việc bạn sẽ sửa lỗi và bạn sẽ học được gì từ nó - nếu có bất cứ điều gì.

Kinh điển về phát triển phần mềm như Lập trình viên thực dụng và Mã hoàn chỉnh về cơ bản lập luận cho cùng một cách tiếp cận: mọi lỗi đều là cơ hội để học, hầu như luôn luôn là về bản thân bạn (vì chỉ người mới bắt đầu đổ lỗi cho trình biên dịch / máy tính trước).

Vì vậy, coi nó như một bí ẩn sẽ rất thú vị để crack. Và phá vỡ bí ẩn đó nên được thực hiện một cách có hệ thống, bằng cách bày tỏ các giả định của chúng tôi (cho chính chúng tôi hoặc cho người khác) và sau đó kiểm tra các giả định của chúng tôi, từng cái một nếu cần - sử dụng mọi công cụ theo ý của chúng tôi, đặc biệt là trình gỡ lỗi và khung kiểm tra tự động. Sau đó, sau khi bí ẩn được giải quyết, bạn có thể làm tốt hơn nữa bằng cách xem qua tất cả các mã của bạn cho các lỗi tương tự bạn có thể đã mắc phải; và viết một bài kiểm tra tự động để đảm bảo lỗi sẽ không xảy ra một lần nữa.

Một lưu ý cuối cùng - Tôi thích gọi lỗi là "lỗi" chứ không phải "lỗi" - Dijkstra đã nói với các đồng nghiệp của mình vì sử dụng thuật ngữ sau bởi vì nó không trung thực, ủng hộ ý tưởng rằng các nàng tiên lỗi và hay thay đổi đã gieo rắc lỗi trong các chương trình của chúng tôi trong khi chúng tôi không Tìm kiếm, thay vì ở đó vì suy nghĩ (cẩu thả) của chúng ta: http://www.cs.utexas.edu/users/EWD/transcrip/EWD10xx/EWD1036.html

Ví dụ, chúng ta có thể bắt đầu với việc dọn dẹp ngôn ngữ của mình bằng cách không còn gọi lỗi là lỗi mà bằng cách gọi đó là lỗi. Nó trung thực hơn nhiều vì nó thẳng thắn đổ lỗi cho nơi nó thuộc về, viz. với các lập trình viên đã làm cho lỗi. Phép ẩn dụ hoạt hình của con bọ đã lén lút xâm nhập trong khi lập trình viên không tìm kiếm là không trung thực về mặt trí tuệ vì nó ngụy trang rằng lỗi là do chính lập trình viên tạo ra. Điều hay ho của sự thay đổi từ vựng đơn giản này là nó có tác dụng sâu sắc như vậy: trong khi, trước đó, một chương trình chỉ có một lỗi được sử dụng là "gần như đúng", sau đó một chương trình có lỗi chỉ là "sai" (vì trong lỗi).

1. Viết bài kiểm tra. Kiểm tra không chỉ tuyệt vời trong việc ngăn chặn lỗi (theo kinh nghiệm của tôi, TDD đã thực hiện đúng giúp loại bỏ gần như tất cả các lỗi tầm thường, ngu ngốc), mà còn giúp ích rất nhiều trong việc gỡ lỗi. Kiểm tra buộc thiết kế của bạn phải khá mô-đun, điều này làm cho việc cách ly và sao chép vấn đề dễ dàng hơn rất nhiều. Ngoài ra, bạn kiểm soát môi trường, do đó sẽ có rất ít bất ngờ. Hơn nữa, một khi bạn gặp trường hợp thử nghiệm thất bại, bạn có thể chắc chắn chắc chắn rằng bạn đã đóng đinh lý do thực sự của hành vi đang làm phiền bạn.

2. Tìm hiểu làm thế nào để sử dụng một trình gỡ lỗi. printcác câu lệnh có thể hoạt động hợp lý ở một mức độ nào đó, nhưng phần lớn trình gỡ lỗi hầu hết thời gian là rất hữu ích (và một khi bạn biết cách sử dụng nó, nó sẽ thoải mái hơn rất nhiều so với các printcâu lệnh).

3. Nói về ai đó về vấn đề của bạn, ngay cả khi đó chỉ là một con vịt cao su . Buộc bản thân phải thể hiện vấn đề mà bạn đang giải quyết bằng lời nói thực sự làm nên điều kỳ diệu.

4. Cho mình một giới hạn thời gian. Nếu ví dụ sau 45 phút bạn cảm thấy mình không đi đến đâu, chỉ cần chuyển sang các nhiệm vụ khác một thời gian. Khi bạn quay lại lỗi của mình, hy vọng bạn sẽ có thể thấy các giải pháp khả thi khác mà trước đây bạn chưa từng xem xét.

Tôi nghĩ rằng sự sinh sản của một lỗi cũng rất quan trọng. Tất cả các trường hợp tái tạo lỗi có thể được liệt kê và sau đó bạn có thể đảm bảo rằng bản sửa lỗi của bạn bao gồm tất cả các trường hợp đó.

Có một cuốn sách tuyệt vời mà tôi đã đọc về chủ đề này có tên là Why Programs Fail , trong đó nêu ra các chiến lược khác nhau để tìm ra các lỗi khác nhau, từ việc áp dụng phương pháp khoa học để cô lập và giải quyết lỗi, đến gỡ lỗi delta. Phần thú vị khác của cuốn sách này là nó không có thuật ngữ 'lỗi'. Cách tiếp cận của Zeller là:

(1) Một lập trình viên tạo ra một khiếm khuyết trong mã. (2) Khiếm khuyết gây nhiễm trùng (3) Nhiễm trùng lan truyền (4) Nhiễm trùng gây ra thất bại.

Nếu bạn muốn cải thiện kỹ năng sửa lỗi của mình, tôi đánh giá cao cuốn sách này.

Theo kinh nghiệm cá nhân của riêng tôi, tôi đã tìm thấy rất nhiều lỗi trong ứng dụng của mình, nhưng quản lý chỉ cần nhấn chúng tôi trở đi để có được các tính năng mới. Tôi thường xuyên nghe thấy "Chúng tôi đã tìm thấy lỗi này và khách hàng chưa nhận thấy nó, vì vậy hãy để nó cho đến khi họ làm điều đó". Tôi nghĩ rằng việc phản ứng ngược lại với sự chủ động trong việc sửa lỗi là một ý tưởng rất tồi vì khi đến lúc thực sự khắc phục, bạn đã gặp phải các vấn đề khác cần giải quyết và nhiều tính năng quản lý muốn ra khỏi cửa càng sớm càng tốt, vì vậy bạn bị bắt trong một vòng luẩn quẩn có thể dẫn đến rất nhiều căng thẳng và kiệt sức và cuối cùng, một hệ thống cưỡi khiếm khuyết.

Truyền thông cũng là một yếu tố khác khi tìm thấy lỗi. Gửi email hoặc gửi tài liệu về trình theo dõi lỗi đều tốt và tốt, nhưng theo kinh nghiệm của riêng tôi, các nhà phát triển khác tìm thấy một lỗi tương tự và thay vì sử dụng lại giải pháp bạn đưa ra để sửa mã (vì họ đã quên tất cả về nó ), họ thêm các phiên bản của riêng họ, do đó, bạn đã có 5 giải pháp khác nhau trong mã của mình và kết quả là nó trông khó hiểu và khó hiểu hơn. Vì vậy, khi bạn sửa lỗi, hãy đảm bảo một vài người xem xét sửa lỗi và cung cấp cho bạn thông tin phản hồi trong trường hợp họ đã sửa một cái gì đó tương tự và tìm ra một chiến lược tốt để xử lý nó.

Limist đã đề cập đến cuốn sách, Lập trình viên thực dụng có một số tài liệu thú vị về sửa lỗi. Sử dụng ví dụ tôi đã đưa ra trong đoạn trước, tôi sẽ xem xét điều này: Entrophy phần mềm , trong đó sử dụng phép tương tự của một góa phụ bị hỏng. Nếu hai cửa sổ bị vỡ xuất hiện, nhóm của bạn có thể trở nên thờ ơ với việc sửa nó trừ khi bạn có lập trường chủ động.

Lỗi, lỗi, sự cố, lỗi - bất cứ điều gì bạn muốn gọi nó, nó không tạo ra nhiều khác biệt. Tôi sẽ dính vào vấn đề vì đó là những gì tôi đã từng.

1. Tìm hiểu nhận thức của vấn đề là gì: dịch từ khách hàng 'Bob vẫn chưa có trong hệ thống' sang 'Khi tôi cố gắng tạo hồ sơ người dùng cho Bob, nó đã thất bại với ngoại lệ khóa trùng lặp, mặc dù Bob chưa trong đó'
2. Tìm hiểu xem đó có thực sự là một vấn đề hay chỉ là một sự hiểu lầm (thực sự, Bob không ở đó, không có ai gọi là bob và insert nên hoạt động).
3. Cố gắng thực hiện các bước đáng tin cậy tối thiểu mà bạn có thể thực hiện để tái tạo vấn đề - đại loại như 'Đưa ra một hệ thống có hồ sơ người dùng' Bruce ', khi bản ghi người dùng' Bob 'được chèn, sau đó xảy ra ngoại lệ'
4. Đây là thử nghiệm của bạn - nếu có thể, hãy đặt nó vào một khai thác thử nghiệm tự động mà bạn có thể chạy đi chạy lại, đây sẽ là vô giá khi gỡ lỗi. Bạn cũng có thể biến nó thành một phần của bộ thử nghiệm của mình để đảm bảo rằng vấn đề cụ thể đó không xuất hiện lại sau này.
5. Đưa trình gỡ lỗi của bạn ra và bắt đầu đặt các điểm dừng - tìm ra đường dẫn mã khi bạn chạy thử nghiệm và xác định những gì sai. Trong khi bạn làm điều đó, bạn cũng có thể tinh chỉnh thử nghiệm của mình bằng cách làm cho nó hẹp nhất có thể - lý tưởng là thử nghiệm đơn vị.
6. Khắc phục sự cố - xác minh vượt qua bài kiểm tra của bạn.
7. Xác minh sự cố ban đầu như được mô tả bởi khách hàng cũng đã được sửa (rất quan trọng - bạn có thể đã sửa một tập hợp con của vấn đề). Xác minh bạn đã không giới thiệu hồi quy trong các khía cạnh khác của chương trình.

Nếu bạn rất quen thuộc với mã hoặc nếu sự cố hoặc cách khắc phục là rõ ràng, bạn có thể bỏ qua một số bước đó.

Làm thế nào chúng ta nên tiếp cận nó để sử dụng hiệu quả nhất thời gian quý báu của mình và cho phép chúng ta dành ít thời gian hơn để cố gắng tìm kiếm nó và nhiều thời gian hơn để mã hóa?

Tôi có vấn đề với điều đó, vì nó ngụ ý rằng việc viết mã mới có giá trị hơn là có một chương trình làm việc chất lượng cao. Không có gì sai khi có hiệu quả nhất có thể trong việc khắc phục sự cố, nhưng một chương trình không nhất thiết trở nên tốt hơn bằng cách chỉ cần thêm mã vào nó.

Tôi thích hầu hết các câu trả lời khác, nhưng đây là một số lời khuyên về những việc cần làm TRƯỚC KHI bạn làm bất cứ điều gì trong số đó. Sẽ giúp bạn tiết kiệm thời gian beaucoup de.

1. Xác định nếu thực sự có một lỗi. Một lỗi là LUÔN LUÔN một sự khác biệt giữa hành vi và yêu cầu hệ thống; người kiểm tra phải có thể nói rõ hành vi dự kiến ​​và thực tế. Nếu anh ta không thể cung cấp hỗ trợ cho hành vi dự kiến, không có yêu cầu và không có lỗi - chỉ là ý kiến ​​của ai đó. Gửi trở lại.

2. Xem xét khả năng hành vi dự kiến ​​là sai. Điều này có thể là do giải thích sai về yêu cầu. Nó cũng có thể là do khiếm khuyết trong chính yêu cầu (đồng bằng giữa yêu cầu chi tiết và yêu cầu kinh doanh). Bạn có thể gửi lại những điều này quá.

3. Cô lập vấn đề. Chỉ có kinh nghiệm mới dạy bạn cách nhanh nhất để làm điều này-- một số người gần như có thể làm điều đó với ruột của họ. Một cách tiếp cận cơ bản là thay đổi một điều trong khi giữ cho tất cả những thứ khác không đổi (vấn đề có xảy ra ở các môi trường khác không? Với các trình duyệt khác? Ở một khu vực thử nghiệm khác? Vào các thời điểm khác nhau trong ngày?) Một cách tiếp cận khác là xem xét các bãi rác ngăn xếp hoặc thông báo lỗi-- đôi khi bạn có thể biết chỉ bằng cách nó được định dạng thành phần nào của hệ thống đã gây ra lỗi ban đầu (ví dụ: nếu bằng tiếng Đức, bạn có thể đổ lỗi cho bên thứ ba mà bạn làm việc ở Berlin).

4. Nếu bạn đã thu hẹp nó xuống hai hệ thống cộng tác, hãy kiểm tra tin nhắn giữa hai hệ thống thông qua trình giám sát lưu lượng hoặc tệp nhật ký và xác định hệ thống nào đang hoạt động với thông số kỹ thuật và hệ thống nào không. Nếu có nhiều hơn hai hệ thống trong kịch bản, bạn có thể thực hiện kiểm tra theo cặp và làm việc theo cách của bạn "xuống" ngăn xếp ứng dụng.

5. Lý do tại sao cách ly vấn đề rất nghiêm trọng là vì vấn đề có thể không phải do lỗi mã mà bạn có quyền kiểm soát (ví dụ: hệ thống của bên thứ ba hoặc môi trường) và bạn muốn khiến bên đó tiếp quản càng nhanh càng tốt . Điều này vừa giúp bạn tiết kiệm công việc vừa giúp họ đạt điểm ngay lập tức để có thể đạt được độ phân giải trong khung thời gian ngắn nhất có thể. Bạn không muốn làm việc với một vấn đề trong mười ngày chỉ để thấy nó thực sự là một vấn đề với dịch vụ web của người khác.

6. Nếu bạn đã xác định rằng thực sự có một khiếm khuyết và nó thực sự nằm trong mã mà bạn kiểm soát, bạn có thể cách ly vấn đề bằng cách tìm kiếm bản ghi "kiểm tra nguồn gốc" đã biết và kiểm tra các thay đổi có thể gây ra sự cố. Điều này có thể tiết kiệm rất nhiều thời gian.

7. Nếu bạn không thể tìm ra nó từ kiểm soát nguồn, bây giờ là thời gian để đính kèm trình gỡ lỗi của bạn và bước qua mã để tìm ra nó. Rất có thể bây giờ bạn có một ý tưởng khá tốt về vấn đề này.

Khi bạn biết lỗi ở đâu và có thể nghĩ ra cách khắc phục, đây là một quy trình tốt để sửa lỗi:

1. Viết một bài kiểm tra đơn vị tái tạo vấn đề và thất bại.

2. Không sửa đổi bài kiểm tra đơn vị, làm cho nó vượt qua (bằng cách sửa đổi mã ứng dụng).

3. Giữ bài kiểm tra đơn vị trong bộ kiểm tra của bạn để ngăn chặn / phát hiện hồi quy.

Đây là cách tôi làm điều đó:

1. sử dụng cùng một phương pháp mỗi lần để tìm ra vấn đề. Điều này sẽ cải thiện thời gian phản ứng của bạn với các lỗi.
2. Cách tốt nhất có lẽ là đọc mã. Điều này là do tất cả các thông tin có sẵn trong mã. Bạn chỉ cần những cách hiệu quả để tìm vị trí chính xác và khả năng hiểu tất cả các chi tiết.
3. gỡ lỗi là cách rất chậm và chỉ cần thiết nếu lập trình viên của bạn chưa hiểu cách máy tính thực thi các hướng dẫn asm / không thể hiểu ngăn xếp cuộc gọi và nội dung cơ bản
4. Cố gắng phát triển các kỹ thuật bằng chứng như sử dụng các nguyên mẫu hàm để suy luận về hành vi của chương trình. Điều này sẽ giúp tìm vị trí chính xác nhanh hơn

Khi chúng tôi phát hiện ra một lỗi trong mã của chúng tôi, chúng tôi có thể làm gì để loại bỏ nó? Làm thế nào chúng ta nên tiếp cận nó để sử dụng hiệu quả nhất thời gian quý báu của mình và cho phép chúng ta dành ít thời gian hơn để cố gắng tìm kiếm nó và nhiều thời gian hơn để mã hóa? Ngoài ra, những gì chúng ta nên tránh khi gỡ lỗi?

Giả sử rằng bạn đang ở trong một môi trường sản xuất, đây là những gì bạn cần làm:

1. Mô tả "lỗi" chính xác và xác định các sự kiện gây ra nó.

2. Xác định xem "lỗi" là lỗi mã hay lỗi đặc tả. Ví dụ: nhập tên 1 chữ cái có thể được coi là lỗi đối với một số hệ thống nhưng hành vi có thể chấp nhận được đối với các hệ thống khác. Đôi khi, người dùng sẽ báo cáo lỗi mà họ cho là có vấn đề nhưng sự mong đợi của người dùng đối với hành vi của hệ thống không phải là một phần của yêu cầu.

3. Nếu bạn đã chứng minh rằng có lỗi và lỗi là do mã, thì bạn có thể xác định những đoạn mã nào cần được sửa để ngăn lỗi. Đồng thời kiểm tra ảnh hưởng của hành vi đối với dữ liệu hiện tại và hoạt động của hệ thống trong tương lai (phân tích tác động lên mã và dữ liệu).

4. Tại thời điểm này, bạn có thể có một ước tính về số lượng tài nguyên sẽ được tiêu thụ để sửa lỗi. Bạn có thể sửa nó ngay lập tức hoặc lên lịch sửa lỗi trong phiên bản phát hành phần mềm sắp tới. Điều này cũng phụ thuộc vào việc người dùng cuối có sẵn sàng trả tiền cho việc sửa chữa hay không. Bạn cũng nên đánh giá các tùy chọn có sẵn khác nhau để sửa lỗi. Có thể có nhiều hơn một cách. Bạn cần chọn cách tiếp cận phù hợp nhất với tình huống.

5. Phân tích các lý do khiến lỗi này xuất hiện (yêu cầu, mã hóa, thử nghiệm, v.v.). Thực thi các quy trình sẽ ngăn điều kiện xảy ra lần nữa.

6. Tài liệu các tập đầy đủ.

7. Phát hành bản sửa lỗi (hoặc phiên bản mới)