Чи краще використовувати наявні погані практики чи добрі практики, які не відповідають старим кодам?

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

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

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

ПРИМІТКА: Багато відповідей поки що пов'язані з повільним рефакторированием поганого коду, однак я не в змозі цього зробити. Код не наш, і він часто оновлюється постачальником. Я можу лише будувати на ньому.

Ви повинні вибрати кращий дизайн, якщо:

1. Ви збираєтеся перейняти значну частину майбутнього кодування

2. Кращий дизайн не є дорожчим для клієнта в довгостроковій перспективі. Наприклад, я був свідком багатомісячного "реконструкції" проектів, які були припинені до кінця року.

Ви повинні вибрати "такий же поганий стиль", якщо:

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

2. Пожертвуючи «кращим» дизайном, ви отримаєте відчутну перевагу в бізнесі. Як додавання функції X погано, ви отримаєте великий контракт, але пропущення терміну заставить вас закінчитися нічим. Тут відбувається історичний конфлікт між mgmt та технічною командою. Як і ремонт будинку, хтось повинен вирішити, коли платити. Ви можете погасити борг спочатку, проживаючи без електрики та сантехніки протягом року. Або ви можете заплатити в 3 рази більше, якщо ви будете мати ці комунальні послуги.

Зрештою, краще використовувати добрі практики. Це заощадить час та зусилля, оскільки для впровадження змін потрібно менше часу.

Якщо це можливо, зробіть невеликі кроки, щоб повернути рефактор до належної практики (наприклад: у SQL, який би порушував деноралізовані таблиці до нормалізованої та використовував представлення зі старими назвами таблиць).

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

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

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

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

Я думаю, ви, мабуть, зробили правильний вибір.

Наскільки це можливо, вам слід ізолювати код програми від поганої конструкції даних.

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

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

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

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

Деякий код можна залишити в спокої; у нас не завжди така розкіш.

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

Час Develloper коштував грошей, тому технічний борг можна розглядати як реальний борг, так і коштувати реальні гроші.

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

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

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

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

Вартість не рефакторингу зростатиме з часом (це інтереси техногенної заборгованості). Тож це з часом стане найдорожчим вибором.

Будьте впевнені, що ваш начальник розуміє поняття технічної заборгованості. Навіть з обережністю ви створите технічну заборгованість. У якийсь момент гроші, які будуть використані для повернення коштів. Коли ви спеціально створюєте технічну заборгованість, у вас є вагома причина цього і бачите борг як інвестицію (як і реальний борг). У будь-яких інших випадках просто НЕ ДАЙТЕ технічну заборгованість спеціально.

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

До речі, це непросте завдання, тож удача. Варто!

Це типова проблема: "Мені потрібно скористатися перевагами своєї роботи зараз чи пізніше?" і я не думаю, що на цю відповідь ніколи не може бути загального рішення. Тільки ви знаєте всі фактори (технічні та людські), які беруть участь у такому рішенні.

Однак ваша проблема викликає цікаве питання:

Чи достатньо прогресує автоматичний рефакторинг коду, щоб однаковість коду повинна цінуватися більше?

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

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

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

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