Ведение кода: сохранение плохого паттерна при расширении нового кода для обеспечения согласованности или нет?

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

Нужно ли мне:

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

или же

• пытаться использовать то, что я чувствую себя лучше, даже если он вводит другой код в коде?

Точность отредактировано после первых ответов:

Существующий код не беспорядок. Это легко понять и понять. НО это вводит много стандартного кода, которого можно избежать с хорошим дизайном (тогда результирующему коду может стать труднее следовать). В моем текущем случае это старый добрый DAO-модуль JDBC (внутренний шаблон пружины), но я уже столкнулся с этой дилеммой и ищу другие отзывы разработчиков.

Я не хочу проводить рефакторинг, потому что у меня нет времени. И даже со временем будет трудно обосновать, что весь прекрасно работающий модуль нуждается в рефакторинге. Стоимость рефакторинга будет выше, чем его преимущества. Помните: код не является грязным или слишком сложным. Я не могу извлечь несколько методов там и ввести абстрактный класс здесь. Это скорее недостаток в дизайне (я думаю, что это результат «Keep It Stupid Simple»)

Таким образом, вопрос также может быть задан так:
Вы, как разработчик, предпочитаете ли вы поддерживать простой тупой скучный код ИЛИ иметь помощников, которые будут делать глупый скучный код у вас?

Недостатком последней возможности является то, что вам придется изучать некоторые вещи и, возможно, вам придется поддерживать простой и глупый скучный код, пока не будет выполнен полный рефакторинг)

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

В общем, старайтесь немного улучшить код всякий раз, когда вы к нему прикасаетесь. Следуйте правилу бойскаутов ( придумано Робертом К. Мартином ), оставив код чище, чем вы его нашли. Когда вы добавляете новый код, старайтесь отделить его от существующего плохого кода. Например, не хороните его в середине длинного метода, вместо этого добавьте вызов отдельному методу и вставьте туда свой новый код. Таким образом, вы постепенно увеличиваете островки чистого (er) кода в существующей кодовой базе.

Обновить

Стоимость рефакторинга будет выше, чем его преимущества. [...] Вы, как разработчик, предпочитаете поддерживать простой тупой скучный код ИЛИ иметь помощников, которые будут делать глупый скучный код на вашем месте?

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

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

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

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

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

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

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

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

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

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

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

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

Обновление, касающееся ответа Петера Торока: не откладывает ли рефакторинг «потому что это требует времени», время на его рефакторинг в более позднее время увеличивается? Рефакторинг не должен занимать много времени, когда это делается чаще.

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

Разве вы не можете создать новый Интерфейс / Классы, который работает как Фасад поверх старого кода, при этом вводя новый код в своем собственном стиле, который можно легко расширить?

Делай это правильно, идя вперед. Используйте функции вместо вырезания и вставки. Это не требует рефакторинга, но дает вам основу для будущего рефакторинга.

Вы, как разработчик, предпочитаете поддерживать простой тупой скучный код ИЛИ иметь помощников, которые будут делать глупый скучный код у вас?

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

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

Если рефакторинг не вариант, вопрос становится скорее обсуждением правильного времени, места и т. Д. Для этого. Последовательность очень важна. И все же долгоживущий код часто выигрывает от «обновления». Другие обсуждали это ...