Phải làm gì khi bạn đã sử dụng hết tất cả các con đường để sửa lỗi

Tôi là một lập trình viên trẻ (4 tháng kinh nghiệm nghề nghiệp cho đến nay) làm việc trên Ứng dụng di động đa nền tảng (nhóm 1 người - vì vậy chỉ có bản thân tôi).

Tôi có một lỗi trong chương trình / ứng dụng này khá lớn (30 tệp tiêu đề khác nhau, mỗi tệp cũng có tệp cpp riêng). Tôi đã cố gắng theo dõi chính xác những gì đang xảy ra với lỗi và cũng để khắc phục nó (thậm chí đã cố gắng sử dụng một số bản hack để nó hoạt động) nhưng khoảng một tá giải pháp trở lên (ý tưởng tôi có về những gì gây ra sự cố ) Tôi đã không đưa ra được gì khiến tôi phải theo dõi chính xác lỗi là gì hoặc đã sửa lỗi.

Bạn có lời khuyên nào cho một lập trình viên cơ sở về một số kỹ thuật rộng rãi (hãy chạy, in tất cả mã của tôi lên giấy và xem qua nó bằng bút, v.v.) Tôi có thể sử dụng để hỗ trợ tôi với lỗi này không?

Để cung cấp thêm một chút bối cảnh cho lỗi của tôi; Nó liên quan đến API Mosync đa nền tảng, khi tôi thực hiện một chuỗi hành động cụ thể, màn hình hiện tại không vẽ lại (& nó xuất hiện) rằng màn hình được hiển thị trước đó vẫn nhận được các sự kiện nhấn con trỏ / phím & không phải màn hình hiện tại.

Trình tự cụ thể:
- Màn hình menu được hiển thị - nhấp vào "Hiển thị nút đơn đặt hàng trước"
- Màn hình đặt hàng trước được hiển thị - nhấp vào "Tải tệp" sau đó nhấp vào nút menu và mở Màn hình
phân phối - Màn hình phân phối được hiển thị - nhấp vào nút menu & mở Màn hình
mua hàng - Lỗi ở đây, đầu vào màn hình này không được hiển thị / phản ứng, ListViews không cuộn, các nút không phản ứng với các nhấp chuột, các ô ListView không phản hồi với các nhấp chuột

Ngoài ra, tôi rất thích có một cặp mắt khác nhìn vào công việc của mình và chỉ ra lỗi, nhưng như tôi đã nói tôi là đội 1, ông chủ của tôi chỉ đạo tôi, anh ta sở hữu công ty và có ý tưởng cho một ứng dụng nhưng không biết c ++ hoặc bất kỳ ngôn ngữ gần đây nào (cobal? Tôi nghĩ là tất cả). Bạn có lời khuyên nào về cách có được một đôi mắt thứ hai mà không vi phạm / khoe mã / tài sản trí tuệ của công ty không?

... và không được nghỉ thực tập có lương này không phải là một lựa chọn, hợp đồng nói rằng nếu tôi rời đi trước 6 triệu trong hợp đồng 12 triệu, tôi có thể phải trả 30% tiền lương hàng năm của mình

Nếu bạn có thể tái tạo vấn đề 100% thời gian, hãy đặt điểm dừng ở bước cuối cùng (càng sớm càng tốt). Nếu bạn đi qua toàn bộ ngăn xếp cuộc gọi, tôi chắc chắn rằng bạn sẽ tìm ra một số giá trị bất ngờ ở đâu đó hoặc một cái gì đó nên được gọi nhưng không được.

Biên tập:

Và nếu bạn đang ngồi cuối cùng, cố gắng sửa lỗi và đăng lên đây với hy vọng rằng bạn sẽ nhận được một số lời khuyên sáng, hãy bỏ đi . Xóa đầu của bạn và quay lại sau (tốt nhất là vào ngày mai hoặc sau cuối tuần). Đã có nhiều thời gian tôi dành cả ngày để tìm kiếm giải pháp cho một vấn đề cụ thể chỉ để bỏ đi, quay lại vào ngày hôm sau với một cái đầu sáng suốt và tìm thấy nó trong vòng mười phút.

Gỡ lỗi liên quan nhiều hơn đến việc cô lập và hiểu chính xác vấn đề là gì (so với việc áp dụng sửa lỗi)

Một điều cần cẩn thận khi gỡ lỗi là nếu bạn bắt đầu thấy rằng bạn đang nhảy theo các lý thuyết khác nhau vì điều này thường thực sự mất nhiều thời gian hơn và không loại bỏ một cách có hệ thống các vấn đề có thể xảy ra.

Thông thường cách tốt nhất để gỡ lỗi các loại tình huống này là cách tiếp cận có hệ thống nhàm chán bằng cách chia hệ thống của bạn thành từng mảnh nhỏ và làm cho mỗi phần hoạt động một cách cô lập và tiếp tục thêm từng yếu tố phức tạp cho đến khi nó bị hỏng. Sau đó, bạn đã cô lập vấn đề chính xác. Cách này có vẻ hơi tẻ nhạt và một số công việc tiên tiến hơn nhưng nó loại bỏ các biến và giữ cho bộ não của bạn lành mạnh trong khi cố gắng gỡ lỗi một phần mềm phức tạp.

Đây chỉ là một số điều tôi đã làm trong quá khứ, rõ ràng chúng sẽ không hoạt động trong mọi tình huống:

1. Nhận ra rằng đó chỉ là mã và ở đâu đó có lỗi (đó không chỉ là ma thuật đen) mà bạn CÓ THỂ sửa.
2. Nghỉ ngơi một lát.
3. Bước qua mã rất chậm, phân tích từng bước và đảm bảo bạn hiểu nó và những gì nó đang làm, không che đậy bất cứ điều gì.
4. Có được một đôi mắt thứ hai để xem xét vấn đề.
5. Đi ngủ và quên nó cho đến ngày mai (xóa đầu của bạn), đi kèm với một viễn cảnh tươi mới).
6. In mã của bạn và phân tích từng dòng, ghi chú bên lề, hiểu mọi hàm ý của mỗi dòng
7. Nếu đó không phải là một lỗi nghiêm trọng, nhưng gây ra lỗi mà người dùng không cần biết, tôi đã (xấu hổ, nhưng thành thật) đã bẫy lỗi đó và nuốt nó! Nếu nó không nguy hiểm và bạn không thể tìm ra nguyên nhân, đôi khi bạn chỉ cần bẫy và không cho người dùng biết bất cứ điều gì đã xảy ra. Đó là tất cả về ROI cho khách hàng, và đôi khi nó không xứng đáng.
8. Nói với con bọ bằng lời nói rằng bạn sẽ săn lùng nó và tiêu diệt nó. Đôi khi nó sẽ chạy trốn. :-)

Tôi thường có cách tiếp cận này khi giải quyết lỗi.

1. Tạo một bước tốt đẹp để tái tạo lỗi
2. Đơn giản hóa từng bước
3. Lỗi xảy ra ở đâu trong mã? Giống như những chức năng có liên quan?
4. Mã chọn đường dẫn nào khi xảy ra lỗi, callchain.
5. Tập trung vào vị trí, khi nào thì ổn. Sau đó lặp lại điều này rất nhiều cho đến khi bạn tìm thấy chính xác vị trí xảy ra lỗi.
6. Lý do tại sao điều này xảy ra?

Tại thời điểm này thường rõ ràng những gì đã xảy ra vì tôi học được rất nhiều trong quá trình tập trung vào vấn đề để tôi biết phải làm gì. Hoặc tôi có một câu hỏi khá tập trung mà tôi có thể hỏi trong một diễn đàn.

Sau đó, tôi cố gắng khắc phục sự cố và sử dụng từng bước bạn đã tạo ở bước một để xác minh xem lỗi đã được khắc phục chưa.

Tất cả các lời khuyên trước đây đều tuyệt vời và phần lớn nhằm mục đích xác minh các giả định về lỗi / lỗi và sau đó theo quy trình gỡ lỗi để xác định lỗi (đôi khi bằng cách kiểm tra môi trường xung quanh lỗi và đôi khi trực tiếp trong mã).

Cách tiếp cận này sẽ không luôn luôn hiệu quả, bất kể phụ thuộc vào thâm niên hoặc chuyên môn của bạn. Đôi khi bạn chỉ cần một đôi mắt khác về vấn đề. Tìm ai đó để xem xét vấn đề hoặc gỡ lỗi phiên với bạn - thường chỉ nói qua mã sẽ dẫn bạn đến lỗi.

Như những người khác đã nói 1) có thể tái tạo nó một cách đáng tin cậy và 2) bước về phía trước trong một trình gỡ lỗi cho đến khi nó xảy ra.

Nếu tôi không thể làm điều đó, vì bất kỳ lý do gì, tôi có hai phương thức khác mà cả hai đều yêu cầu phải có một phiên bản mã khác không thể hiện lỗi.

1. Chạy cả hai phiên bản của mã bên cạnh trình gỡ lỗi. Bước theo họ cho đến khi người xấu làm điều gì đó khác với người tốt.

2. Thay thế chạy các phiên bản tốt và xấu của mã. Có một khác biệt hoặc một số danh sách khác về sự khác biệt giữa các phiên bản. Sau đó tăng dần mã của một trong hai phiên bản để làm cho nó phù hợp hơn với phiên bản khác. Nếu cái xấu trở nên tốt, hay cái tốt trở thành xấu, tôi lùi lại thay đổi và thực hiện một thay đổi nhỏ hơn. Theo cách này tôi về nhà trên lỗi. Tôi nghĩ về nó như là "giải quyết cả hai mặt của vấn đề và làm việc hướng về trung tâm". Phương pháp này không yêu cầu trình gỡ lỗi.

Nếu vấn đề là khó có thể tái sản xuất, sau đó tôi cần càng nhiều thông tin như tôi có thể nhận được, chẳng hạn như một chồng đổ, khi nó không xảy ra. Vì vậy, tôi chắc chắn rằng tôi có thể có được những chẩn đoán đó, chờ đợi vấn đề xảy ra và hy vọng tôi có đủ thông tin để tìm thấy nó.

Nếu bạn được phân công làm công việc trên tay như một lập trình viên cơ sở, có ít nhất một người tin rằng bạn có khả năng tự xử lý tất cả.

Sau đó, trước khi yêu cầu sự giúp đỡ từ cấp trên, hãy viết ra một tờ giấy vụn, danh sách các bước / phương pháp bạn đã thực hiện để tìm ra lỗi, bạn đã tiếp tục với nó như thế nào, tại sao bạn từ bỏ từng phương pháp và bạn đã học được gì trong từng nỗ lực. Ngoài ra, tóm tắt những gì bạn đã học về dự án cho đến nay.

Rất có thể, khi bạn viết xong bài này, những gì có thể làm sẽ trở nên rõ ràng. Nếu có, bạn chỉ cần làm theo những gì đã tiết lộ để tái tạo lỗi và thử sửa lỗi. Nếu không, bạn có một nền tảng để bạn có thể nói chuyện với cấp trên. Nếu bạn yêu cầu sự giúp đỡ của họ mà không thể hiện những gì bạn đã làm, họ có thể có ấn tượng tiêu cực với bạn.

Nhưng, nếu bạn làm sáng tỏ, trở lại sau cuối tuần, bạn có thể giải quyết nó ngay lập tức, mà không cần ai giúp đỡ. Lúc nào chả vậy.

Chúng ta cần biết nó khó sinh sản như thế nào, vì phương pháp này khá khác nhau. Đối với một khiếm khuyết được tái tạo đáng tin cậy, tự động hóa gây ra các khiếm khuyết. Sử dụng trình gỡ lỗi và dấu vết gỡ lỗi (dấu vết có tác động ít nhất đến các khiếm khuyết loại điều kiện chủng tộc). Lấy phương pháp. Mỗi bước một bước, mỗi bước cung cấp thêm thông tin, thậm chí nó đang xác nhận những gì bạn đã biết. Nếu bạn nhận được một kết quả bất ngờ, hãy dừng lại, hiểu nó 100% trước khi tiếp tục. Nó rất chậm, nhưng luôn đưa bạn đến kết quả cuối cùng nếu bạn cho nó đủ thời gian.

Nếu bạn không thể tái sản xuất nó, thì bạn có một vấn đề, làm thế nào để bạn xác nhận bạn đã sửa nó. Đặt mã gỡ lỗi và để nó ở đó. Cuối cùng, hãy tự hỏi, "Đóng: DNR" có phải là một lựa chọn hợp lệ không? (Đã / Không thể tái sản xuất). Trong kinh doanh, cuối cùng đó là một quyết định chi phí / lợi ích.

Đừng cho rằng thư viện của bạn là chính xác, hãy xác nhận chúng.

Hãy nghỉ ngơi, thực dụng về chi phí và cần phải sửa chữa, và trên hết, hãy nhờ người khác ngồi xuống bên cạnh bạn và giúp đỡ.

Rất nhiều câu trả lời tốt ở đây. Một vài lời khuyên khác:

UI hiếm khi sống cô lập. Xây dựng chương trình thử nghiệm với bộ tính năng tối thiểu cần thiết để tái tạo lỗi. Nếu UI được thiết kế tốt, bạn sẽ có thể tách rời các thành phần UI bị lỗi và chạy chúng một cách cô lập trong một chương trình thử nghiệm. Bạn vẫn có thể tái tạo vấn đề? Nếu vậy, vấn đề có thể xảy ra trong cấu trúc hoặc khung UI của bạn. Kiểm tra cấu trúc UI của bạn - đặc biệt là coi chừng các yếu tố vô hình. Cố gắng tìm hiểu chính xác điều gì xảy ra khi bạn nhấp vào ListView đó và nó không phản hồi - trình xử lý sự kiện nào được gọi? Hãy nhớ rằng, có thể tồn tại các lỗi trong chính khung UI - đừng chuyển đến kết luận đó, nhưng đừng loại trừ nó hoàn toàn. Kiểm tra nhanh là nâng cấp phiên bản Mosync của bạn và kiểm tra xem các triệu chứng có tuân theo không.

Không thành công: Những gì còn lại trong chương trình thử nghiệm của bạn? Hiểu tất cả các thành phần của những gì còn lại, đặc biệt là bất kỳ chủ đề đang chạy. Một cái gì đó làm bảo trì cơ sở dữ liệu trong nền? Một bộ đệm tập tin của một số loại? Mã giám sát hành vi người dùng NSA? UI có hoạt động với một số thành phần này không (có thể là hậu trường)? Giao diện người dùng phụ thuộc vào hoạt động nền nào?

Trong khi bạn đang đọc mã - điều mà bạn nên dành thời gian đáng kể để thực hiện, gặp khó khăn trong lỗi - hãy coi chừng một số thực tiễn xấu có thể che khuất lỗi của bạn. Cụ thể, bạn có thấy cái nào không?

try {
    SaveTheWorld();
} catch (std::exception& ex) { /* oh it didn't work, let's just ignore it */ }

Đó là thực tế cực kỳ kém và như vậy, là khá phổ biến (hey, nó đã không sụp đổ!). Hãy chắc chắn rằng bạn nâng cấp bất kỳ mã nào đang làm điều đó để ít nhất đăng nhập nó - tốt nhất là loại bỏ hoàn toàn việc xử lý ngoại lệ sai. (Một nguyên tắc nhỏ là nếu bạn không biết ngoại lệ là gì, bạn sẽ không sẵn sàng xử lý nó.) Nếu nó tương tác với API kiểu C, hãy xem các giá trị trả về mã lỗi bị rơi và chắc chắn rằng bạn đang kiểm tra thông tin trạng thái lỗi từ bất kỳ công cụ nào bạn đang tương tác.

Xem làm thế nào chương trình thử nghiệm của bạn hiện đang xử lý các lỗi thất bại và bạn đã đọc nhật ký bạn đã tạo, nhưng vẫn không có gì làm nổi bật lỗi, hãy tìm các giao diện bạn có thể thăm dò. Có một giao dịch mạng nên được thực hiện dưới vỏ bọc? Nếu vậy, đánh nó với Wireshark. Cơ sở dữ liệu giao dịch? Hãy thử một số ghi nhật ký truy vấn hoặc kiểm tra trạng thái máy chủ cơ sở dữ liệu. Hệ thống tập tin hoặc chia sẻ mạng bị tấn công? Kiểm tra các tệp trung gian hoặc sử dụng trình gỡ lỗi để theo dõi I / O. I / O phần cứng? Giám sát và thăm dò. Hãy thực nghiệm. Giao diện người dùng có thể được treo lên trên một số thao tác nền mà bạn không lường trước được.

Cuối cùng: Đừng hoảng sợ. Giữ bình tĩnh và theo dõi những gì bạn đã cố gắng. Nếu bạn vẫn không thể tìm thấy nó, nó sẽ phải trở thành một "vấn đề đã biết" để được theo dõi vào một ngày mưa. Bạn sẽ muốn nhiều tài liệu để biện minh cho quyết định đó nếu nó phải đi theo hướng đó.

Trong sơ đồ của mọi thứ, lỗi tái tạo là (tương đối) dễ dàng! Tại sao? Bởi vì bạn luôn có thể hack mã xuống mức tối thiểu cho đến khi lỗi biến mất, và sau đó hoạt động trở lại để tìm ra mã nào gây ra nó. Vì vậy, đó là một phương pháp. Nó có thể tái tạo, bạn có máy nghiền ở đó dưới sự kiểm soát của bạn. Bạn có thể chọc nó, và thử nghiệm với nó. Bạn thậm chí có thể mổ xẻ nó nếu bạn muốn.

Mục tiêu đầu tiên của bạn là hiểu lý do tại sao lỗi xảy ra trong mã của bạn . Đừng cố gắng sửa nó ban đầu. Chỉ cần cố gắng để hiểu nó. Nếu bạn cố gắng sửa nó mà không hiểu thì bạn sẽ bị hack và có thể sẽ đưa ra nợ kỹ thuật , ngay cả khi bạn giải quyết được.

Bước qua hành vi của ứng dụng, từng dòng. Xem các giá trị biến. Theo dõi dòng kiểm soát. Trường hợp hành vi đầu tiên đi chệch khỏi những gì sự hiểu biết của bạn nói với bạn rằng nó nên được? Bạn có hiểu làm thế nào hệ điều hành gửi các sự kiện đến ứng dụng của bạn? Nếu bạn bị cản trở bởi vấn đề "hộp đen", bạn có thể lấy nguồn cho các thư viện / khung đã biên dịch, cho phép bạn bước qua ở mức sâu hơn nếu bạn phải không?

Bạn có một cam kết trong hệ thống kiểm soát phiên bản của bạn không tạo ra lỗi này không? (Bạn đang sử dụng kiểm soát phiên bản phải không?) Nếu bạn có một cam kết như vậy, thì bạn có thể thực hiện tìm kiếm nhị phân trên lịch sử để tìm ra chính xác nơi lỗi được giới thiệu.

Mục tiêu của bạn là (1) hiểu - xác định nguyên nhân và cuối cùng, cố gắng (2) kiểm tra, hiểu chi tiết hành vi ứng dụng (3) cách ly vấn đề bằng cách làm cho nó biến mất và sau đó kiểm tra và hiểu về delta mà cho phép bạn làm điều đó

Nhưng chắc chắn đừng ngồi đó hàng tuần nếu bạn thực sự bế tắc. Bạn phải nói với ai đó trong tổ chức của bạn quá. Tìm kiếm sự giúp đỡ ở nơi bạn có thể và vượt qua một điểm nào đó, chắc chắn bạn phải đương nhiên nói với quản lý rằng bạn cảm thấy mình đã vượt qua rào cản tiến bộ. Nhưng bạn có thể sẽ giải quyết được vấn đề này nếu bạn đánh nó từ một số góc độ khác nhau, tất cả tập trung vào việc học và hiểu.