"Осторожное" программирование
Большинство читателей, наверное, уже в курсе значения слова «хардфорк». По сути, это жесткая модификация программного кода, при которой дороги назад нет. Это слово настолько стало популярным, что часто заменяет собой обычную модификацию программного обеспечения (ПО).
Между тем, далеко не каждая модификация ПО - это «переход Рубикона». Часто у программистов есть пути оставлять за собой «мосты», чтобы в случае проблем можно было бы относительно безболезненно вернуться назад. Вот о таких «мостах» и пойдет речь в данной статье. Здесь будут описываться не сколько принципы написания кода (шаблоны, паттерны), о которых и так написаны сотни книг, сколько сам подход к выполнению изменений в ПО.
Первый принцип, которому лучше следовать при модификациях в критических системах, заключается в вынесении изменений в сторону настроек. В программе не должны быть «зашиты», те или иные параметры, которые могут в будущем меняться. Очень желательно вынести их наружу, например, в конфигурационный файл или в таблицу(-ы) базы данных (БД). Тогда любые последующие изменения этих параметров уже не потребуют работы программистов по изменению кода, что позволит снизить риск возникновения ошибок. Возможно также привлечение сопровождающего персонала к этим действиям, что особенно удобно, если программа написана какой-то сторонней организацией. Ну и особенно полезно, если программа эксплуатируется в режиме 24х7 - если она правильно спроектирована, то такие изменения даже не потребуют ее перезапуска. Да и в случае проблем, можно будет оперативно все вернуть назад, просто выставив старые значения параметров, на которых все правильно работало.
Если же простым вынесением параметров наружу при изменениях обойтись не получается и требуются изменения в нескольких важных местах системы, то при внесении изменений можно переписать код таким образом, чтобы часть функций стали более универсальными. Например, можно «превратить» часть кода в метаданные и написать для них специальный обработчик. Метаданные – это информация об информации, этакий дополнительный уровень абстракции. В простом случае даже набор параметров настройки, о которых я писал в предыдущем абзаце, также можно назвать метаданными.
Но в реальных системах одними параметрами не отделаешься, часто приходится изобретать собственный примитивный язык программирования, который используется внутри метаданных. Все это, безусловно, усложняет программный код, однако для больших систем такой подход оказывается оправданным, т.к. позволяет вносить изменения только с помощью добавления или изменения метаданных, не меняя при этом исполняемые файлы. При этом можно научить подготавливать наборы метаданных людей с более низкой квалификацией, возможно даже далеких от программирования, особенно если разработчик позаботится о создании специализированного редактора метаданных с дружественным интерфейсом. Такой подход отлично работает, когда требуется автоматизация множества однотипных задач, которые при этом еще и постоянно изменяются.
Часто бывает, что изменения в постановке задачи требуют изменения в структуре БД, например, добавить новые столбцы у таблиц или создать новые объекты. Казалось бы, при таких изменениях обратного простого пути назад нет. Но есть несколько трюков, которые можно использовать при подобных изменениях. Например, все скрипты по изменению структуры БД можно написать «повторновходимыми», т.е. так, чтобы они работали при неоднократном их выполнении. Также каждому изменению в структуре БД можно присваивать какой-нибудь уникальный номер, который хранить в специальной таблице и при необходимости в коде заложить проверку на этот самый номер. Если этого номера в этой таблице не будет, то какая-то часть программного кода работает по-старому давно отлаженному алгоритму, а если номер есть, то - по-новому. При большом количестве изменений в этой таблице можно хранить и дату/время проведения скриптов, а также их исходные коды – это может помочь при «разборе полетов».
Некоторые изменения можно проводить не сразу, а последовательно, например, сначала создать новый столбец и начать его использовать и только потом, спустя скажем месяц, удалить ранее использованные столбцы, которые больше не нужны. Такой подход позволяет в случае проблем безболезненно откатиться на старую версию программы.
Ну а самый главный принцип, который обычно игнорируют при разработке – тщательнее подходить к проектированию системы. Разработчикам очень желательно представлять в какую сторону система будет развиваться, и какие изменения могут потребоваться в будущем. Но это очень сложная задача, как правило понимание приходит только с опытом. Именно гибкость вашей системы может помочь ей в будущем выиграть конкурентную борьбу, а также значительно снизить сложность последующей модернизации.