Є один загальний принцип, який регулює необхідність рефакторації та оптимізації, як у водоспаді, так і у Agile: YAGNI (You Ant't Gonna Need It). Другим принципом є наслідок першого: "Передчасна оптимізація - корінь усього зла", кодуючий еквівалент загального прислів'я "ворог досконалості - досконалість".
Візьмемо принципи та застосуємо їх. У вас є вимога побудувати алгоритм ETL, який приймає файл певного типу, витягує його інформацію, а потім заносить цю інформацію в базу даних. Ваша мета цього тижня (для наших цілей неважливо, чи є ви в Agile або SDLC-магазині) - це досягти.
Ти розумний хлопець, і тобі дали уяву про велику картину. Ви знаєте, що це не єдиний тип файлу, для якого проекту знадобиться ETL. Отже, ви розглядаєте можливість реалізації цього алгоритму ETL для роботи над іншим типом файлів, які мають лише незначні відмінності. Це може порушити YAGNI. Ваше завдання - не розробити алгоритм для цього іншого файлу; це розробити алгоритм для одного файлу, який потрібен до кінця тижня. Щоб досягти цієї мети і пройти тести прийняття, вам потрібно розробити цей алгоритм і змусити його правильно працювати. Вам "не знадобиться" додатковий код, щоб він працював з іншим файлом. Ви можете подумати, що це заощадить ваш час, щоб включити його зараз, і ви можете мати рацію, але ви також можете страшенно помилитися; алгоритм для іншого файлу, можливо, потрібно буде використовувати в області системи, коду не можна використовувати, або вимоги до нового файлу можуть бути іншими, ніж для вашого способу, якого ви не знаєте (у Agile, ці вимоги можуть ще не існувати). Тим часом ви витратили час і зайво збільшили складність свого алгоритму.
Тепер на наступний тиждень, і як сумнівна нагорода за відмінну роботу над першим алгоритмом, вам дали завдання створити алгоритми для двох нових типів файлів. Тепер вам потрібен додатковий код, щоб ваш алгоритм працював з більшою кількістю файлів. Ви можете розширити свій існуючий алгоритм, використовуючи шаблон шаблону методу, який буде використовувати базовий шаблон з окремими окремими кроками, або ви можете просто отримати спільний інтерфейс із наявного алгоритму, розробити два нових, які слід за інтерфейсом, і підключити їх до об’єкт, який може вибрати, який алгоритм використовувати.
Під час розробки ви знаєте, що у вас є вимога, щоб система могла обробляти 10 КБ необроблених даних за секунду. Ви робите тест навантаження та знаходите, що ваш початковий алгоритм чернетки обробляє 8 КБ / с. Ну, це не передасть ААТ. Ви подивіться і побачите, що у вашому алгоритмі є якась структура циклу комплексності O (мій Боже); ви впорядкуєте його і отримаєте 12 КБ / с. "Дуже добре", ви думаєте, "але якщо у мене була бідна петля в коді, що ще я можу збрити?". гудіти Ви просто порушили «передчасної оптимізації» правила. Ваш код працює і проходить усі вимоги. Ви готові до тих пір, поки вимоги не будуть оновлені, щоб вимагати 15 КБ / с. Якщо і коли це трапиться, ТОГО ви потягнете код назад і шукаєте, щоб покращити.
Дотримуйтесь цього простого процесу, розробляючи, будь то в Agile або в традиційних SDLC: "На першому проході змусьте його працювати. На другому проході зробіть його гарним. На третьому проході зробіть його твердим". Це означає, що коли ви вперше створюєте рядок коду, змушуйте цей код виконувати свою роботу правильно і без помилок, але не звертайте занадто багато уваги на правила дизайну в цьому коді, як на все, що ви зараз знаєте " Ніколи більше не торкайтесь цієї області. Наступного разу, коли ви відвідуєте цей рядок коду, ви просто довели себе неправильно; це вже не одноразова частина системи. Refactor - це для читабельності, стиснення коду та / або принципів DRY (можливо, ви можете скопіювати якийсь код, щоб зробити щось п’ять разів; рефактор, який перебуває у циклі та / або виклик методу). Третій раз ви працюєте в цьому рядку коду чи навколо нього,
O(my God)-complexityякщо нічого іншого не змусило мене сміятися!