Природные посиделки
О старых конфигурациях 1С
У одного заказчика используется 1С:Торговля достаточно старой версии на такой же старой платформе 8.2. И то, и другое уже не поддерживается 1C, никакие обновления не ставятся. Хранение данных выполнено в MS SQL старой древней, который установлен на ещё более древнем Windows Server. Конфигурация Торговли была достаточно сильно дописана на заказ именно под бизнес-процессы заказчика. И вот эта вся связка работает уже более 5 лет. Надо сказать, прекрасно работает.
Но вот новые обновления от налоговой бухучёта не ставятся. Это частично решается разовыми доработками от 1с-программиста, но не всегда завершается гладко — конфигурация сильно правленная. Узнавали сколько будет переписать конфигурацию новой УТ под бизнес-процессы и получили большое круглое число. Новая конфигурация ещё и по интерфейсу отличается и там старая логика не реализуется нормально.
С момента внедрения конфигурации прошло уже более 10 лет. СУБД, ОС и серверы, на которых это всё работает, устарели и их отдельно даже смысла обновлять нет.
Что делать? Конструктивно ничего с этим не сделать. Только делать всё наново. И в конкретно этом случае в новом решении из качественно-быстро-дешёво даже 2 пунктов не набирается.
Что сделали: оставили как есть.
Вывод: с самого начала внедрения любого продукта продумывать варианты завершения цикла его использования.
Каракол 2021
Сомневайся во всем, создавай правильное окружение
Биолог Джеймс Уотсон, один из первооткрывателей структуры ДНК в своей автобиографической книге описывает как это происходило.
Над структурой ДНК работали несколько групп, в том числе Лайнус Полинг с коллегами. Он предложил модель тройной спирали и поспешил об этом сообщить миру. Уотсон, когда узнал о модели Полинга, засомневался в её реалистичности, тройная спираль по химическим соображениям была неустойчива. Уотсон обратился к своим коллегам и те подтвердили его сомнения. Через очень непродолжительное время Уотсон, Крик и Морис предложили модель двойной спирали и опубликовали статью, за которое потом получили нобелевку.
Почему же Полинг, уже нобелевский лоуреат по химии, допустил ошибку? Одна из причин заключалась в авторитарном подходе Полинга в его лаборатории, в которой сотрудники смотрели на него как на полубожество. И когда он допустил ошибку из его окружения не нашлось никого, кто посмел бы о ней сообщить. А Полинг — прислушаться к критике.
Полинг шёл в правильном направлении — ДНК действительно имела спиральную структуру, и он был один из первых немногочисленных исследователей уже понимавших это. Всего в нескольких шагах от большого открытия, упущенного во многом из-за отсутствия обратной связи и разумной критики.
Неподдерживаемый код
Работаем с одним проектом, в котором требуется хранить большое количество картинок. Картинки хранятся на разных серверах в сетевой файловой системе mogilefs. Выбор этой системы был сделан очень давно, когда она поддерживалась разработчиками. Как иногда бывает со свободным специфическим софтом, поддержка через некоторое время закончилась, а именно с 2013 исходный код могилы не обновляется.
В продакшене могила компилировалась из исходников на тех же CentOS серверах примерно в те же годы, т.е. начало 2010-х. На тех же серверах работает код самого проекта на php 5.4 с остальным уже сильно не новым окружением. А код заказчика развивается и хотелось бы уже мигрировать новую спецификацию языка и использовать возможности новых библиотек. Но сделать это сложно.
Код скомпилироан на старом продакшене, под старые версии библиотек. Операционная система тоже не обновляется и старые репозитарии уже не доступны, а ставить по частям новые библиотеки опасно — там ещё много другого кода с зависимостями на старое и можно их поломать. Получается, что старые библиотеки нормально не обновить.
На новом продакшене с новым окружением не компилируется старый код mogilefs и его модуля для php. Ситуация осложняется тем, что могила непрозрачно хранит файлы, их из хранилища просто так не вытащить, а в базе хранятся только их могиловские идентификаторы.
Какое решение нашли? Настроили параллельно на старых и новых серверах nfs, сделали единую структуру файловой системы, путь в которой не зависит от места хранения. Далее уже задача программистов перенести файлы со старой системы на новую. Для этого написали отдельный скрипт, которой вытягивал файл со старой на новую и правил путь в базе данных. Отдельно для кода заказчика пришлось писать новый интерфейс доступа к файлам и менять старые вызовы в коде на использование этого интерфейса.
Долго запрягали, но поехали очень быстро. За половину суток скрипт обработал все файлы и доступ к ним через новый интерфейс неожиданно оказался намного быстрее. И самое главное: можно полностью избавиться от всего старого окружения.
Выводы:
- Избегать использования библиотек, поддержка которых вероятно скоро прекратится. Заранее это не всегда можно определить, но есть косвенные признаки.
- Писать код с продуманной архитектурой и интерфейсами, которые позволяют легко поменять хранилище (и не только его).
- Разделять задачу на разные уровни. Конкретно здесь хранение можно почти полностью реализовать на более низком уровне без существенного потери функционала.
- Использовать как можно более прозрачные и унифицированные инструменты.