2009-05-27 41 views
6

Bạn có bao giờ gặp phải một lỗi mà bạn vừa mới hết ý tưởng và không biết phải thử làm gì tiếp theo không, và bạn có thực sự bực mình không? Có ý tưởng chung nào về cách thoát khỏi chế độ này không?khối của trình gỡ lỗi

Trả lời

11

Khi tôi bị chặn như vậy, lời khuyên tốt nhất mà tôi đã tìm thấy là để lại một lúc. Cho dù đó là cho một bữa ăn trưa dài hoặc để lại cho ngày. Hãy trở lại tươi mới và có một cái nhìn mới. Hầu hết thời gian câu trả lời sẽ được nhìn chằm chằm vào mặt bạn. Cho đến giờ nghỉ giải lao 10 phút vẫn chưa đủ cho tôi, nhưng số dặm của bạn có thể thay đổi.

Thứ hai, trao đổi với đồng nghiệp của bạn. Đi qua tất cả mọi thứ bạn đã thử. Chỉ yêu cầu họ lắng nghe, và trong khi bạn đang nói chuyện qua, rất nhiều lần, câu trả lời sẽ đến với bạn.

Đó chỉ là hai mà tôi sử dụng thường xuyên nhất khi tôi gỡ lỗi bị chặn.

+0

Có..hãy cố gắng giải thích vấn đề cho một người ngang hàng chắc chắn sẽ giúp đào tạo suy nghĩ theo đúng thứ tự. – Naveen

+0

http://c2.com/cgi/wiki?RubberDucking – JesperE

+0

Một vài tuần lễ nên được tốt cho tôi :) – leppie

3

Tôi thường nghỉ ngơi ... nếu điều đó không hiệu quả, tôi sẽ giải quyết vấn đề. (Thực ra, thành thật mà nói, tôi nên nói rằng tôi đã trải qua một đêm không ngủ để suy nghĩ về vấn đề này).

Tôi hầu như luôn có danh sách các giải pháp có thể sẵn sàng vào buổi sáng. :-)

2

Tôi thường mất một vài bước sau:

  • nhìn vào mã mà có liên quan đến các chức năng mà có lỗi và địa điểm thông điệp logger trong một cách mà họ sẽ giúp tôi thu hẹp vấn đề (điều này cho phép bạn nhìn vào nhật ký sau này khi bạn không còn khó chịu nữa, và có thể tìm thấy gợi ý hữu ích: P)
  • yêu cầu đại lý cao cấp của tôi gợi ý
  • gọi cho khách hàng để có một sự hiểu biết rõ ràng về thời điểm vấn đề phát sinh
1

Tôi thường kết thúc trong tâm trạng đó khi tôi không có cách tiếp cận cấu trúc từ đầu. Bằng cách lặp lại thu hẹp khu vực nơi sự cố có thể phát sinh và cố gắng viết cơ sở mã nhỏ nhất có thể tạo lại lỗi, tôi chưa thất bại.

0

Tôi nghĩ rằng nếu bạn chạy vào đó loại vấn đề đó là thời gian để làm một số refactoring nghiêm trọng ...

Ngoài ra nó có thể chỉ ra những giả định sai. Cố gắng giả sử tất cả những gì bạn đang 'giả định'. Xem nó không có phương pháp bất biến được phá vỡ của bất kỳ phương pháp có trong ngăn xếp.

0

Những người khác đã đề cập đến việc nghỉ ngơi hoặc "ngủ trên đó". Kỹ thuật này được gọi là (trong số những thứ khác) Ủ bệnh. Một khi bạn nắm lấy ý tưởng bạn cũng có thể tiếp tục.

Một khía cạnh quan trọng là thực sự để lại vấn đề phía sau, tự tin rằng bạn sẽ có câu trả lời sau. Cách khác nguy hiểm, đặc biệt là nếu ngủ trên đó, là bạn sẽ lo lắng về nó đến phút cuối cùng, thế thì điều này trở thành một chu kỳ bất tận mà tâm trí của bạn bị kẹt trong đêm. Có thể bạn sẽ thức dậy và không nghỉ ngơi quá lâu khi mơ ước nhiều giấc mơ tròn. Làm điều này quá nhiều và đó là một con đường để trầm cảm.

5
  • Năm phút nghỉ

Hoàn toàn quan trọng, kẻo bạn đập bàn phím của bạn.

  • Giải thích vấn đề trong một email cho chị bạn

Hoặc con trai tuổi hai năm của mình. Ai đó wouldn't understand a word * trừ khi bạn giải thích rõ ràng. Bạn không cần phải gửi email, bạn chỉ cần chắc chắn rằng bạn hiểu nó trong ra ngoài. Bạn ngạc nhiên về việc bao nhiêu lần chỉ đơn giản là nghỉ ngơi vấn đề đột nhiên làm cho nó rõ ràng cho bạn, nơi bạn đã đi sai. Đây là một cách hay để khám phá những giả định của bạn về vấn đề này và cách chúng có thể không nhất thiết phải đúng.

* Liên kết đó là một câu trả lời tuyệt vời của JaredPar trên một câu hỏi SO khác.

  • Nói chuyện với một đồng nghiệp

Đến thời điểm này bạn đã 'gửi qua email' những con vật cưng trong gia đình, vì vậy bạn biết rằng bạn đã hy vọng bao gồm tất cả các khía cạnh ngu ngốc, đó là thời gian để nói chuyện cho một người thực sự. Họ có thể đã trải qua một số điều mơ hồ trong quá khứ nhắc nhở họ về tình trạng này, và họ chắc chắn sẽ có một quan điểm khác. Hãy cố gắng đảm bảo bạn hiểu rõ vấn đề là gì, chứ không phải những gì bạn nghĩ rằng. Bạn không muốn thiên vị họ. Bạn có thể và nên nói về những gì họ đã thử và giải thích lý do tại sao bạn nghĩ rằng vấn đề nằm trong khu vực đó (có thể bạn đã đúng) nhưng bạn không muốn đóng tâm trí của mình theo đề xuất của họ, ngay cả khi họ không có vẻ đúng.

  • Nhìn vào mã một lần nữa

Đến thời điểm này, bạn hy vọng sẽ được ít bạo lực, và bạn nên được trang bị những ý tưởng mới. Bắt đầu bằng cách xác minh lại lỗi. Một bước đơn giản, nhưng tôi đã thất vọng hàng giờ trên một lỗi trong tập lệnh thử nghiệm của chúng tôi chứ không phải trong mã của chúng tôi. Khi bạn đã xác minh lại lỗi, hãy bắt đầu ở trên cùng. Xác minh mọi thứ. Đặt điểm ngắt ở điểm cuối cùng bạn tự tin 100%, và sau đó làm việc theo cách của bạn về phía trước cho đến khi bạn thấy rằng đầu ra bị hỏng một lần nữa. Đó là một thành công lớn bởi vì bây giờ bạn có một khối mã nhỏ hơn hy vọng để điều tra. Sau đó, nếu cần, hãy kéo đồng nghiệp để xem mã chạy thực tế.

0

Một lựa chọn tốt khác là trả lại ý tưởng cho các nhà phát triển/thành viên khác trong nhóm. Đôi khi họ sẽ hỏi bạn những câu hỏi mà bạn chưa từng cân nhắc.

Nếu bạn làm việc một mình, bạn nên có một vài nhà phát triển đồng nghiệp mà bạn có thể trò chuyện để khắc phục sự cố với một số cách tiếp cận khác nhau. Bạn sẽ ngạc nhiên về mức độ quan điểm mới mẻ có thể là bước đột phá bạn cần.

0

Hãy thử David Ungars "Shower Phương pháp":

"Nếu bạn biết những gì để gõ, gõ Nếu bạn không biết những gì để gõ, đi tắm và đứng dưới vòi sen cho đến khi bạn biết những gì để gõ. "

Loại triệu tập này lên những gì phần lớn muốn làm. Nghỉ ngơi một lát ! Không có vấn đề gì loại phá vỡ nó là, miễn là bạn không nghĩ về những điều bạn đã làm trước giờ nghỉ. Phân tâm dưới mọi hình thức đều tốt.

Chúc mừng!

0

Tôi thường chạy khô thông qua phương pháp/chức năng vi phạm, từng bước.Và đừng cho rằng lỗi đang đến từ đó, nó có thể đến từ bất cứ đâu trước đó.

Sử dụng trình sửa lỗi thích hợp, không sử dụng một loạt printfs.

Các vấn đề liên quan