Мне периодически призывают выполнять ремонтные работы на системе, которая была создана настоящим ракетологом. Там так много неправильно, что трудно понять, с чего начать.
Нет, подождите, я начну с самого начала: в начале проекта дизайнеру сказали, что системе нужно будет масштабировать, и он читал, что источником проблем с масштабируемостью является трафик между серверов приложений и баз данных, поэтому он старался минимизировать этот трафик. Как? Поместив всю логику приложения в хранимые процедуры SQL Server.
Серьезно. Основная часть приложения работает с интерфейсом HTML, который формирует XML-сообщения. Когда средний уровень получает XML-сообщение, он использует имя тега элемента документа как имя хранимой процедуры, которую он должен вызывать, и вызывает SP, передавая ему все XML-сообщение в качестве параметра. Требуется XML-сообщение, которое возвращается SP, и возвращает его обратно обратно в интерфейс. В уровне приложения нет другой логики.
(Для проверки входящих XML-сообщений в библиотеке схем был обнаружен некоторый код, но я удалил его, установив, что 1) только небольшая часть сообщений имела соответствующие схемы, 2) t фактически соответствуют этим схемам, и 3) после проверки сообщений, если были обнаружены какие-либо ошибки, метод отменил их. "Этот блок предохранителей - реальная экономия времени - он поставляется с factory с заранее установленными пенни!" )
Я видел программное обеспечение, которое раньше делало неправильное. Много. Я написал совсем немного. Но я никогда не видел ничего похожего на твердое намерение сделать не то, что нужно, в любой момент, воплотившийся в дизайне и программировании этой системы.
Ну, по крайней мере, он пошел с тем, что знал, да? Um. По-видимому, он знал, что "Доступ". И он действительно не понимал Access. Или базы данных.
Вот общий шаблон в этом коде:
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
Хорошо, отлично. Вы также не доверяете оптимизатору запросов. Но как насчет этого? (Первоначально я собирался опубликовать это в Какой лучший комментарий в исходном коде, который вы когда-либо встречали?, но я понял, что писать было гораздо больше, чем просто этот комментарий, и все просто вышло из-под контроля.) В конце многих хранимых процедур утилиты вы увидите код, который выглядит следующим образом:
-- Fix NULLs SET @TargetValue = ISNULL(@TargetValue, -9999)
Да, этот код делает именно то, что вы не можете позволить себе поверить в это, чтобы вас не смутило. Если переменная содержит NULL, он предупреждает вызывающего абонента, изменяя его значение на -9999. Здесь, как обычно используется это число:
-- Get target value
EXEC ap_GetTargetValue @Param1, @Param2, OUTPUT @TargetValue
-- Check target value for NULL value
IF @TargetValue = -9999
...
На самом деле.
Для другого измерения этой системы см. статью на thedailywtf.com под названием Думаю, я позвоню им "Транзакции" . Я не делаю этого. Клянусь.
Мне часто вспоминают, когда я работаю над этой системой, Вольфганга Паули известный ответ ученику: "Это неправильно, это даже не так".
На самом деле это не самая худшая программа. Это определенно худший из тех, над которыми я работал в своей 30-летней карьере. Но я не видел всего. Что вы видели?
