Комментарий на статью Мягкое кодирование

Письмо, на котором основывалась сегодняшняя статья, было отозвано. Вместо нее я воспользуюсь случаем и представлю практику мягкого кодирования.

Многие программисты считают «Жесткое Кодирование» (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");
  }
}

Я уже слышу, негодующие крики: волшебные числа, строковые литералы, фуу, да это же все жесткое кодирование! Однако ни единый символ в этом примере не является жестко закодированным: в вышеприведенном примере нет ничего «чего не должно быть в исходном коде». Функция просто реализует очень ясное и очень специфическое бизнес-требование посредством очень ясного и специфического кода. Если хоть что-то убрать, это уже будет закодировано мягко.

Это приводит нас к определению мягкого кодирования: практике удаления «вещей, которые должны быть в исходном коде» из исходного кода и перемещения их во внешнее хранилище. Это еще одно намеренно расплывчатое определение с не меньшим числом пограничных случаев.

Снова о Корпоративном Движке Правил

Возможно наиболее вопиющим случаем использования мягкого кодирования, который мне доводилось наблюдать, является Корпоративный Движок Правил. Идея, стоящая за этим движком казалась довольно невинной: бизнес-правила часто изменяются, поэтому система должна поддерживать эти изменения. В результате запутанность и сложность, им порожденные, не поддавались описанию.

За год прошедший с того момента, как я впервые рассказал про Корпоративный Движок Правил, компании стоящей за его созданием удалось создать схему базы данных для хранения их бизнес-правил. Выглядит она примерно так:

• Fields (FieldId, DataTypeId, FieldName)
• Atoms (AtomId, Field1Id, OperatorId, Field2Id)
• AtomSets(AtomSetId, AtomId)
• AtomGroups(AtomGroupId, AtomSetId, BooleanId)
• AtomGroupSets(AtomGroupSetId, AtomGroupId)
• … и так далее

Это нововведение означало, что для реализации простого правила (скажем «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. Любое другое изменение правила потребует при реализации гораздо больше работы – конфигурирования, документирования, кодирования:

• AUTHLDG-1A не присоединяется, если уровень обслуживания клиента как минимум равен трем
• CRTAUTH-CA1 должен быть присоединен в дополнение к AUTHLDG-1A
• AUTHLDG-2A должен быть присоединен вместо AUTHLDG-1A, если объем баланса превышает 1000000

Между жестким и мягким кодом

Причина, по которой мы оказываемся в пучине мягкого кодирования, заключается в том, что мы боимся изменений. Не обыкновенной боязни перемен, а того, что код, который мы пишем, придется изменять из-за изменений бизнес правила.

Это довольно глупый страх. Вся сущность программного обеспечения (потому оно собственно и программное, а не аппаратное) заключается в том, что оно может изменяться и будет изменяться. Единственный способ избавить ваше программное обеспечение от изменяющихся бизнес правил - это создать абсолютно общую программу, которая не зависит от бизнес-правил и поэтому может реализовать любое из них. Да, кстати, подобные инструменты уже изобретены. Они называются C++, Java, C#, Basic, да и Бог с ним, даже COBOL.

Эти инструменты разработаны, чтобы реализовывать очень специфичную бизнес-логику используя специфичный код. Как показывает вышеприведенный пример, нет более ясного способа воспроизвести бизнес-логику присоединения дополнительных документов. Когда меняется бизнес-логика, может измениться и код. Все просто.

Страх перед развертыванием.

Первородный страх, стоящий за страхом изменения кода - это страх перед развертыванием. Мягкое кодирование на самом деле не делает развертывание легче. И Корпоративный Движок Правил показывает нам на практике, что оно делает его даже еще труднее. А когда вы предоставляете пользователям возможность менять бизнес правила - это просто безумие.

Однако по каким-то причинам многие из нас находят развертывание мягко закодированных изменений более удобным. Кажется, уж простите за каламбур, что они проходят мягче.

Однако решение проблем с развертыванием заключается не в том, чтобы добавлять новые. А в том, чтобы выявлять реальные корни проблемы. Множество доступных сегодня инструментов позволяют вам свести процесс развертывания к простому автоматизированному сценарию, который достает код из системы управления кодом, компилирует его, копирует/устанавливает исполняемые файлы, а затем выполняет соответствующие сценарии для изменения базы данных.

Но это конечно только в том случае, если ваша программа не построена в соответствии с логикой мягкого кодирования.

Оригинал:http://worsethanfailure.com/Articles/Soft_Coding.aspx
Перевод:Евгений Виговский