Лучше ли использовать ранее существовавшие плохие методы или хорошие методы, которые не вписываются в старый код?

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

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

Я закончил тем, что выбрал первый вариант использования существующего плохого стиля дизайна, но у меня остался вопрос: лучше ли идти с ранее существовавшими плохими методами или реализовать хорошие методы, которые не очень хорошо работают с существующим кодом? Есть ли ситуации, в которых я должен выбрать одну над другой?

ПРИМЕЧАНИЕ. Многие ответы до сих пор связаны с медленным рефакторингом плохого кода, однако я не могу этого сделать. Код не наш, и он часто обновляется поставщиком. Я могу только строить на этом.

Вы должны выбрать лучший дизайн, если:

1. Вы собираетесь взять на себя большую часть будущего кодирования

2. Лучший дизайн не дороже для клиента в долгосрочной перспективе. Например, я был свидетелем многомесячных «рефакторингов» для проектов, которые были прекращены к концу года.

Вы должны выбрать «тот же плохой стиль», если:

1. Ты просто помогаешь. Нереально думать, что вы можете взять существующую группу и привести ее в соответствие с более высокими стандартами дизайна, если вы только частично заняты проектом. Лучший дизайн субъективен и почти всегда имеет кривую обучения. Если этот новый дизайн не изучен остальной частью команды, тогда проект закончится мешаниной стилей, и ваш лучше разработанный код может оказаться в куче вещей, которые никто не меняет, потому что они не могут понять Это. В приведенном выше примере, что произойдет, если появятся обновления стороннего программного обеспечения?

2. Принесение в жертву «лучшего» дизайна принесет вам ощутимое деловое преимущество. Как и добавление функции X, вы получите крупный контракт, но если вы пропустите крайний срок, вы ничего не получите. Вот тут-то и возникает исторический конфликт между mgmt и технической командой. Как и ремонт дома, кто-то должен решить, когда платить. Первоначально вы можете погасить долг, не имея электричества или водопровода в течение года. Или вы можете заплатить в 3 раза больше за эти утилиты.

В долгосрочной перспективе лучше использовать хорошие практики. Это сэкономит время и усилия, так как внесение изменений займет меньше времени.

Если возможно, сделайте небольшие шаги для рефакторинга в соответствии с хорошей практикой (например: в SQL, который будет разбивать денорализованные таблицы на нормализованные и использовать представления со старыми именами таблиц).

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

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

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

Теперь ваш клиент не увидит, что вы использовали лучший дизайн, он просто увидит, что ваше решение замедлило его систему. Этот тип решения должен приниматься в каждом конкретном случае, и вы должны использовать свой опыт и критерии для принятия решения.

Я думаю, что вы, вероятно, сделали правильный выбор.

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

Вы обновляете их таблицы? Если нет, то создайте представления SQL для представления этих таблиц способом, удобным для вашего приложения. Представления SQL относительно просты в написании и гораздо проще тестировать, чем код приложения.

Если вам нужно обновить устаревшие таблицы, подумайте о написании хранимых процедур для управления обновлениями. Их немного сложнее написать, но их можно проверить мгновенно.

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

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

Некоторый код можно оставить в покое; у нас не всегда есть такая роскошь.

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

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

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

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

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

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

Стоимость не рефакторинга со временем будет расти (это интересы технокального долга). Так что это в конечном итоге станет самым дорогим выбором.

Будьте уверены, что ваш начальник понимает понятие технического долга. Даже с осторожностью вы будете создавать технические долги. В какой-то момент деньги так же будут использованы для его возврата. Когда вы целенаправленно создаете технический долг, вы ДОЛЖНЫ иметь вескую причину для этого и рассматривать долг как инвестицию (точно так же, как реальный долг). В любых других случаях, просто не делайте технический долг нарочно.

Вы можете быть заинтересованы в методологиях для развития БД и развертывания этих эволюций: http://richarddingwall.name/2011/02/09/the-road-to-automated-database-deployment

Кстати, это сложная задача, так что удачи. Это того стоит !

Это типичная проблема: «Нужно ли мне пожинать плоды моей работы сейчас или позже?» и я не думаю, что когда-либо найдется общее решение для этого ответа. Только вы знаете все факторы (технические и человеческие), связанные с таким решением.

Однако ваша проблема поднимает интересный вопрос:

Достаточно ли продвигается автоматический рефакторинг кода, чтобы единообразие кода оценивалось больше?

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

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

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

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