Дорога в совершенство

Вот и созрел я для очередного поста в этом забытом всеми блоге )
Вопреки собственным ожиданиям, текст не будет связан ни с явой, ни с асп,
да и вообще будет носить скорее философский характер.

К чему это все? Да к тому, что идеальных программ не бывает.
И часто нужно добавлять функционал в ходе поддержки и эволюции проекта,
причем зачастую в самых неожиданных местах.

Вопрос: каким свойством должен обладать любой мало-мальски крупный и хороший продукт?

Правильно, масштабируемостью. Чего часто не понимают, так это того,
что масштабируемость должна быть не столько возможной, сколько простой и понятной.
Программисты, осуществляющие сопровождение (а не разработку) данного продукта
должны иметь возможность не лазить в недра кода каждый раз, когда один из клиентов
захочет что-то изменить в своей конкретной копии продукта.

Например, сегодня я столкнулся с тем, что один из наших клиентов использует нестандартную
структуру базы данных. Их база ориентирована на Казахстан и, соответственно, имеет функционал
для поддержки тамошних национальных стандартов.
А сейчас нам нужно подцепить эту ихнюю "самопальную" базу к нашему интерфейсу
(и не только интерфейсу), который уже изрядно поменялся с тех пор, как они стали развивать
свою собственную наработку.

Для наглядности поясню - база, с которой я имею дело, не то,
чтобы очень объемная, но и не маленькая. В ней порядка полусотни таблиц
и несколько сотен хранимок. В результате поверхностного сравнения я пришел к выводу,
что процентов 25 наших объектов не имеют аналогов в казахской базе.
Таким образом нужно ручками их там создать и по возможности скопировать их содержимое
А ведь есть еще и немало тех, которые имеют аналогов, но не совпадают с ними именами
(а имена в той базе, между прочим, на казахском).
И вот как их переделать, я пока не представляю...

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

Достаточно было просто ввести один уровень абстракции - между базой и приложением.
Тот же самый подход, который сейчас применяется в Java
для хранения состояний объектов (Hibernate).
Таким образом изменение названий или даже полностью структуры базы
привело бы максимум к нескольким переписанным сторчкам в настройках,
т.к. все привязки остались бы для приложения в неизменном виде.

Еще одна немаловажная часть масштабируемости - самовоссоздание структуры базы.
Нельзя все время рассчитывать, что база неизменна.
В случае падения ее, такой подход дает возможность поднять базу заново все парой кликов.
А в нашем случае, если реализовать все правильно, дал бы автоматическую перенастройку
синонимов таблиц путем сравнивания структур этих самых таблиц
(т.е. те самые сложные случаи, когда изменилось название таблицы на неизвестное,
автоматически бы анализировались и чинились).

Последние новости