Có phải những người khác sửa lỗi khi họ nhìn thấy chúng, hoặc họ đợi cho đến khi có sự cố / mất dữ liệu / người chết trước khi sửa nó?
ví dụ 1
Customer customer = null;
...
customer.Save();
Mã rõ ràng là sai và không có cách nào khác - nó đang gọi một phương thức trên tham chiếu null. Nó không xảy ra sự cố vì Savekhông truy cập bất kỳ dữ liệu cá thể nào; vì vậy nó giống như gọi một hàm tĩnh. Nhưng bất kỳ thay đổi nhỏ ở bất cứ đâu cũng có thể đột nhiên gây ra mã bị hỏng không bị sập: bắt đầu bị sập.
Nhưng , cũng không thể tưởng tượng rằng việc sửa mã:
Customer customer = null;
...
customer = new Customer();
try
...
customer.Save();
...
finally
customer.Free();
end;
có thể giới thiệu một vụ tai nạn; một không được phát hiện thông qua các bài kiểm tra đơn vị với phạm vi bảo hiểm đầy đủ và kiểm tra người dùng thủ công.
Ví dụ 2
float speed = 0.5 * ((G * mass1 * mass2) / R) * Pow(time, 2);
Những người biết về vật lý sẽ nhận ra rằng nó được coi là R 2 trong mẫu số.
Mã là sai, nó hoàn toàn sai. Và việc đánh giá quá cao tốc độ sẽ khiến các tên lửa retro bắn quá sớm, giết chết tất cả những người chiếm giữ tàu vũ trụ.
Nhưng có lẽ cũng có thể ước tính quá mức tốc độ đang che giấu một vấn đề khác: túi khí không thể triển khai trong khi tàu con thoi di chuyển quá nhanh. Nếu chúng tôi đột nhiên sửa mã:
float speed = 0.5 * ((G * mass1 * mass2) / Pow(R, 2)) * Pow(time, 2);
Bây giờ tốc độ là chính xác, và đột nhiên túi khí được triển khai khi họ không nên.
Ví dụ 3
Đây là một ví dụ mà tôi đã có gần đây, kiểm tra xem một chuỗi có chứa các ký tự không hợp lệ không:
if (StrPos(Address, "PO BOX") >= 0)
{
//Do something
}
Điều gì nếu nó quay ra có một lỗi trong các Do somethingchi nhánh? Sửa mã rõ ràng không chính xác:
if (StrPos("PO BOX", Address) >= 0)
{
//Do something
}
Sửa mã, nhưng giới thiệu một lỗi.
Cách tôi nhìn thấy nó có hai khả năng:
- sửa mã và bị đổ lỗi vì phá vỡ mã
- chờ mã bị sập và bị đổ lỗi vì có lỗi
Làm gì bạn làm chính trị?
Ví dụ 4 - Lỗi thế giới thực ngày nay
Tôi đang xây dựng một đối tượng, nhưng gọi hàm tạo sai:
Customer customer = new Customer();
Hóa ra hàm tạo "không tham số" thực sự là hàm tạo được tham số hóa từ phía sau trong chuỗi thừa kế:
public Customer(SomeObjectThatNobodyShouldBeUsingDirectly thingy = null)
public Customer(InjectedDependancy depends)
Gọi nó là một sai lầm, vì nó bỏ qua tất cả các nhà xây dựng tiếp theo.
Tôi có thể thay đổi dòng dõi của đối tượng để không lộ ra một hàm tạo nguy hiểm như vậy, nhưng bây giờ tôi phải thay đổi mã thành:
Customer customer = new Customer(depends);
Nhưng tôi không thể đảm bảo rằng sự thay đổi này sẽ không phá vỡ bất cứ điều gì. Giống như ví dụ 1 của tôi ở trên, có lẽ ai đó, ở đâu đó, bằng cách nào đó, trong một số điều kiện bí truyền, phụ thuộc vào cấu trúc Customerkhông hợp lệ và đầy rác.
Có lẽ Customerđối tượng, bây giờ nó được xây dựng đúng sẽ cho phép một số mã chạy mà trước đây chưa từng làm, và bây giờ tôi có thể gặp sự cố.
Tôi không thể đặt cược cuộc sống của vợ bạn vào đó.
Và tôi có thể kiểm tra nó từ đây đến thứ ba, tôi không thể thề với cuộc sống của con gái bạn rằng tôi không đưa ra hồi quy.
Tôi có
- Sửa mã và bị đổ lỗi cho việc phá vỡ nó? hoặc là
- Để lại lỗi, và bị đổ lỗi khi khách hàng tìm thấy nó?