Моє правило полягає в тому, що коли мені доведеться щось робити втретє, час або написати невеликий сценарій, щоб його автоматизувати, або переглянути свій підхід.
На даний момент я не створюю повноцінний «інструмент», лише невеликий сценарій (зазвичай bash або python; perl теж буде працювати, або навіть PHP), який автоматизує те, що я робив раніше вручну. Це в основному застосування принципу DRY (або принципу "Єдине джерело правди", що по суті одне і те ж) - якщо вам доведеться змінити два вихідні файли в тандемі, має бути якась загальна правда, якою вони поділяються, і це істину потрібно враховувати і зберігати в одному центральному місці. Чудово, якщо ви можете вирішити це внутрішньо шляхом рефакторингу, але іноді це неможливо, і саме там входять спеціальні сценарії.
Потім пізніше сценарій може перетворитись на повноцінний інструмент, але я зазвичай починаю із дуже специфічного сценарію, в якому багато речей, важко закодованих.
Я ненавиджу бурхливу роботу з пристрастю, але я також твердо вірю, що це ознака поганого чи неправильного дизайну. Бути ледачим - важлива якість програміста, і краще бути таким, коли ви проходите велику довжину, щоб уникнути повторюваної роботи.
Звичайно, іноді баланс є негативним - ви витрачаєте три години на рефакторинг коду або написання сценарію, щоб заощадити одну годину повторної роботи; але зазвичай баланс є позитивним, тим більше, якщо врахувати витрати, які не очевидні безпосередньо: людська недостатність (люди справді погані при повторній роботі), менша база коду, краща ремонтопридатність через зменшення надмірності, краща самодокументація, швидше майбутнє розробка, чистіший код. Таким чином , навіть якщо баланс з'являється негативний прямо зараз, база даних буде зростати далі, і той інструмент, який ви написали для створення веб-форм для трьох об'єктів даних, все ще працюватиме, коли у вас є тридцять об'єктів даних. На мій досвід, баланс зазвичай оцінюється на користь бурхливої роботи, ймовірно, тому, що повторювані завдання легше оцінити і, таким чином, недооцінювати, тоді як рефакторинг, автоматизація та абстрагування сприймаються як менш передбачувані та небезпечніші, а отже, завищені. Зазвичай виявляється, що автоматизація не така вже й складна.
І тоді є ризик зробити це занадто пізно: легко переробити три абсолютно нові класи об’єкта даних у форму і написати сценарій, який генерує для них веб-форми, і як тільки ви це зробите, легко додати ще 27 класів, які також працюйте зі своїм сценарієм. Але писати цей сценарій майже неможливо, коли ви досягли точки, де існує 30 класів об'єктів даних, кожен із написаними вручну веб-формами, і без будь-якої послідовності між ними (він же "органічне зростання"). Підтримання цих 30 класів із їх формами - це кошмар багаторазового кодування та напівручного пошуку-заміни, зміна загальних аспектів займає тридцять разів довше, ніж слід, але написання сценарію для вирішення проблеми, що могло б стати перервою на обід, коли ніхто не подумав, коли проект розпочався, тепер це страхітливий двотижневий проект із жахливою перспективою місячного наслідку, що складається з виправлення помилок, навчання користувачів і, можливо, навіть здавання та повернення до стара база коду. За іронією долі, написання безладу в 30 класах зайняло більше часу, ніж чисте рішення, бо ви могли весь цей час їздити на зручному сценарії. На моєму досвіді, автоматизація повторної роботи надто пізно є однією з головних проблем у довготривалих великих програмних проектах. тому що ви могли весь цей час їздити на зручному сценарії. На моєму досвіді, автоматизація повторної роботи надто пізно є однією з головних проблем у довготривалих великих програмних проектах. тому що ви могли весь цей час їздити на зручному сценарії. На моєму досвіді, автоматизація повторної роботи надто пізно є однією з головних проблем у довготривалих великих програмних проектах.
