Chương trình không chắc chắn nhất mà bạn phải duy trì là gì?

Tôi định kỳ kêu gọi thực hiện công việc bảo trì trên một hệ thống được xây dựng bởi một bác sĩ phẫu thuật tên lửa thực sự. Có rất nhiều điều sai trái với việc thật khó để biết bắt đầu từ đâu.Chương trình không chắc chắn nhất mà bạn phải duy trì là gì?

Không, chờ đợi, tôi sẽ bắt đầu từ đầu: trong những ngày đầu của dự án, nhà thiết kế đã được thông báo rằng hệ thống sẽ cần phải mở rộng quy mô và anh ta đọc rằng một vấn đề về khả năng mở rộng là lưu lượng truy cập giữa các máy chủ ứng dụng và cơ sở dữ liệu, do đó, anh ta đã đảm bảo giảm thiểu lưu lượng truy cập này. Làm sao? Bằng cách đặt tất cả các logic ứng dụng trong các thủ tục lưu sẵn SQL Server.

Nghiêm túc. Phần lớn các hàm ứng dụng của giao diện người dùng HTML tạo thành các thông điệp XML. Khi tầng giữa nhận được một thông báo XML, nó sử dụng tên thẻ của phần tử tài liệu làm tên của thủ tục lưu sẵn mà nó sẽ gọi và gọi SP, chuyển nó toàn bộ thông điệp XML như một tham số. Nó lấy thông điệp XML mà SP trả về và trả về trực tiếp trở lại giao diện người dùng. Không có logic nào khác trong tầng ứng dụng.

(Có là một số mã trong tầng giữa để xác nhận các thông điệp XML đến chống lại một thư viện các lược đồ. Nhưng tôi lấy nó, sau khi xem xét nếu 1) chỉ một số nhỏ các thông điệp đã tương ứng schemas, 2) các thông điệp không thực sự phù hợp với các lược đồ này và 3) sau khi xác thực các thông báo, nếu có bất kỳ lỗi nào gặp phải, phương thức đã loại bỏ chúng. "Hộp cầu chì này là một máy tiết kiệm thời gian thực - nó xuất phát từ nhà máy với các đồng xu được cài sẵn!")

Tôi đã thấy phần mềm làm điều sai trái trước đây. Rất nhiều của nó. Tôi đã viết khá một chút. Nhưng tôi chưa bao giờ thấy bất cứ điều gì như quyết tâm đúng đắn để làm điều sai trái, tại mọi lượt có thể, được thể hiện trong thiết kế và lập trình của hệ thống này.

Vâng, ít nhất anh ấy đã làm theo những gì anh ấy biết, phải không? Um. Rõ ràng, những gì anh biết là Access. Và anh ấy thực sự không hiểu quyền truy cập. Hoặc cơ sở dữ liệu.

Dưới đây là một mô hình phổ biến ở mã này:

 
SELECT @TestCodeID FROM TestCode WHERE TestCode = @TestCode 

SELECT @CountryID FROM Country WHERE CountryAbbr = @CountryAbbr 

SELECT Invoice.*, TestCode.*, Country.* 
    FROM Invoice 
    JOIN TestCode ON Invoice.TestCodeID = TestCode.ID 
    JOIN Country ON Invoice.CountryID = Country.ID 
    WHERE Invoice.TestCodeID = @TestCodeID AND Invoice.CountryID = @CountryID

Được rồi, được rồi. Bạn cũng không tin tưởng trình tối ưu hóa truy vấn. Nhưng làm thế nào về điều này? (Ban đầu, tôi sẽ đăng bài này trong số What's the best comment in source code you have ever encountered? nhưng tôi nhận ra rằng có quá nhiều thứ để viết về hơn là chỉ một bình luận này, và mọi thứ đã vượt khỏi tầm tay.) Vào cuối nhiều thủ tục lưu trữ tiện ích, bạn sẽ thấy mã trông giống như sau:

 
-- Fix NULLs 
SET @TargetValue = ISNULL(@TargetValue, -9999)

Có, mã đó đang thực hiện chính xác những gì bạn không thể cho phép mình tin rằng điều đó làm bạn sợ bị điên. Nếu biến chứa NULL, anh ta cảnh báo người gọi bằng cách thay đổi giá trị của nó thành -9999. Dưới đây là cách số này thường được sử dụng:

 
-- Get target value 
EXEC ap_GetTargetValue @Param1, @Param2, OUTPUT @TargetValue 
-- Check target value for NULL value 
IF @TargetValue = -9999 
    ...

Thực sự.

Để biết kích thước khác của hệ thống này, hãy xem bài viết trên thedailywtf.com có tiêu đề I Think I'll Call Them "Transactions". Tôi không thực hiện bất kỳ điều này. Tôi thề.

Tôi thường được nhắc nhở, khi tôi làm việc trên hệ thống này, phản ứng nổi tiếng của Wolfgang Pauli đối với một sinh viên: "Điều đó không đúng. Nó thậm chí không sai."

Đây thực sự không phải là chương trình tồi tệ nhất bao giờ hết. Đó chắc chắn là điều tồi tệ nhất mà tôi đã từng làm trong toàn bộ 30 năm (sự nghiệp) của tôi. Nhưng tôi chưa từng thấy mọi thứ. ?

Chương trình không chắc chắn nhất mà bạn phải duy trì là gì?

Trả lời

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