Gỡ lỗi: hiểu chi tiết về lý do tại sao một số bản sửa lỗi hoạt động? [đóng cửa]

Khi gỡ lỗi, đôi khi tôi thấy rằng tôi thực hiện một số thay đổi và tôi không chắc chắn 100% lý do tại sao những thay đổi đó sửa một số lỗi trong chương trình. Có cần thiết phải hiểu từng chi tiết về lý do tại sao một số lỗi xảy ra và tại sao một số thay đổi nhất định loại bỏ các lỗi đó không? Hoặc là phổ biến giữa các nhà phát triển đôi khi làm cho chương trình hoạt động mà không thực sự biết chi tiết về lý do tại sao bản sửa lỗi hoạt động?

Tôi sẽ nói rằng điều cần thiết là phải hiểu từng chi tiết về lý do tại sao một số lỗi xảy ra và tại sao một số thay đổi đã loại bỏ các lỗi đó và đôi khi các nhà phát triển cũng thường làm cho chương trình hoạt động mà không thực sự biết chi tiết về lý do tại sao bản sửa lỗi hoạt động!

Nghệ thuật thay đổi mọi thứ cho đến khi một lỗi biến mất, mà không hiểu nguyên nhân gây ra nó hoặc tại sao thay đổi đã khắc phục nó, thường được gọi là "lập trình voodoo", và đó không phải là một lời khen. Thực sự không có cách nào bạn có thể tự tin rằng bạn đã thực sự sửa một lỗi, trái ngược với việc sửa một phần cho trường hợp cụ thể mà bạn đang điều tra, nếu bạn không hiểu nguyên nhân gây ra nó.

Trong trường hợp xấu nhất, bạn chưa làm gì cả ngoại trừ di chuyển lỗi: Tôi nhớ từ năm đầu tiên tính toán tại uni, khi nhiều sinh viên học C và con trỏ lần đầu tiên, lỗi con trỏ thường sẽ ngừng biểu hiện khi họ thay đổi mọi thứ ngẫu nhiên, vì các thay đổi sẽ sắp xếp lại các cấu trúc dữ liệu trong bộ nhớ đủ để khiến lỗi con trỏ dậm lên một bit bộ nhớ khác. Rõ ràng điều đó đã không giúp được gì cả .

Nhưng có nói rằng, thực tế thương mại của lập trình thường là việc thỏa mãn khách hàng rằng một lỗi được sửa chữa quan trọng hơn là thỏa mãn chính mình. Tôi không bao giờ khuyên bạn nên khai báo một cái gì đó cố định nếu bạn không biết điều gì đã gây ra nó, nhưng nếu bạn có thể thấy rằng một số mã có vấn đề và bạn đã làm lại nó, ngay cả khi bạn "không chắc chắn 100%" việc đó gây ra sự cụ thể như thế nào lỗi để biểu hiện, đôi khi bạn chỉ cần chuyển sang lỗi tiếp theo trước khi khách hàng hét quá to về tiến trình chậm chạp của bạn.

Nếu bạn nghĩ rằng một khách hàng tức giận vì mất quá nhiều thời gian để sửa lỗi, hãy tưởng tượng họ sẽ điên như thế nào về một lỗi lặp lại mà bạn tuyên bố đã được sửa chữa, hoặc một sửa chữa cho một điều khiến điều khác trở nên tồi tệ hơn. Nếu sửa chữa của bạn chỉ là một cách giải quyết hoặc giảm thiểu, khách hàng thường sẽ vẫn hoan nghênh nó, nhưng bạn phải trung thực về những gì nó là, và bạn đặt nhiều nhật ký như bạn cần để sửa nó thành sự thật.

Nếu bạn khá chắc chắn rằng bạn đã sửa nó, nhưng không biết tại sao bản sửa lỗi hoạt động, hãy hỏi ai đó. Hầu hết các kỹ sư tôi biết đều thích nhận được những câu hỏi như vậy vì bí ẩn đằng sau nó.

Thay đổi công cụ cho đến khi lỗi không còn là thực tế xấu, nhưng thật không may, một thực tế cho một số người.

Tôi có quan điểm mạnh mẽ rằng bạn không bao giờ nên viết mã mà bạn không hiểu nó làm gì hoặc tại sao nó lại làm như vậy. Làm thế nào bạn có thể chắc chắn rằng mặc dù bạn đã sửa lỗi bạn đã đặt ra để sửa - bạn chưa làm gì khác?

Nói chung, trước khi bạn khắc phục sự cố / lỗi - bạn nên thực hiện đánh giá / phân tích nguyên nhân cơ bản để xác định lý do tại sao sự cố xảy ra và liệu nó có thể được nhân rộng. Sau đó, bạn nên đọc mã và hiểu lý do tại sao mã gây ra lỗi xảy ra. Khi bạn đã hiểu điều đó: sau đó bạn có thể bắt đầu xem xét cách giải quyết vấn đề và xác định các lĩnh vực khác mà (các) thay đổi của bạn sẽ tác động. Bài kiểm tra đơn vị thực sự có thể giúp đỡ ở đây!

Tôi đã thấy một số thay đổi mã mà mọi người đã thực hiện để khắc phục sự cố (rất tốt), nhưng không may giới thiệu các vấn đề khác vì nhà phát triển không biết về tác động đầy đủ của những gì họ đã thay đổi. Nhiều "sửa chữa" này chỉ che khuất nguyên nhân cơ bản của vấn đề ban đầu cũng như đưa ra sự phức tạp và nhiều lỗi hơn.

Phải nói rằng, tôi đã sửa một số vấn đề trong mã hoàn toàn bằng liên kết. Nơi tôi đã thay đổi / làm lại / tái cấu trúc một cái gì đó và nó đã sửa các lỗi nổi bật khác. Vì vậy, mặc dù tôi không biết nguyên nhân gây ra chúng ban đầu, tôi đã tìm thấy mã tinh ranh và "sửa" nó - điều này cũng xảy ra để sửa những lỗi đó. Tôi bao gồm các thay đổi như thế này với các bài kiểm tra đơn vị và tích hợp để đảm bảo tính toàn vẹn của các yêu cầu kinh doanh và kỹ thuật của chức năng.

Hoặc là phổ biến giữa các nhà phát triển đôi khi làm cho chương trình hoạt động mà không thực sự biết chi tiết về lý do tại sao bản sửa lỗi hoạt động?

Có ít nhất ba vấn đề lớn với điều đó:

1. Nó dẫn đến một tư duy ma thuật đen , nơi bạn từ bỏ ý tưởng rằng bạn có thể hiểu được mã và thay vào đó chỉ bắt đầu di chuyển các bộ phận xung quanh với hy vọng rằng các vấn đề sẽ biến mất. Đây là chương trình tương đương với việc đẩy thức ăn xung quanh đĩa của bạn, hy vọng làm cho bữa tối của bạn trông đủ ăn mà bố mẹ bạn sẽ không cho bạn ăn nhiều rau hơn.

2. Bạn không thể biết rằng lỗi thực sự đã được sửa chữa hoặc chỉ bị che dấu bởi sự thay đổi của bạn trừ khi bạn hiểu a) vấn đề là gì và b) cách thay đổi của bạn giải quyết vấn đề.

3. Lỗi này có thể không được sửa và nó sẽ cắn bạn một lần nữa trong tương lai gần.

Tôi thấy hai tình huống: bạn đã làm việc với một thứ khác và lỗi đã ngừng xảy ra, miễn là thứ khác không làm hỏng bất cứ thứ gì khác, bạn phải để nó đi vào - bạn đã làm những gì cần / muốn và nó đã có một tác dụng phụ tích cực không lường trước và không thể giải thích.

Khác là bạn đang làm việc với lỗi này và một sự thay đổi ngẫu nhiên khiến mọi thứ hoạt động, điều đó không thể chấp nhận được. Nếu bạn không biết mã cũ đã làm gì sai, có lẽ bạn không biết mã mới đang làm gì sai.

Tôi thực sự không thể nghĩ ra một lý do chính đáng để kiểm tra trường hợp thứ hai - nếu đó là một lỗi nghiêm trọng, thì điều đó rất quan trọng để làm cho đúng. Nếu đó là một lỗi không nghiêm trọng, ít nhất bạn có thể chắc chắn rằng mình không đưa ra một lỗi nghiêm trọng bằng "sửa lỗi" của mình.

Hoặc là phổ biến giữa các nhà phát triển đôi khi làm cho chương trình hoạt động mà không thực sự biết chi tiết về lý do tại sao bản sửa lỗi hoạt động?

Tôi nghĩ rằng nó rất phổ biến những ngày này. Đó là vì Google và Stackoverflow. Bạn có một vấn đề với mã của bạn, chỉ cần google nó, tìm giải pháp, sửa lỗi, chuyển sang vấn đề tiếp theo.