Что Вы делаете с избыточным кодом?
Я согласен с Кшиштофом Штомпкой о разнице между:
Man.hasOne(RightArm);
RightArm.belongsTo(Man);
Я хотел бы ответить на вопрос Янцзюнь Вана :
Итак, в этом случае я должен использовать
Man.hasOne(RightArm);илиRightArm.belongsTo(Man);? Или использовать их обоих?
Это правда, что отношения Man.hasOne(RightArm); и RightArm.belongsTo(Man); делают одно и то же - каждое из этих отношений добавит внешний ключ manId к RightArm. ] таблица.
С точки зрения физического уровня базы данных эти методы делают то же самое, и для нашей базы данных не имеет значения, какой именно метод мы будем использовать.
1147 Так в чем же разница? Основное различие лежит на слое ORM (в нашем случае это Sequalize ORM, но приведенная ниже логика применима к Eloquent ] ORM Ларавела или даже к активной записи Руби ОРМ).
Используя отношение Man.hasOne(RightArm);, мы сможем заполнить человека RightArm, используя модель Man. Если этого достаточно для нашего приложения, мы можем остановиться на этом и не добавлять отношение RightArm.belongsTo(Man); к модели RightArm.
Но что, если нам нужно получить владельца RightArm? Мы не сможем сделать это, используя модель RightArm без определения отношения RightArm.belongsTo(Man); для модели RightArm.
Еще одним примером будут модели User и Phone. Определив отношение User.hasOne(Phone), мы сможем заполнить наши User Phone. Без определения отношения Phone.belongsTo(User) мы не сможем заполнить владельца Phone (например, нашего User). Если мы определим отношение Phone.belongsTo(User), мы сможем получить владельца Phone.
Итак, здесь мы имеем главное отличие: если мы хотим иметь возможность заполнять данные из обеих моделей, нам нужно определить отношения (hasOne и belongsTo) для обеих из них. Если нам достаточно получить, например, только User [1128], но не User Phone, мы можем определить только отношение User.hasOne(Phone) для модели User.
]
Приведенная выше логика применяется ко всем ORM, которые имеют отношения hasOne и belongsTo.
Надеюсь, это прояснит ваше понимание.
8 ответов
Удалите его. Вы всегда можете получить его обратно из системы контроля версий позже. У вас ведь есть контроль версий?
Как сказал Нил, удалите его. Если меня наняли для поддержки вашего проекта спустя годы после того, как вы его закончили, а он все еще полон мертвого кода ... Я буду преследовать вас. И не ооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооо более надоедливый вид преследования.
Это зависит от обстоятельств.
Если он не используется, потому что он устарел, я бы очистил его от текущей кодовой базы, удалив его. Если окажется, что он действительно нужен, вы всегда можете получить его из системы управления версиями.
Если он не используется в данный момент, но может быть использован в ближайшем будущем, я бы оставил его в текущей базе кода как Я бы не ожидал, что другие разработчики на всякий случай будут просматривать систему управления версиями в поисках функций. Другими словами: если вы удалите то, что с высокой вероятностью может быть использовано, есть вероятность, что кто-то повторно внедрит это.
Я полностью согласен с Нилом. Используйте SVN или любую другую систему контроля версий, чтобы отслеживать свой код и удалять все лишнее. Слишком много комментариев делает ваш код трудным для чтения, а в некоторых случаях невозможна отладка.
Я бы начал с пометки устаревших элементов кода атрибутом Устаревший . Таким образом вы сможете найти любой код, относящийся к устаревшим элементам, что даст вам возможность обновить эти части. Когда вы больше не получаете никаких предупреждений компилятора о том, что вы используете устаревший код, продолжайте и удалите его.
Обновление: Хорошо, теперь я думал о .NET и C #, но я уверен, что многие другие языки имеют похожие функции ...
Если он нигде не используется и больше не требуется, вы должны удалить его, чтобы избежать путаницы.
Вы не сказали, какой код вы используете, но в C # / VisualStudio вы можете использовать атрибут Obsolete, чтобы указать другим разработчикам не использовать код, вы можете установить для аргумента ошибок значение true, и это нарушит сборку везде, где используется код.
Я стараюсь как можно меньше использовать код своего приложения. Код библиотеки должен быть совместим с рядом выпусков, затем удалите его или просто пометьте как устаревший.
Лучший вариант - удалить код, чтобы получить более чистый репозиторий. В большинстве случаев это всего лишь краткосрочная угроза того, что вы удалили что-то потенциально огромное. Расчет на svn, если он понадобится товарищу-программисту позже, не сработает. Потому что вы должны знать, что код существовал раньше, а затем некоторые должны сканировать svn. Если я действительно думаю, что хочу сохранить этот код, я обычно делаю архив из файлов и добавляю их с описанием в нашу вики, а затем удаляю код. При поиске в вики кто-нибудь может найти код. Отсканируйте его с помощью архива, и, поскольку описание содержит репозиторий и номер версии, они могут даже легко восстановить нужные части.