Като разработчици правим различни видове грешки в различни моменти от нашата кариера. По-специално при разработването на WordPress, ние допускаме различни видове грешки, тъй като познаването ни с кодовата база на WordPress расте.
Преди няколко години чух Мат Мюленвег да обявява нещо, че повечето хора повтарят грешките си, по-умните хора се учат от грешките си, а най-умните хора сред нас се учат от грешките на другите . Това по-скоро ми харесва и бих добавил следствие: Всеки прави грешки, смирените хора споделят тези грешки насаме и най-смелите сред нас ги записват и публикуват в блог!
Но има време за размисъл по-късно. Вие четете тази статия, защото искате да чуете за влакова катастрофа, а аз съм инженерът. Без допълнителни преамбюли, присъединете се към мен с поглед назад с ужас към петте най-смущаващи грешки, които съм допуснал като разработчик на WordPress.
Тъкмо завърших да правя много неясни концертни програми на CraigsList, за да работя в действителна агенция на живо. Бях пристигнал! Бях изнервен да работя от друго място, освен от дивана, в нещо различно от пижамата си. Но дори тогава обикновено познавах WordPress още от WordPress Doing It Wrong и ми се стори приятно самовъзвесяващо да се хваля с Най-добри практики за WordPress , като никога „хакерско ядро“.
Моят първи Разработка на WordPress задачата на тази агенция беше да поднови закъсал проект - доста сложен за моите умения по това време. Той включваше много персонализации на регистрацията в WordPress и потока за вход. Предишният разработчик беше известен като постигнал значителен напредък, като просто редактира ядрото wp-login файлове.
Знаех, че това е неустойчиво, затова първата ми поръчка беше да инсталирам приставка за архивиране / възстановяване и да замествам ядрото на WordPress с прясно изтеглена версия. Бях уверен, че към момента в проекта не е изпълнено нищо ужасяващо впечатляващо и че ще мога да имитирам съществуващия набор от функции чрез филтри.
Каквато и да е способност за кодиране, която можех да имам или не в този момент, бързо стана без значение, тъй като новият ми работодател кипеше лудо. Тя не разбираше значението на „хакерското ядро“ и аз не бях достатъчно зрял, за да го обясня по смилаем начин. Единственото нещо, което временно охлаждаше челото й, беше, когато я уверих, че мога да се върна чрез добавката за архивиране / възстановяване, която инсталирах.
Можете ли да познаете къде отива това?
Този плъгин, според съдбата, само архивира wp-content папка. Каквито и да са били хакерите на WordPress в тези основни файлове, са изчезнали завинаги. Все още си спомням имейла си до нея (тя отдавна ме беше прогонила обратно в домашния ми офис до този момент):
Момчета, не мога да направя резервното копие.
Наистина бях готов да завърша желания от нея набор от функции чрез филтри и действия, но тя не го чу. Тя ме уволни на място, заплаши да ме съди и никога не ми плати за две седмици много тежък труд. Бях толкова унижен.
Има много (сега очевидни) неща, които бих могъл да науча от този опит. Общият урок, че архивирането не е резервно копие, докато не бъде репетирано и потвърдено, е добър. Но този, който остана с мен повече, е конкретен урок за как точно за архивиране в WordPress - особено с WordPress ядро.
Научих се наистина да ценя управлявана среда като WP-Engine, със здрава система за архивиране / възстановяване. Много домакини на бутици разполагат с различни инструменти на командния ред и други функции, насочени към разработчици, за извършване на архиви, но WP-Engine's ми е любим. Това е доста бързо, освен ако нямате много голяма мрежа. Потребителският интерфейс е прост. То има потребителски интерфейс, точка: Всеки, който знае как да използва WordPress, може да работи с това. Т.е., за разлика от някакъв CLI подход, който вероятно е много по-бърз, или някакво неясно нещо, заровено в Plesk, клиентите ми могат да използват това, да го разберат, да го наблюдават и да проверят дали го използвам. Аз съм голям фен.
Все още бях сравнително нов на професионалното работно място и винаги съм бил човек с Windows. Новата ми работа обаче беше в магазин за Mac и се научих много бързо да обичам всичко по въпроса. Е, почти всичко. Изглежда имах много проблеми с „вълшебната мишка“. Имах тенденция да загубя Bluetooth връзката си, което доведе до случайни и често плашещи действия при плъзгане и пускане, след като се свърже отново. Нещо повече, бях просто несръчен с ново фино моторно умение.
Още в наши дни нашият поток за разработка на WordPress все още включваше внедряване в производството чрез FTP. Не беше необичайно да прекарвам цели делнични дни в писане на код, чат, отговаряне на имейли, като обикновено се въртях насам-натам чрез новата ми магическа мишка, с Cyberduck, отворен за производство на работния ми плот. Боже, звучи ли зле! Но ето как беше
Един ден цялата ни платформа просто изчезна. Нашият системен администратор бързо прие, че това е някакъв вид DDoS или нещо общо на негово ниво. Що се отнася до нас разработчиците, ние се доверихме на неговите инстинкти и предположихме, че той ще разбере достатъчно скоро.
Минаха часове. Денят идваше и си отиваше. Все още надолу.
На следващата сутрин нещата бяха възстановени и нашият технически директор нежно ме помоли да се присъединя към нея в конферентната зала. Нашият системен администратор беше идентифицирал проблема. Той извади регистрационните файлове на FTP и забеляза, че моят потребител е преместил цялата ни платформа в директорията на брат и сестра. Тоест, wp-content бяха вложени под wp-includes.
Бях смаян, но нашият технически директор беше страхотен за това. Тя можеше да разбере, че като цяло съм услужлив и отговорен служител, но ме предизвика да отида отвъд обикновеното разкаяние и да измисля начини да предотвратя това да се случи никога повече. Открих две наистина полезни неща.
Първият беше да се намери команда на CLI, за да се предотврати въобще Cyberduck да позволява отдалечено към отдалечено движение на файлове. Това беше добра мярка за безопасност и веднага я приехме като фирмена политика.
Второто беше, че проявих голям интерес към внедряването през Git. В крайна сметка завърших писането на плъгин за WordPress, за да превърна нашата версия на Bitbucket в нормалното wp-admin поток на актуализация. Оттогава нямаме почти никаква причина дори имат FTP достъп до продукцията. Този плъгин е едно от любимите ми професионални постижения. Разбира се, афинитетът към Git е предпоставка за разработчиците днес.
add_filter()Наистина мислех, че съм станал доста умен с моите практики на WordPress до този момент. Искането беше да се добави „значка“ към публикации от определена категория. По някаква причина имах предвид, че само noobs биха добавили още една условна към шаблонния файл за нещо подобно, така че с голяма гордост внедрих следния филтър:
add_filter( 'the_content', 'myprefix_add_a_badge' ); function myprefix_add_a_badge( $content ) { global $post; if( ! has_category( 'sponsored', $post ) ) { return false; } $out = $content . myprefix_get_badge(); return $out; } Виждате ли нещо нередно в това? Изпробвах го бързо в постановка, за да потвърдя, че необходимите постове са приложили значките си. След това го разположих и оставих работа за деня. Както се досещате, Вселената избухна.
По-конкретно, резултатът беше, че публикациите без значката се изобразяваха отпред без никакво съдържание! Виждате ли защо? Проблемът беше, че вместо да се върне $content в моето охранително състояние се връщах false. Но наистина тук има много пластове грешки.
Защо се задоволих само да тествам, че публикациите са получили значка? Защо не проверих също така, че други публикации остават невредими? Защо се разположих в производството толкова късно през деня? Защо това беше нашето качество контролът се състоеше изцяло от това, че щракнах малко и освежих страницата?
Отговорът на всички тези въпроси може да бъде обобщен като зрелост . Просто отнема известно време да се разболеем от извършването на подобни грешки, преди да се преместим да инвестираме в неща като тестове за визуална регресия и модулни тестове. Тази конкретна грешка беше сламка сред стотици, която в крайна сметка счупи гърба на камилата и ме накара да се инвестирам много phpUnit и xDebug . На свой ред тези инструменти ме научиха да пиша тестваем код, което вероятно е предотвратило повече грешки от самите тестове.
Искането на клиента беше да преформатира реда на публикацията в блога на WordPress, така че датата да гласи „XYZ ago“, за разлика от „10 ноември 2011 г.“ Не бях съвсем сигурен как да постигна това, но бях наясно, че това беше формат за дата, който изглежда нарастваше популярността си и наистина д-р Google ми предостави фрагмент много бързо. Работи върху моя местен! Имаше много математика, по-специално много разделение . Не бях точно сигурен защо работи - имаше много вложени цикли, остатъци, закръгляване и други такива. Но беше в Google и изглеждаше, че работи и бях достатъчно щастлив да го внедря в производството.
Около 30 минути по-късно получих неприветлив Skype от нашия системен администратор. Производството беше намалено. Мъртви във водата. Той ме попита дали напоследък съм делила на нула и нямах представа какво може да има предвид. Ето какво се случи.
Вярвате или не, нечетливият фрагмент „работи върху моя локален“, който намерих, предвид достатъчно голям размер на извадката, беше способен на някакво отклонено поведение. Доставяни с някои нещастни комбинации от дни, часове и минути, веригите Rube Goldberg от време на време биха се опитали да разделят число на нула. Спомнете си от математиката в гимназията:
В обикновената аритметика изразът няма значение, тъй като няма число, което, когато се умножи по 0, дава (ако приемем ≠ 0) и така делението на нула е неопределено. - Уикипедия
И така, какво означава това за компютрите? Обикновено само съобщение за грешка в регистрационните файлове, но в моя случай беше по-лошо: математическата грешка се намесваше в логиката на моя цикъл, карайки моите вложени цикли да се изпълняват, без никога да завършат - безкраен цикъл, водещ до бял екран на смъртта. И става по-лошо! Тъй като всяка итерация на цикъла пишеше грешка за разделяне на нула, дневникът на грешките нарасна до фантастични размери и започна да възпрепятства нашата файлова система. Това имаше ефекта на DDoS атака, макар и абсурдно самонанесена.
Лошото при тази грешка беше, че тя свали сайт с голям трафик. Хубавото на тази грешка е, че тя драстично промени подхода ми към работата. Повече от всичко се срамувах от готовността си да прилагам без разбиране. Обещах се никога повече да не поставям фрагмент, без да полагам всички възможни усилия да разбера всеки ред, дори да проследя автора на фрагмента, ако е необходимо.
Освен това се зарекох никога повече да не изпращам код, който не беше много четим за начинаещи разработчици. Вманиачих се по стандартите за кодиране на WordPress, разширенията на текстовия редактор, вграденото коментиране и блоковете, и дори раздели спрямо интервали, този класически ритуал за преминаване! В обобщение реших да се погрижа повече за това колко лесно беше Прочети моя код, отколкото колко лесно беше пиши то. Този бунт срещу поставяне без разбиране ме накара да се заинтересувам дълбоко от управлението на зависимостите на трети страни, тема, която подхрани различни възможности за писане и говорене за мен през следващото десетилетие.
Реших да се погрижа повече за това колко лесно беше Прочети моя код, отколкото колко лесно беше пиши то. TweetО, и наистина забавното нещо за тази грешка? Ядрото на WordPress има еднолинейна решение за него.
Бях приземил наистина завладяващ проект. Трябваше да бъда технически ръководител и инженер за разработка на WordPress и щях да имам разработчик на Amazon AWS Lambda и задълбочен експерт по JavaScript, който да ми докладва. Това беше първият път, когато няколко души ми докладваха и това беше най-сложният проект, по който някога съм работил. Дори да го спомена като проект на WordPress, това беше много подценяващо въпроса, но WordPress беше лепилото, което държеше цялото нещо заедно, така че имаше смисъл да действам като технически ръководител.
Тъй като основната ми роля обикновено беше да бъда строго техник, а също и защото имам афинитет към минимализма, никога не ми е хрумнало да внедря нещо като Jira или Basecamp или някаква реална платформа за управление на задачи. Нещата се развиха доста добре за първата итерация на проекта. Успяхме да работим върху собствените си отделни компоненти, да се позовем на спецификацията на клиента като нашата пътна карта на продукта и просто да се пингнем през Slack, когато трябваше да свържем нещата.
Проблемът започна, когато започнахме да демонстрираме напредъка на клиента и да прилагаме неговите отзиви. Това, което започна като екип от трима души, веднага почувства, че е изведено до нов порядък: Не беше ясно кой е отговорен за каква част от обратната връзка, какъв е статусът на прилагането на тази обратна връзка или дори кой с кого разговаря . Няколко пъти надхвърлихме ограничението на Gmail от 100 отговора на нишка!
Нещата започнаха да стават неудобни. Мисля, че клиентът се чувстваше така, сякаш е загубил контрол над посоката на проекта, и също толкова важно е, че е загубил видимост на статуса на проекта. Моят разработчик на Amazon спомена един ден, „Чудя се дали да не използваме Trello.“
Ами , Мислех. Има ли нужда от екип от трима души такава платформа? Отново, моята обичайна тенденция е да предпочитам по-малко инструменти, по-малко режийни разходи, по-малко сложност. Но проектът вече ни влачеше всички в мръсотията, така че каква беше вредата от опита му?
Прегледах всичките ни имейли, всичките ни спецификационни документи, всичките ни различни коментарни нишки и ги картографирах на дъските на Trello. Веднага проектът се възкреси от дигиталната си гробница, защото можехме да общуваме с далеч по-малко умствени разходи. Вместо да търсим текст в пощенската си поща или в предимно остарял спецификационен документ, имахме прекрасни табла, списъци и карти. Беше лесно да се види състоянието на която и да е функция, да се включи обратна връзка и да се изпълнят нови задачи. Чувствахме се така, сякаш постепенно ослепяхме, толкова бавно, че не го забелязахме, а след това изведнъж можехме вижте отново.
Разбира се, кодът не се е написал сам, той все още беше много труден проект и все още трябваше да използваме всяка унция от нашите технически умения. Но това е нещо като смисъл: Тъй като най-накрая имахме инфраструктура за разбиране на проекта, сега бяхме Безплатно да приложим нашите технически умения.
Щастлив съм да кажа, че този проект беше завършен с пълното удовлетворение на клиента. В днешно време считам Trello или Jira за фактическо изискване за отбори от двама или повече.
Ето едно от най-умните неща, които съм чувал да преподавам по време на военното си време: „Редниците да правят грешки на лейтенантите и капитаните да правят грешките на капитана. Това, което не е наред, е капитаните да правят лейтенантски грешки или лейтенантите да правят частни грешки. '
С други думи, добре е да направите често допускани грешки това е нещо разбираемо за сегашното ви ниво на отговорност. По-важното е как израствате от тях.
Надявам се, че ние като разработчици се научаваме да проявяваме състрадание към другите, когато правят грешки, както се надяваме и другите да са били с нас. Надявам се да остана любопитен и отговорен, когато правя грешки, така че да продължа да въвеждам иновации покрай тях. Надявам се винаги да съм заобиколен от вдъхновяваща общност от WordPress експерти —Хора, от чиито грешки мога да се уча и да не правя себе си. И не на последно място, надявам се, че други могат да се поучат от моя опит, като грешките в WordPress, които споделих тук.
Свързани: Как да подходим към модерното разработване на WordPress (част 1)Те са вътрешният двигател на WordPress и трябва да останат безопасно прибрани под капака: Можете да ги четете, но не и да ги редактирате, защото работата ви ще бъде заменена при следващото актуализиране на WordPress. Вместо това разработчиците се интегрират с WordPress чрез теми и приставки.
Повечето разработчици на WordPress плъгини пишат по-голямата част от кода си на PHP и JavaScript, с по-малък обем HTML и CSS. Разработчиците на теми използват същия набор от езици, но в приблизително обратния ред на приоритет. Много рядко може да се наложи разработчик на теми или приставки да напише SQL.
Традиционният избор е MAMP. Това е прост продукт с отворен код, който бързо се доставя с поддръжка за phpMyAdmin и превключване между различни езикови версии. През последните години няколко по-нови опции спечелиха значителен пазарен дял, като Vagrant, Local by Flywheel и Pantheon’s Multidev.
Query Monitor е де факто изискване за отстраняване на грешки и също така предупреждава разработчиците, когато заявките или отдалечените заявки станат твърде бавни. Yoast SEO дава на клиентите много задълбочен потребителски интерфейс за управление на неща като SEO заглавия и мета, както и протоколи в социалните медии. Формуляр за контакт 7 е надеждно решение за формулярите „свържете се с нас“.
Най-доброто място за намиране на приставки е WordPress.org, защото там има стабилна екосистема за отзиви, поддръжка и общност като цяло. Още приставки, ориентирани към разработчиците, могат да бъдат намерени на GitHub. Тук също разработчиците на ядро на WordPress подготвят бъдещи основни функции, като ги стартират като плъгини.
