Вертикальная совместимость

← →
PEAKTOP © (2007-12-11 15:02) [0]

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

Имеется проект, который успешно внедряется другим отделом. Проект - кроссплатформенное клиентской приложение для доступа к СУБД (поддерживается Firebird и MySQL). Само по себе приложение ничего не умеет, оно представляет собой интерпретатор объектного языка (Pascal) и имеет дизайнер форм (как в Delphi7). На этом всем пишется конфигурация, то есть конкретная заточка по определенный вид деятельности, уже внедренцами. В результате конфигурация представляет собой саму БД и 1000..1500 текстовых файлов - ресурсов XFM и скриптов.

В текущий момент имеется стабильная версия с огромным багофиксом, и работающая как часики. Сейчас возник вопрос о доработке ядра в сторону расширения функционала, поддержка Unicode (читай переход на BDS2006/2007), переход на новые версии компонент (Indy10, TeeChart8, EhLib), переработка LINUX-овых модулей (чтобы выглядело все одинаково), кардинальная переработка некоторых вещей.

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

В общем, хотелось бы услышать мнение других.

← →
Семен Сурков (2007-12-11 15:16) [1]

Никогда ничего не переписывай с нуля. И не имхо.
Биться за старый код нужно до конца, пока силы есть.

Переработка старого *работающего проекта* путем постепенного рефакторинга по моему мнению лучшее решение в большинстве случаев.

Хотя, в конкретной ситуации все очень зависит от текущего состояния проекта.

← →
Reindeer Moss Eater © (2007-12-11 15:17) [2]

Принцип такой. Новый сервер приложений должен уметь работать со всеми версиями клиентов младше его самого. Тогда все будет ок.

← →
PEAKTOP © (2007-12-11 15:29) [3]

> Семен Сурков (11.12.07 15:16) [1]
Фактор №1 - время. И не все с нуля будем писать. Библиотеки кода никуда не денутся, никто их перерабатывать не собирается. Речь идет о 30-50 unit-ах из 380, отвечающих за "идеологию" ядра.

> Reindeer Moss Eater © (11.12.07 15:17) [2]
Ну, это понятно. но некоторые вещи будут "сноситься", это уже обговорено. Опять таки, обкатывать будем на отделе внедрения, пусть открывают новой версией старые конфигурации. И будем искать грабли. :)

Опять же, будет кое-чего выкинуто из скомпиленнго ядра в скрипты (скриптовая машина поддерживает $INCLUDE - директиву).

← →
Anatoly Podgoretsky © (2007-12-11 16:00) [4]

Переписать все нафиг :-)
Отказ от поддержки старого кода не тянет за собой его ошибок, а новые все равно создавать придется.

← →
PEAKTOP © (2007-12-11 16:10) [5]

> Anatoly Podgoretsky © (11.12.07 16:00) [4]

Совместимость обеспечивать придется. Пускай и с помощью "костылей".

При этом хочется убить и еще одного зайца: доработка механизма OpenToolsAPI, как Delphi. т.к. отдел внедрения уже просто достал просьбами: "нет редактора меню", "можно изменить редактор колонок в DBGrid" - "не, можно вернуть старый".

Имеется возможность достучаться до дизайнера объектов из скрипта и пусть сами ваяют себе редакторы объектов и свойств "под себя".

Я уже не привожу просьбы сделать интеллектуальный редактор кода.... :( Может сразу и с распознаванием устной речи :)

← →
oldman © (2007-12-11 16:13) [6]

> Проект - кроссплатформенное клиентской приложение для доступа
> к СУБД (поддерживается Firebird и MySQL).

Ничего не понял...
Если вы не меняете саму БД на фига вам совместимость?
И для совсем тупых: для доступа к БД или СУБД???

Разницу между понятиями объяснять?

← →
data © (2007-12-11 16:14) [7]

> PEAKTOP © (11.12.07 15:02)

вопрос с точки зрения бизнес-заказчиков или с точки зрения разработчиков?

Для бизнеса выгоднее постепенно наращивать функционал на старое, тк ему пофиг "новая философия" и красота кода. Ему главное, чтоб проект не стоял на месте. Тут так и получится - постепенное наращивание возможностей всей командой на уже живом, существующем проекте.

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

Я бы выбрала вариант дописывать старое. Хотя очень много зависит от проекта, команды и пр.

← →
oldman © (2007-12-11 16:15) [8]

> В текущий момент имеется стабильная версия с огромным багофиксом,
> и работающая как часики. Сейчас возник вопрос о доработке
> ядра в сторону расширения функционала

При чем тут "совместимость"???
Дорабатываете ядро и все.
У кого старая версия, просто лишится некоторых возможностей.

> oldman © (11.12.07 16:13) [6]

> Если вы не меняете саму БД на фига вам совместимость?

Имеется в виду совместимость скриптовой машины (хотя опять таки с нулевой версии поддерживается директива препроцессора IFDEF VER_NNNN) и ресурслоадера XFM (Не может он загрузить объекты с отсутсвующими свойствами - теми, которые будут "снесены").

> data © (11.12.07 16:14) [7]

> или разбивать команду разработчиков на два проекта
Никого разбивать не надо. Основной доход - отдел внедрения. Как внедряли, так и будут внедрять. Мы (разработчики ядра) их не касаемся.
Хотя, у отдела внедрения после этого появиться дополнительная нагрузка : тестить модули под новой версией в поисках граблей. Что времени не прибавит.

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

Так что не понятно что автор имеет в виду под "переписывать полностью" и уж особенно - при чем тут совместимость? Выкосить некоторые функции можно и вообще без какого-либо переписывания, если в этом собственно цель :)

Замена 15% кода не есть переписывание.
Отлаженная как часики версия исключает простой в работе внедренцев.
Разработчикам ядра все равно нечего делать, кроме как развивать ядро.
Совместимость обеспечивается сохранением старых ф-й, даже при появлении новых аналогов.
При нормальной документированности изменений тестировать надо будет по минимуму.
Так что в чем вопрос не совсем ясно.

> Сергей Суровцев © (11.12.07 20:04) [11]
> Разработчикам ядра все равно нечего делать, кроме как развивать ядро.

Все, убедил. Пойдем по пути переписывания. :)

Всем: спасибо за участие в обсуждении. Услышал много полезного.

Вертикальная совместимость - Ваше мнение Найти похожие ветки