Hãy tưởng tượng kịch bản sau đây:

Bạn đã phát hiện ra rằng chương trình của bạn (hoặc của người khác) có lỗi - một hàm tạo ra kết quả sai khi đưa ra một đầu vào cụ thể. Bạn kiểm tra mã và không thể tìm thấy bất cứ điều gì sai: nó dường như bị sa lầy khi đưa ra đầu vào này.

Bây giờ bạn có thể thực hiện một trong hai điều sau: bạn kiểm tra mã thêm cho đến khi bạn tìm thấy nguyên nhân thực sự; hoặc bạn tát vào băng bằng cách thêm ifcâu lệnh kiểm tra xem đầu vào có phải là đầu vào cụ thể này không - nếu có, trả về giá trị mong đợi.

Đối với tôi, áp dụng băng sẽ hoàn toàn không thể chấp nhận được. Nếu mã đang hoạt động không giới hạn trên đầu vào này, thì đầu vào nào khác mà bạn đã bỏ lỡ sẽ phản ứng kỳ lạ với? Nó hoàn toàn không giống một bản sửa lỗi - bạn chỉ đang giải quyết vấn đề dưới tấm thảm.

Vì tôi thậm chí sẽ không cân nhắc việc này, tôi ngạc nhiên về việc các giáo sư và sách thường xuyên nhắc nhở chúng tôi về việc áp dụng các bản sửa lỗi "băng bó" không phải là một ý tưởng hay. Vì vậy, điều này làm cho tôi tự hỏi: làm thế nào phổ biến là những loại "sửa chữa"?

Áp lực thời gian / thời hạn là một lý do.

Nếu bạn đang chống lại một thời hạn chặt chẽ và bạn đã khiến sếp phải thở dốc (có thể theo nghĩa đen!) Thì hãy làm điều này và nghĩ rằng "Tôi sẽ quay lại và sửa lỗi này sau" rất hấp dẫn và có thể là điều duy nhất bạn có thể làm được.

Tất nhiên số lần bạn thực sự quay lại và sửa nó là rất ít và rất xa bởi vì bạn có một vấn đề mới cần khắc phục ngày hôm qua.

Nhiều như chúng tôi, các lập trình viên không muốn thừa nhận nó, phần mềm được mã hóa đẹp mắt sẽ không luôn chuyển sang giá trị cao hơn cho công ty hoặc khách hàng. Điều này hoàn toàn đúng trong tình huống thảm họa, ví dụ như phần mềm đang tính phí gấp đôi thẻ tín dụng của mọi người. Đôi khi, giống như băng, bạn chỉ cần cầm máu bằng bất cứ phương tiện nào cần thiết và hứa sẽ lấy lại sau khi bệnh nhân đã ổn định và thực sự khắc phục vấn đề cốt lõi.

Bí quyết là, một khi sự khẩn cấp không còn nữa, thật khó để thuyết phục bất cứ ai ưu tiên thay thế băng bằng một sửa chữa thực sự. Đặc biệt là xem xét rằng luôn luôn có một vấn đề cấp bách khác đang chờ đợi phía sau cái đầu tiên. Bạn chỉ cần thận trọng về vấn đề vượt ra ngoài cách khắc phục nhanh.

Thời gian

Là lý do số 1 theo ý kiến ​​của tôi. Mặc dù nếu vấn đề là codebase, tôi có thể mất nhiều thời gian hơn để điều tra nó. Thông thường các bản sửa lỗi "băng bó" của tôi liên quan đến các chỉnh sửa CSS hoặc UI. Tôi đã viết một số CSS và JavaScript nội tuyến khá khó chịu để xử lý chúng nhanh chóng. Quay trở lại và sửa nó luôn là một lựa chọn nếu bạn có thời gian.

Chúng tôi làm chúng đặc biệt.

Đối với các bản sửa lỗi trong quá trình phát triển, chúng tôi đảm bảo rằng không có bản sửa lỗi nào được thực hiện mà không biết nguyên nhân gốc. Tuy nhiên:

• Ngoại lệ, việc tìm kiếm nguyên nhân gốc sẽ bắt đầu mất quá nhiều thời gian hoặc bị đình trệ VÀ có một thời hạn khó khăn,
• Thay đổi mã ngoại lệ để khắc phục nguyên nhân gốc là không khả thi về mặt chiến thuật (thay đổi sẽ mất quá nhiều thời gian và thời hạn tiếp cận)

Trong những trường hợp đó, chúng tôi lựa chọn sửa lỗi "băng bó". Sau đó chúng tôi mở các khiếm khuyết nội bộ để giải quyết nguyên nhân gốc rễ. Có, thường xuyên hơn không phải là những khiếm khuyết bên trong được điều trị với mức độ ưu tiên rất thấp.

Đối với các bản sửa lỗi trong luồng bảo trì, chúng tôi đảm bảo rằng không có sửa chữa nào được thực hiện mà không biết nguyên nhân gốc. Tuy nhiên:

• Rất đặc biệt việc tìm kiếm nguyên nhân gốc sẽ bị đình trệ,
• Ngoại lệ có thể xảy ra rằng việc khắc phục nguyên nhân gốc là không khả thi về mặt chiến thuật (thay đổi là không tầm thường và khách hàng cần sửa chữa ngày hôm qua).

Trong những trường hợp đó, chúng tôi chọn cách khắc phục tạm thời "băng bó" và một khi khách hàng hài lòng, chúng tôi sẽ khắc phục sự cố và chỉ sau đó lỗi được giải quyết.

Định hướng.

• Với một lỗi cụ thể, có một khó khăn đáng kể trong việc xác định một cách khách quan liệu một sửa chữa cụ thể có phải là "băng bó" hay không: "giải pháp chính xác" của một người có thể là "băng bó" của người khác.
• Vì vậy, tôi sử dụng định nghĩa sau: để sửa chữa một khiếm khuyết theo cách kém thanh lịch và ít nghiên cứu hơn tôi ước tôi sẽ thực hiện một cách chuyên nghiệp.

Đầu tiên, liên quan đến tần suất sửa lỗi "băng bó":

• Mã mới: gần như không có.
• Mã cũ:
  • Bạn sẽ tìm thấy một số, mặc dù chúng thường được viết đủ thanh lịch (xem "giảm thiểu dựa trên dữ liệu" bên dưới) rằng chúng không giống như băng và sẽ tồn tại trong tất cả các đánh giá mã.
  • Cũng chú ý đến "băng vô hình": đơn giản là đừng gọi chức năng đó. Với việc thiếu mã, thậm chí không có dấu vết nào cho thấy lỗi tồn tại.
• Mã cũ với nhiều phụ thuộc bên ngoài:
  • Gần như đầy đủ của nó.
  • Nó hầu như luôn được viết cho một phiên bản lỗi thời của phụ thuộc và không ai thực sự đọc "ghi chú phát hành" của phụ thuộc trước khi cập nhật phụ thuộc lên phiên bản mới.

Thứ hai, lời khuyên của tôi:

Nếu lỗi xảy ra trong mã nguồn riêng của nhóm phát triển:

• Sửa nó một cách chuyên nghiệp. (Nếu bạn sửa nó, bạn sở hữu nó.)
• Khi chịu áp lực thời gian, hãy làm những điều tốt nhất bạn có thể - đòi hỏi bạn phải:
  • Xem xét tác động tiềm tàng đối với người dùng cuối: của chính lỗi và của bản sửa lỗi được đề xuất, để quyết định có chấp nhận sửa lỗi hay không.
  • Nghiên cứu các đoạn mã liên quan (sử dụng thông tin lịch sử từ công cụ quản lý mã nguồn của bạn) và thảo luận với đồng nghiệp của bạn (nhưng không chiếm quá nhiều thời gian của họ), cho đến khi bạn hiểu rõ vấn đề và giải pháp.
• Luôn theo dõi lỗi với hệ thống theo dõi lỗi .

Nếu lỗi xảy ra trong mã nguồn của nhóm khác:

• Đẩy đội đó để sửa lỗi của họ.
• Luôn luôn báo lỗi với hệ thống theo dõi lỗi của nhóm khác .

Nếu lỗi xảy ra trong sản phẩm của công ty khác (hoặc không có công ty):

• Trong trường hợp này, sửa lỗi băng keo (hoặc cách khắc phục dựa trên dữ liệu ) có thể là cách duy nhất để sửa lỗi.
• Nếu đó là nguồn mở, hãy gửi tệp đó với một số hệ thống theo dõi lỗi (có thể là công khai) , để ai đó có thể xem xét nó.

Tôi nghĩ phụ thuộc rất nhiều vào độ tuổi của cơ sở mã. Về mã cũ tôi nghĩ nó rất phổ biến, viết lại rằng thói quen COBOL 20 năm tuổi không vui chút nào. Ngay cả trên mã mới vừa phải đang được sản xuất, nó vẫn khá phổ biến.

Tôi sẽ nói nó rất phổ biến.

Kiểm tra bài viết trên blog của Joel Spolsky: Lập trình viên băng keo

Tôi có thể dễ dàng nói rằng cứ gần như mọi dự án tôi từng tham gia tôi đã phải áp dụng một số loại băng hoặc băng keo để đáp ứng thời hạn và hoàn thành một nhiệm vụ. Nó không đẹp, không sạch sẽ, nhưng nó hoàn thành công việc để một doanh nghiệp có thể tiếp tục hoạt động và dự án có thể tiến lên theo một cách nào đó.

Có một sự khác biệt giữa thế giới học thuật và thế giới thực nơi phần mềm thực sự cần phải vận chuyển theo thời gian và các điều kiện kinh doanh.

Theo một cách nào đó, nó đặt nó dưới tấm thảm, để trì hoãn việc sửa chữa, cho đến khi hy vọng, sau này. Đáng buồn thay, quá thường xuyên, sửa chữa trì hoãn không bao giờ xảy ra và mã này tìm đường vào sản xuất.

Thật khó để nói mà không có nhiều ngữ cảnh - trong ví dụ của bạn, tại sao việc thêm câu lệnh if không phải là sửa lỗi chính xác? Có phải vì có một số khối mã khác ở đó được cho là đang xử lý đầu vào đó không?

Mức độ thường xuyên sử dụng các bản sửa lỗi băng bó phụ thuộc vào một số điều như mức độ phức tạp của mã, liệu người quen thuộc nhất với mã có sẵn hay không (người chịu trách nhiệm về thói quen COBOL 20 năm của Craig có thể rời công ty nhiều năm trước ) và thời gian liên quan.

Với một thời hạn nhìn chằm chằm vào mặt bạn, đôi khi bạn sẽ đầy đặn để sửa chữa an toàn hơn, ngay cả khi nó chỉ là một cái thạch cao trên thay vì sửa chữa nguyên nhân gốc rễ. Điều đó ổn miễn là bạn không làm mọi thứ tồi tệ hơn, nhưng điều quan trọng là phải theo dõi thực tế rằng nó vẫn không đúng và vẫn cần được sửa chữa đúng cách.

Có những trường hợp loại sửa chữa đó thực sự ổn và có lẽ là lý tưởng (theo thời gian cần thiết để gỡ lỗi có liên quan).

Hãy tưởng tượng một kịch bản trong đó bạn có 20 DLL được cho là hoạt động như một loại mô-đun cho tệp thực thi chính của bạn, nhưng cũng yêu cầu một số thông tin từ tệp thực thi chính để chạy.

Nếu bạn muốn sử dụng các DLL đó bên ngoài tệp thực thi chính, bạn sẽ cần làm mờ một số giá trị trả về từ tệp thực thi chính bởi vì. A.) Nó không tồn tại trong bối cảnh này và B.) Bạn không muốn nó tồn tại trong bối cảnh này.

Điều đó đang được nói, tốt hơn hết là bạn nên đặt một số chỉ thị của trình biên dịch vào mã của mình để đảm bảo rằng bạn đang chạy mã hoàn toàn khác khi bạn làm mờ kết quả so với khi bạn nhận được kết quả thực.

Thay vì đặt một ifchức năng bên trong của người khác, tôi sẽ đặt một {$ifdef}chức năng xung quanh - theo cách đó, không ai nhầm lẫn nó với thứ gì đó phải có ở đó.