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