Успадкування проектів WordPress: поради щодо розробки
Якщо ви керуєте компанією, яка зосереджена як на розробці рішень з нуля, так і на впровадженні спеціального рішення в контексті вже існуючих проектів (або, можливо, на обох), то ви, ймовірно, – у якийсь момент – був у ситуації успадкування проектів WordPress.
Розгляд проектів з будь-якої сторони пов’язаний із набором труднощів – більшість із них вітаються – але, здається, люди набагато частіше скаржаться на роботу з уже існуючою кодовою базою.
Справа не в тому, що я не відчуваю цього, але я вважаю, що в цьому є певна незрілість. З одного боку, так, деякі кодові бази просто жахливі. Але деякі кодові бази не такі вже й погані. Насправді я б стверджував, що вони просто трохи відрізняються від того, як ви це розробили.
Це той випадок, коли стандарти вступають у гру, але я поки що відступлю від цього.
Тож припустімо, що ви успадковуєте проекти WordPress і вас не особливо влаштовує кодова база, з якою ви працюєте. Як виходить, що ви все ще можете насолоджуватися роботою, яку ви робите, не відчуваючи, що вам потрібно критикувати кожен аспект того, з чим ви маєте справу?
Успадкування проектів WordPress
По-перше, це поняття скаржитися на роботу інших людей – це прислів’я, у якому я не люблю топтатися.
- Я не знаю передумов, які призвели до того, що кодова база перебуває у своєму стані,
- Я не знаю, чому певні речі були розроблені так, як вони були (обмеження часу, відсутність знайомства з проектом тощо),
- Мені доручено щось робити в контексті проекту, тож навіщо витрачати час на те, що не входить до моїх обов’язків?
Я розумію: бувають випадки, коли код, який ми пишемо, має спілкуватися з кодом, який уже існує. І це може бути важко. Є шаблони проектування, які не призначені спеціально для цієї ситуації.
Але замість того, щоб розповідати про це, я подумав поділитися трьома речами, які, на мою думку, демонструють зрілість, коли йдеться про розробку, коли ми успадковуємо проекти WordPress, які можуть нас дратувати.
1 Не рефакторингуйте все
Як сказав Мартін Фаулер :
Цей опортуністичний рефакторинг дядько Боб називає дотриманням правила бойскаутів – завжди залишайте код у кращому стані, ніж ви його знайшли.
Загалом, мені подобається це правило, але залежно від вимог проекту це може виходити за межі нашої відповідальності.
Тому щоразу, коли ми стикаємося з чимось, що, як ми знаємо, потребує рефакторингу, але проект працює гладко. Якщо ви вносите одну зміну в щось, тому що вважаєте, що це потрібно зробити, ви не знаєте, як це відобразиться на всьому проекті.
Якщо у вас є час провести повний аудит коду, це одне, але якщо ні, то ваше завдання полягає в тому, щоб представити те, що ви погодилися зробити.
2 Зосередьтеся на тому, що ви погодилися зробити
І це веде до наступного: коли успадковуєте проекти WordPress, вам доручають певний обсяг роботи і нічого більше (саме тому у нас є технічний запис, чи не так?).
Тому, незважаючи на те, як сильно ви хочете змінити середовище, в якому ви перебуваєте, не робіть цього. Зосередьтеся на тому, що ви можете зробити, що можете зробити тільки ви і що ви погодилися зробити.
Я вважаю, що це добре робити нотатки про проблеми, і я думаю, що це може бути навіть корисним (і я зараз поговорю про це), але не втрачайте зосередженість на тому, що ви погодилися зробити. Робити будь-що, але це непрофесійно.
3 Не судіть попереднього розробника
Ще одна поширена річ – особливо у відкритому коді – це судити розробника, який написав початковий набір коду, з яким ви працюєте.
Що це? Я б ніколи не написав це так.
Я маю на увазі, скільки разів ми про це думали? Але ми не знаємо часу, обмежень, досвіду чи контексту, в якому працював розробник.
Код, який ми випускаємо, не обов’язково відповідає нашому рівню кваліфікації. Це часто продиктовано сторонніми змінними, які впливають на те, як ми реалізуємо рішення.
І ми знаємо, що це таке, чи не так? Скільки разів ми хотіли зробити щось одним способом, але обмеження та графік, за яким ми працюємо, диктують, що ми робимо?
Тож чому ми очікуємо, що ці розробники будуть іншими?
Додатково: Пропонуйте майбутню підтримку
Як згадувалося раніше, якщо ви натрапите на проблемні ділянки кодової бази, це не означає, що справа програна.
Натомість, коли ви стикаєтеся з такими проблемами, я вважаю, що було б гарною ідеєю:
- робити нотатки про те, що ви бачили,
- поясніть, що ви зробили б, щоб це виправити, і чому,
- поговоріть із клієнтом про те, що ви бачили, і про переваги його оновлення.
Це, очевидно, веде до майбутньої роботи, але, можливо, понад це, це дозволяє вам пропонувати рішення для створення кращого, добре архітектурного програмного забезпечення, і це дозволяє переконатися, що ви робите Інтернет кращим місцем для такої популярної CMS.
Ні, ця робота ніколи не гарантується, але вона корисна.
Я впевнений, що є більше
Це лише три поради, які я пропоную на основі досвіду, який я отримав під час успадкування проектів WordPress. Воно не повинно бути всеохоплюючим.
Натомість він має на меті надати кілька порад, які дозволять вам уважніше ставитися до роботи інших людей у зв’язку зі своєю роботою, чіткіше думати про те, що ви можете робити, коли стикаєтеся з подібними ситуаціями, і отримати більше роботи, покращуючи існуючу рішення потенційно.
Але я знаю, що те, про що я згадав, — це лише частина моїх спостережень. Маєш свій? Згадайте їх у коментарях.