Хорошая идея?

Question

У нас есть «устаревшее» приложение, написанное на C ++ / powerbuilder, работающее на Unix с собственными базами данных Sybase. Для сложной организационной структуры (существующие приложения должны пройти через много бюрократизма, чтобы быть модифицированным) и по причинам кода (рефакторинг не выполнялся в течение года, поэтому код является спагетти), поэтому сложно внести изменения в это приложение. Поэтому я планирую написать новое современное веб-приложение, основанное на Grails, для того, чтобы сделать некоторые вещи типа «администратор» непосредственно в базе данных. Например, чтобы добавить пользователей или добавить «строки ограничений».

Что сообщество разработчиков программного обеспечения думает об этом подходе к обходу существующего приложения, как это? Отличная идея? Советы и подсказки?

Answer 1

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

Answer 2

Хорошая идея? Это зависит от того, насколько хорошо база данных задокументирована и / или понята. Сделайте ошибку в каком-то неявном правиле, отношении или ограничении, реализованном на уровне приложения, и ваше устаревшее приложение может в конечном итоге сделать колесико по проходу.

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

• app_users
• app_constraints
• app_permissions
• user_address

Предположим, вы поймали первые три, пропустили четвертое. Это не может быть важно, верно? Но что если в приложении из 50 мест, где используется app_users, одно место выполняет внутреннее соединение с user_address. (А почему бы и нет? Автор приложения знал , что он всегда записывал запись в user_address!) Недавно добавленный пользователь внезапно исчезает из поля зрения приложения, что, по мнению исходного кодера, «никогда не могло произойти», и приложение кашляет волосяного покрова. Заказы не могут быть приняты. Производство останавливается. Вице-президент ставит свою новую операцию по шунтированию сердца.

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

Удачи,

Терри.

Answer 3

См. это от Джоэла, сначала!

Обновление: я несколько неправильно истолковал вопрос и подумал, что переписывается больше.

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

Во-первых, это может быть самый быстрый путь к желаемому результату, так как со старым кодом очень трудно работать.

Во-вторых, это дает вам опыт работы с новой технологией разработки и делает это в контексте вашей существующей работы - это реальное преимущество.

В-третьих, я использовал этот подход несколько лет назад, когда переводил приложение с C ++ на Delphi. Со временем приложение Delphi стало настолько способным, что стал возможен полный скачок на эту платформу. Ни в коем случае пользователи не были без функциональности, которую они уже знали, потому что старое приложение не было прекращено, пока функциональность замены не была доказана. Однако именно на этом этапе вы захотите прислушаться к предупреждениям Джоэла: помните, что некоторая «грязь», которую вы видите, на самом деле является знанием, воплощенным в старом коде.

Answer 4

Хорошая идея? Нет.

Иногда необходимо? Да.

Жизнь в мире, где вам иногда приходится делать то, что вы знаете, не является хорошей идеей? Бесценный.

В общем, вы всегда должны следовать лучшим практикам. Для всего остального есть кладжи.