|
|
| /* Русский Вариант */ |
|
|
|
| /* Русский Вариант */ |
| « Корпоративный Движок Правил | Убйиство процессов » |
Письмо, на котором основывалась сегодняшняя статья, было отозвано. Вместо нее я воспользуюсь случаем и представлю практику мягкого кодирования.
Многие программисты считают «Жесткое Кодирование» (Hard Coding) нехорошей штукой: это похоже на сиюминутные заплатки, не элегантный и лентяйский код. А посему многие программисты из кожи вон лезут, чтобы избежать этого. К сожалению, этот путь уклонения часто заводит на еще более порочный путь: усложнения и запутывания, а в итоге совершенно неподдерживаемого кода. Этот путь я предпочитаю называть «Мягкое Кодирование» (Soft Coding).
Перед тем как начать обсуждение тонких деталей мягкого кодирования, я бы хотел вкратце описать само понятие «жесткое кодирование». Это практика включения «вещей, которых не должно быть в исходном коде» прямиком в исходный код. Это определение умышленно расплывчатое: хотя многие из вас согласятся, что строки подключения к базам данных и каталоги для хранения журналов не принадлежат к исходному коду, существует множество пограничных случаев. Возьмем для примера следующий код:
private void attachSupplementalDocuments()
{
if (stateCode == "AZ" || stateCode == "TX") {
//SR008-04X/I в этих штатах требуется всегда
attachDocument("SR008-04X");
attachDocument("SR008-04XI");
}
if (ledgerAmnt >= 500000) {
//Для книг с балансами в 500000 или больше требуются AUTHLDG-1A
attachDocument("AUTHLDG-1A");
}
if (coInsuredCount >= 5 && orgStatusCode != "CORP") {
//Для не-CORP организаций с 5 или более совместно страхующимися требуется AUTHCNS-1A
attachDocument("AUTHCNS-1A");
}
}
Я уже слышу, негодующие крики: волшебные числа, строковые литералы, фуу, да это же все жесткое кодирование! Однако ни единый символ в этом примере не является жестко закодированным: в вышеприведенном примере нет ничего «чего не должно быть в исходном коде». Функция просто реализует очень ясное и очень специфическое бизнес-требование посредством очень ясного и специфического кода. Если хоть что-то убрать, это уже будет закодировано мягко.
Это приводит нас к определению мягкого кодирования: практике удаления «вещей, которые должны быть в исходном коде» из исходного кода и перемещения их во внешнее хранилище. Это еще одно намеренно расплывчатое определение с не меньшим числом пограничных случаев.
Возможно наиболее вопиющим случаем использования мягкого кодирования, который мне доводилось наблюдать, является Корпоративный Движок Правил. Идея, стоящая за этим движком казалась довольно невинной: бизнес-правила часто изменяются, поэтому система должна поддерживать эти изменения. В результате запутанность и сложность, им порожденные, не поддавались описанию.
За год прошедший с того момента, как я впервые рассказал про Корпоративный Движок Правил, компании стоящей за его созданием удалось создать схему базы данных для хранения их бизнес-правил. Выглядит она примерно так:
Это нововведение означало, что для реализации простого правила (скажем «if (orderTotal > 50000 and ordersApproved < 3) then flagOrderForReview=true») разработчику требовалось изменить от десяти до тридцати записей в базе данных. Хотя это возможно и не звучит так уж плохо, представьте себе кишащий разработчиками этаж, которые совместно работают над этой базой данных с правилами. Сколь бы сложным не было мягкое кодирование правил при помощи C#, мягкое кодирование правил при помощи базы данных было феерически более сложным и менее продуктивным.
Пытаясь улучшить продуктивность команда (да, для поддержки этого чудовища выделена отдельная команда специалистов) Корпоративного Движка Правил вкалывает над синтаксисом языка и его синтаксическим анализатором, чтобы дать разработчикам возможность проще поддерживать эти хранящиеся в базе данных правила. Идея заключалась в том, чтобы создать Общий Бизнес Ориентированный Язык (именно так расшифровывается аббревиатура COBOL - COmmon Business Oriented Language), который был бы достаточно общим, чтобы на нем можно закодировать любое правило, не сталкиваясь между тем со сложностями настоящего кода, такими как функции и прочее. Вы только представьте себе это.
Конечно, я сомневаюсь, что среди нас есть люди настолько заблудшие, что способны создать Корпоративный Движок Правил. Но многие из нас – включая этого разработчика – случайно оказываются на пути мягкого кодирования. На этот путь легко ступить: сначала вы просто пытаетесь избежать жесткого кодирования, а потом вы уже осознаете, что барахтаетесь в море мягкого. Если взглянуть на предыдущий пример кода (attachSupplementalDocuments), на ум приходит классическое решение проблемы потенциально изменяющихся бизнес-правил – конфигурационный файл. Представляю, как многие из вас уже решили сделать конфигурируемым вышеизложенное:
{app.cfg}
#используется docMgmt.java:attachSupplementalDocuments()
LEDGER_AMOUNT_REQUIRING_AUTHLDG1A=500000
Хотя, это кажется достаточно безобидным, а для некоторых даже более ясным, это первый порочный шаг по пути мягкого кодирования.
Если каждое правило хранить в каком-то конфигурационном файле, для всех кто поддерживает программное обеспечение, жизнь станет гораздо безрадостнее: будет существовать огромное количество строк кода, которые разделяют между собой один здоровенный файл (или противоположное решение - мириады мелких конфигурационных файлов), развертывание измененных бизнес-правил потребует не нового кода, а ручного изменения конфигурационных файлов, а отлаживать подобное гораздо труднее.
Единственное правило, которое было бы позволительно изменять при помощи мягкого кодирования - это изменение объема баланса для которого требуется AUTHLDG-1A. Любое другое изменение правила потребует при реализации гораздо больше работы – конфигурирования, документирования, кодирования:
Причина, по которой мы оказываемся в пучине мягкого кодирования, заключается в том, что мы боимся изменений. Не обыкновенной боязни перемен, а того, что код, который мы пишем, придется изменять из-за изменений бизнес правила.
Это довольно глупый страх. Вся сущность программного обеспечения (потому оно собственно и программное, а не аппаратное) заключается в том, что оно может изменяться и будет изменяться. Единственный способ избавить ваше программное обеспечение от изменяющихся бизнес правил - это создать абсолютно общую программу, которая не зависит от бизнес-правил и поэтому может реализовать любое из них. Да, кстати, подобные инструменты уже изобретены. Они называются C++, Java, C#, Basic, да и Бог с ним, даже COBOL.
Эти инструменты разработаны, чтобы реализовывать очень специфичную бизнес-логику используя специфичный код. Как показывает вышеприведенный пример, нет более ясного способа воспроизвести бизнес-логику присоединения дополнительных документов. Когда меняется бизнес-логика, может измениться и код. Все просто.
Первородный страх, стоящий за страхом изменения кода - это страх перед развертыванием. Мягкое кодирование на самом деле не делает развертывание легче. И Корпоративный Движок Правил показывает нам на практике, что оно делает его даже еще труднее. А когда вы предоставляете пользователям возможность менять бизнес правила - это просто безумие.
Однако по каким-то причинам многие из нас находят развертывание мягко закодированных изменений более удобным. Кажется, уж простите за каламбур, что они проходят мягче.
Однако решение проблем с развертыванием заключается не в том, чтобы добавлять новые. А в том, чтобы выявлять реальные корни проблемы. Множество доступных сегодня инструментов позволяют вам свести процесс развертывания к простому автоматизированному сценарию, который достает код из системы управления кодом, компилирует его, копирует/устанавливает исполняемые файлы, а затем выполняет соответствующие сценарии для изменения базы данных.
Но это конечно только в том случае, если ваша программа не построена в соответствии с логикой мягкого кодирования.
Оригинал:http://worsethanfailure.com/Articles/Soft_Coding.aspx
Перевод:Евгений Виговский
| « Корпоративный Движок Правил | Убйиство процессов » |
