Обслуговування коду: зберігати поганий зразок при розширенні нового коду на постійність, чи ні?

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

Чи я повинен:

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

або

• спробуйте використовувати те, що мені здається краще, навіть якщо це вводить інший зразок у код?

Точність відредагована після перших відповідей:

Існуючий код - це не безлад. Це легко простежити і зрозуміти. АЛЕ це введення безлічі кодового коду, якого можна уникнути при гарному дизайні (в результаті цього код може бути важче слідувати). У моєму теперішньому випадку це старий хороший модуль DAO JDBC (весняний шаблон на борту), але я вже стикався з цією дилемою і шукаю відгуків інших розробників.

Я не хочу переробляти, бо не маю часу. І навіть з часом важко буде виправдати, що цілий ідеально працюючий модуль потребує рефакторингу. Вартість рефакторингу буде важче, ніж його переваги. Пам'ятайте: код не є безладним або надмірно складним. Я не можу витягнути там мало методів і ввести сюди абстрактний клас. Це більше вада в дизайні (я думаю, результат крайнього "Keep It Stupid Simple")

Тож питання також можна задати так:
Ви, як розробник, ви віддаєте перевагу підтримувати легкий дурний нудний код АБО мати деяких помічників, які зроблять ваш дурний нудний код?

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

Рефакторинг найкраще проводити невеликими кроками, і бажано, лише якщо у вас є одиничні тести для покриття коду. (Отже, якщо у вас ще немає тестів, прагніть їх написати спочатку, а до цього - дотримуйтесь найпростіших, найбезглуздіших, бажано автоматизованих реконструкцій. Відмінна допомога в цьому - ефективна робота зі застарілим кодом Майкла Перу.)

Загалом, прагніть трохи вдосконалити код, коли ви торкаєтесь його. Дотримуйтесь Правила скаутів хлопчика ( придуманий Робертом К. Мартіном ), залишаючи код чистішим, ніж ви його знайшли. Коли ви додаєте новий код, намагайтеся не відривати його від існуючого неправильного коду. Наприклад, не закопуйте його в середину тривалого методу, замість цього додайте виклик в окремий метод і вкладайте туди свій новий код. Таким чином, ви поступово збільшуєте великі острови чистого (ер) коду в межах наявної кодової бази.

Оновлення

Вартість рефакторингу буде важче, ніж його переваги. [...] Ви, як розробник, ви віддаєте перевагу підтримувати легкий дурний нудний код АБО мати деяких помічників, які зроблять ваш дурний нудний код?

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

Як творчий розум, звичайно, я вважаю за краще створити ідеальний, красивий та елегантний код та переписати все, що не нагадує мої ідеали :-) Насправді, я дійсно плачу, щоб створити програмне забезпечення, яке вирішує справжні проблеми для його користувачів, тому я слід подумати про створення найбільшої вартості своїх грошей у довгостроковій перспективі.

Користь від рефакторингу з’являється лише за умови достатньої економії часу та зусиль для розуміння, підтримки, виправлення та розширення коду в довгостроковій перспективі . Тож якщо шматок коду - як би це не потворно - рідко або ніколи не торкався, в ньому немає жодних відомих помилок, і я не знаю жодних майбутніх функцій в осяжному майбутньому, які вимагали б від нього торкнутися, я вважаю за краще залишити це в мирі.

Оскільки у вас немає часу на рефактор, і код є доступним, дотримуйтесь його. Наступного разу обов'язково включіть в оцінку рефакторинг.

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

Якщо ви переймените код на змістовні функції, наступному хлопцеві буде легше зрозуміти, що відбувається, і йому потрібно буде докласти менше зусиль, щоб додати свої зміни. Думай про це так. Припустимо, наступний хлопець - це ти. Що б ви хотіли бачити, переглядаючи цей блок коду, той самий безлад, який ви дивитесь зараз, або щось більш логічно побудоване?

Консистенція має високий пріоритет. Очевидно, кожен, хто має розум, віддасть перевагу елегантному DRY-рішенню скрізь, а не скріпленому копіювальним шаблоном скрізь, але чи дійсно ви б віддали перевагу двом різним підходам в одній і тій же кодовій базі, щоб послідовно застосовувати один? Що робити, якщо хтось винайде ще розумніше рішення, а також застосує його непослідовно? Тоді у вас є три різні способи зробити те саме.

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

Можливо, ви могли б розглянути можливість рефакторингу меншими кроками, таким чином, щоб кожен крок можна було застосувати по всій базі коду за один раз. Напр. витягування меншої частини котлоагрегату до функції помічника при кожній ітерації. З часом ви потрапляєте з усіма котлами в клас помічників. Це може виглядати по-справжньому некрасиво, оскільки він не був розроблений, а вирощений, але ви можете це виправити зараз, оскільки у вас є весь код в одному місці.

Будь-який рефакторинг, що виключає повторюваний код, є хорошим рефакторингом, і його не слід відкладати, якщо не настає термін. Час, витрачений на рефакторинг один раз, легко компенсується часом, виграним у майбутніх реалізаціях. Завдяки рефакторингу внутрішня робота більше не видно, тому її слід легше зрозуміти, а не важче дотримуватися.

На мою думку, поширене неправильне уявлення про те, що реконструйований код важче дотримуватися. Зазвичай це аргумент людей, які лише знайомі з тим, що відбувається після реконструкції, а не з результатом реконструкції. Для новачків результат реконструкції буде чіткішим.

Будь-які помилки / функції можуть бути виправлені / реалізовані в центральному місці згодом, і вони автоматично доступні всюди у вашій програмі. Це величезний приріст, який зазвичай сильно занижений. Взагалі загальний рефакторинг компонента не займе багато часу. (дні замість місяців) Якщо порівнювати цей час із втраченою через помилки, розуміючи код, який міг бути відновлений, вартість рефакторингу стає мінімальною.

Оновлення, що стосується відповіді Петера Тьорека: Чи не відклавши рефакторинг "тому що це потребує часу", час на його рефакторинг збільшується на більш пізній час? Реконструкція не повинна зайняти багато часу, коли робиться частіше.

Як пояснити своєму начальникові, що ви витратите кілька днів на написання коду, який нічого не додає до продукту, важко, і це зовсім інше питання. :)

Ви не можете створити новий інтерфейс / класи, які працюють як фасад над старим кодом, вводячи новий код у власному стилі, який можна легко розширити?

Зробіть це правильно, рухаючись вперед. Використовуйте функції замість різання та наклеювання. Це не вимагає рефакторингу, але це дає вам початок фундаменту для майбутнього рефакторингу.

Ви, як розробник, ви віддаєте перевагу підтримувати легкий дурний нудний код АБО мати деяких помічників, які зроблять ваш дурний нудний код у вас?

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

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

Якщо рефакторинг не є можливим, тоді питання стає більше дискусією про правильний час, місце тощо ... для цього. Консистенція дуже важлива. І все-таки довгоживучий код часто виграє від "оновлення". Інші обговорили це ...